Erweiterungen in späteren Java-Versionen

[miketech]

Hallo zusammen,

ich habe einige Zeit nun mit .NET programmiert und gerade wieder dabei mich mit Java zu beschäftigen, weil ich mit ASP.NET nicht so ganz zufrieden bin und was gescheites für Webentwicklung suche, weshalb ich grad mit JSF zu schaffen bin.

Aber hier möchte ich was ganz anderes ansprechen: Vielleicht kennt sich einer mit den aktuellen Entwicklungen im Java Community Process aus. Es gibt einige Dinge, die ich in Java vermisse, seitdem ich mit C# entwickelt habe:

1. Partial Classes

Hiermit ist es möglich eine Klasse über mehrere Dateien zu verteilen. Ziel war es vielmehr auf der einen Seite eine Datei mit dem vom GUI Designer generierten Code zu erhalten und auf der anderen Seite das Backend mit der Programm-Logik. D.h. der Designer pfuscht nicht im Code rum.


2. Properties

In C# greift man nicht über einfache Methoden auf Felder einer Klasse zu, sondern über getter und setter. Das läuft dann in der Form:

int meineVariable;
public int MeineVariable {
  set {
     meineVariable = value; 
  }
}

Im Programm kann ich dann direkt darauf zugreifen mittels: XY.MeineVariable = 2; statt XY.setMeineVariable(2).

Damit können eben auch solche Operationen wie XY.MeineVariable = XY.MeineVariable + 2; ausgeführt werden.


3. Gleichheit bei Strings

string a = "test";
a == "test"

Geht in Java ja nur mittels equals. Kann ich in Java nicht auch Operatoren wie == überladen?




Also das hier soll kein Genörgel sein, nicht falsch verstehen Aber in letzter Zeit war es ja doch so, dass sich Java und C# gegenseitig etwas befruchtet haben. Daher wollte ich fragen: Weiß jemand, ob solche Sachen aktuell im JCP angesprochen werden? Oder ist nichts derartiges geplant?

Gruß

Mike


Was ich noch ganz nett fand: In C# werden Interfaces immer mit I begonnen. Also IList, IEnumerable usw. Damit wußte man immer, was man da verwendet. Wie erkennt man in Java Interfaces? Muss man dafür einfach wissen, was man verwendet, bzw. in der Doku nachschauen? Oder gibts da auch ein Muster?

 

[SlaterB]

sind diese setter und getter ganz normale Operationen in denen beliebiger Code hineindarf?
dann wär das ja ein praktisches Auto-Feature

-------

wozu Interface erkennen? wüßte nicht, dass das irgendwo mal vorgeschlagen wurde,
vermisse ich bisher nicht, wo wäre das von Vorteil?

interessanter ist es da schon, Variablen nach ihrem Datentyp zu benennen,
i(nt)Anzahl, s(tring)Name,
aber selbst das macht ja keiner

widerspricht wohl ein wenig der objektorientierten Benennung?

 

[RaoulDuke]

1. Partial Classes

Hiermit ist es möglich eine Klasse über mehrere Dateien zu verteilen. Ziel war es vielmehr auf der einen Seite eine Datei mit dem vom GUI Designer generierten Code zu erhalten und auf der anderen Seite das Backend mit der Programm-Logik. D.h. der Designer pfuscht nicht im Code rum.

*hust*

Darstellung und Logik gehören sowieso nicht in die gleiche Klasse, also braucht man da eigentlich keine "Partial Classes". Wofür soll das gut sein?

 

[Leroy42]

interessanter ist es da schon, Variablen nach ihrem Datentyp zu benennen,
i(nt)Anzahl, s(tring)Name,
aber selbst das macht ja keiner

und das ist auch gut so.

Daß die, von der C#-Api, vorgegebenen Interfaces mit I beginnen,
halte ich eher für kontraproduktiv im Sinne der OOP; frei nach dem Motto,

Was geht es den Nutzer an ob etwas eine reine Klasse oder
die Implementation eines Interfaces ist; er hat sich gefälligst
an die Schnittstelle zu halten.

(Wer weiß denn z.B. schon daß Graphics ein Interface ist).

Darüber, ob man getter und setter, wie auch in Delphi, verstecken soll,
kann man, genau wie bei der Überlagerung von Operatoren, streiten.

Ich persönlich finde es vernünftig, daß man sofort erkennt, ob eine
Methode aufgerufen wird oder nicht.

 

[miketech]

Hallo,

sind diese setter und getter ganz normale Operationen in denen beliebiger Code hineindarf?
dann wär das ja ein praktisches Auto-Feature

Da darf im Grunde alles rein, ja. Das wirklich interessante ist meiner Meinung nach die Verwendung:

In C# schreibt man lokale Variablen klein, die Getter und Setter groß, wie im obigen Beispiel von mir.

D.h. wenn ich mit XY.MeineVariable = xy zugreife weiß ich schon, dass es ein Setter ist. XY.meineVariable wäre dann eine lokale Variable der Klasse.

Und XY.MeineVariable += 2; finde ich schöner als:

XY.setMeineVariable(XY.getMeineVariable() + 2));

wozu Interface erkennen? wüßte nicht, dass das irgendwo mal vorgeschlagen wurde,
vermisse ich bisher nicht, wo wäre das von Vorteil?

Ich fand das immer ganz sinnvoll. Wenn ich von einem Interface ableite weiß ich, dass ich noch alles implementieren muss. Wenn ich nur von einer Klasse erbe muss ich ja nur benötigte veränderte Methoden überschreiben.

Darstellung und Logik gehören sowieso nicht in die gleiche Klasse, also braucht man da eigentlich keine "Partial Classes". Wofür soll das gut sein?

Aber in Java würdest Du es auch so machen. Also ich meine mit Logik insbesondere den Part, dass man auf Events von irgendwelchen Controls reagiert. Du hast ja dann in Deiner Klasse einen Button und ein Event OnButton1_Clicked oder sowas. In Visual Studio wird eben der vom Designer erstellte Code durch partial classes von diesen Handlern getrennt.

(Wer weiß denn z.B. schon daß Graphics ein Interface ist).

Sowas weiß eben keiner. Ich persönlich finde es, wie gesagt sinnvoll, dass ich weiß, was ich verwende. Ob ich ein Interface implementiere, oder von einer Klasse erbe. Damit ich weiß, was ich da verwende.



Und nochmal zu den Events: In C# werden sogenannte Delegates verwendet. Halte ich persönlich für eine feine Sache:

Button1.OnClick += MyClickHandler;


Damit wird immer, wenn das OnClick Event gefeuert wird die Methode MyClickHandler aufgerufen.


In Java kenn ich nur diese Listener. Ist das ein generelles Konzept von Java, oder ist das nur in Swing so gelöst?

Gruß

Mike

 

[Leroy42]

(Wer weiß denn z.B. schon daß Graphics ein Interface ist).

Sowas weiß eben keiner. Ich persönlich finde es, wie gesagt sinnvoll, dass ich weiß, was ich verwende. Ob ich ein Interface implementiere, oder von einer Klasse erbe. Damit ich weiß, was ich da verwende.

Und nochmal: Du weißt daß du eine Instanz einer Klasse verwendest, die das notwendige anbietet.
Was interessiert es dich, ob es sich um ein Interface handelt? Das nennt sich Information Hiding

In Java kenn ich nur diese Listener. Ist das ein generelles Konzept von Java, oder ist das nur in Swing so gelöst?

Es ist ein generelles Konzept und ich selbst schreibe mir häufig meine eigenen Listener

 

[miketech]

Hi,

Und nochmal: Du weißt daß du eine Instanz einer Klasse verwendest, die das notwendige anbietet.
Was interessiert es dich, ob es sich um ein Interface handelt? Das nennt sich Information Hiding

Naja, wenn ich es nur instanziiere ist das natürlich egal. Aber in dem Moment, wo ich z.B. eine eigene Klasse schreiben möchte ist es für mich interessant. Ich finde es bei Java etwas verwirrend, dass es List als Interface gibt und dann ArrayList, LinkedList und weitere(?) als Implementierungen. Und Maps gibt es doch auch mehrere Varianten. Wieso brauch ich davon mehrere? Und es hat bei mir ein Weilchen gedauert bis ich wußte, dass List nur das Interface ist, d.h. dass ich davon auch keine Instanz erzeugen kann.

Es ist ein generelles Konzept und ich selbst schreibe mir häufig meine eigenen Listener

Ok.

Gruß

Mike

 

[AlArenal]

Ich finde es bei Java etwas verwirrend, dass es List als Interface gibt und dann ArrayList, LinkedList und weitere(?) als Implementierungen. Und Maps gibt es doch auch mehrere Varianten. Wieso brauch ich davon mehrere?

Gedankenanstoß:
Wozu braucht es unterschiedliche Autos? Alle machen im Grunde dasgleiche....

 

[byte]

zu den Properties:
Mir gefällt das Feature von C# auch, ich hätte es gerne in Java. Aber im Grunde ist es nix anderes als Syntactic Sugar. Im Grunde ist es Jacke wie Hose, ob ich nun Properties habe oder meine IDE auf Knopfdruck Getter/Setter erzeugt. In der aktuellen Eclipse Version kannst Du z.b. auch dank der Categories Getter/Setter im Outliner ausblenden. Dann stören sie auch nicht weiter bei der Übersicht.

zur Operatorüberladung:
Hätte ich mir häufig mal gewünscht, aber gibts auch nicht in Java. Ist im Grunde auch wurscht. Ob man nun einen Operator verwendet oder eine Methode, sind ja bloß Unterschiede in der Syntax. Bei mathematischem Kram wäre es halt nett, aber was solls. Operatorüberladung hat halt auch Nachteile, denn man kann sich dann nie bei einer Klasse sicher sein, was ein gewisser Operator denn nun wirklich macht.

Ansonsten hindert Dich niemand daran auch in Java alle Interfaces mit I beginnen zu lassen. Es gibt auch einige Frameworks, die das tun, siehe SWT.

Was die Listener angeht: ist im Grunde nichts anderes als eine Umsetzung des Observer Patterns, das mit Events arbeitet.

 

[Wildcard]

Operatorüberladung wird gerne mit Kernkraftwerken verglichen... können sehr nützlich sein, oder...
Da Atomkraftwerke eh aus der SUN Lizenz ausgeschlossen sind war die Entscheidung natürlich klar :bae:
Aber im ernst, die SUN Entwickler sind einfach der Meinung das die Nachteile der Operatorüberladung überwiegen, und ich stimme dieser Einschätzung zu.
Wirklich nötig sind sie nur bei komplexen mathematischen Berechnungen, und für sowas nimmt man weder Java, noch C#, noch C.

 

[Leroy42]

Wirklich nötig sind sie nur bei komplexen mathematischen Berechnungen, und für sowas nimmt man weder ... noch C.

C auch nicht? :shock:

Was denn dann? Jetzt sag' nicht: "Das gute, alte Fortran"

 

[byte]

Scheme!

 

[Wildcard]

Das gute, alte Fortran

http://forum.java.sun.com/thread.jspa?forumID=31&threadID=570191[/url]]Daniel Steinberg: You mentioned that one area where performance wasn't there yet was numerical computing. But I think I saw on one of your slides that that's actually where you guys compared quite well against the Visual C++ demo.

James Gosling: We actually are pretty good against C++ in most numeric stuff. But there are ways that we could be a lot better. The performance parts are okay. There are some things like operator overloading. Operator overloading is one of these things where, if you're not doing numerical computing, operator overloading is much more often abused than used sensibly. And in numerical computing, it's used very heavily.

But for performance things, the target to beat really isn't C++, it's FORTRAN.

 

[Leroy42]

Das gute, alte Fortran

Und ich dachte PROLOG

 

[Wildcard]

Und ich dachte PROLOG

:autsch:

 

[foobar]

In der aktuellen Eclipse Version kannst Du z.b. auch dank der Categories Getter/Setter im Outliner ausblenden

Huch, wie geht das denn?

 

[Roar]

Graphics ist übrigens ne Klasse :lol:

 

[Illuvatar]

Um die Frage des OP nochmal klar zu beantworten: Es gibt in Java (noch?) keine Partial Classes, Properties, Operatorenüberladung, Delegates oder Events

Und um in dem Fred nicht so Java-negativ aussehen zu lassen, mal ein Kritikpunkt an .net... Dass das ganze Zeugs mit virtual, override, new etc. aus C++ übernommen wurde find ich doof - einfach immer late binden wie in Java, und gut ist

 

[byte]

In der aktuellen Eclipse Version kannst Du z.b. auch dank der Categories Getter/Setter im Outliner ausblenden

Huch, wie geht das denn?

Wenn Du z.b. an alle Getter im Javadoc @category getter schreibst, kannst du diese im outliner ausblenden (über irgendein Symbol da).

 

[miketech]

Ok, also offensichtlich ist nichts davon für kommende Versionen geplant

Gruß

Mike

 

[Roar]

doch partial classes sind für 1,7 geplant

 

[sparrow]

Damit können eben auch solche Operationen wie XY.MeineVariable = XY.MeineVariable + 2; ausgeführt werden

Äääh... versteh ich hier was nicht?
also wenn man unbedingt ohne setter und getter arbeiten will geht das doch:

public class MethodTest {

	public int x = 5;
	
	public static void main(String[] args) {
		MethodTest test = new MethodTest();
		System.out.println(test.x);
		test.x = test.x + 2;
		System.out.println(test.x);
	}

}

Ausgabe:

5
7

Ich meine, es ist nicht schön, aber gehen tut das schon.

 

[miketech]

Nett, woher hast Du die Info mit den Partial Classes?


Und zu dem anderen: Natürlich geht das auch mit öffentlichen Variablen *g* Aber was ist z.B. bei:

private int a;

public void setA(int a) {
  this.a = a * 5;
}

Jetzt geht das mit öffentlichen Variablen natürlich nicht mehr. In C# könnte ich trotzdem:

XY.A += 2;

ausführen.

Gruß

Mike

 

[sparrow]

Natürlich geht das auch mit öffentlichen Variablen *g* Aber was ist z.B. bei:

private int a;

public void setA(int a) {
  this.a = a * 5;
}

Jetzt geht das mit öffentlichen Variablen natürlich nicht mehr. In C# könnte ich trotzdem:

XY.A += 2;

ausführen.

Jo.. das klingt aber völlig sinnlos.
Dafür sind die Deklarationen ja da. Wenn ich die Variable außerhalb der Klasse sichtbar haben will mach ich sie halt public. Will ich es nicht hat das sicher seinen Grund.
Nene, das ist für mich eine Funktion die ganz sicher nicht in Java fehlt sondern ziemlich Blödsinnig wirkt.

 

[miketech]

Hi,

aber wo ist denn dann der Unterschied zu

XY.A und XY.getA() ?

Es ist beides nach außen sichtbar. Das erste ist nur eine kürzere Schreibweise. Natürlich ist das Beispiel von mir oben nicht sehr sinnvoll. Aber ich könnte ja in dem get oder set noch Funktionsaufrufe implementieren:

setA(int a) {
SaveValueToDataBase(a);
this.a = a;
}

Geht auch nicht mit public Variablen.


Und es ist immer noch zu unterscheiden:

Mittels

get {
  return xy;
}
set {
  xy = value;
}

unterscheide ich ja zwischen getter und setter. D.h. ich kann auch nur set oder get freigeben, was mit public Variablen nicht möglich ist.


Was ich auch gut finde sind Indizes:

class A {
 public int this[int index] {
  get {
    return irgendwas;
  }
 }
}

Damit kann ich auch folgendermaßen auf ein Objekt zugreifen:

A a = new A();

int b = a[0];


b = irgendwas

In Java gibt es fast immer nur die umständlichere objekt.get(0) Schreibweise, obwohl die Index-Schreibweise mit [] recht intuitiv ist.

Mittels der Indizes kann ich [] selbst definieren.


Gruß

Mike

 

[Roar]

das mit den properties is ne intressante sache. afaik gibt's sowas ähnliches in EJB3, wo man die source dateien vorher aber noch nem extra compiler durchjagen muss der daraus wieder für javac lesbaren code macht.

mit deinen [] sind wir aber schon bei der operatorüberladung und das wird nicht in java kommen

edit: ne ich mein das: http://www.geocities.com/adcalves/javaproperty/

 

[miketech]

Ach das ist natürlich auch eine feine Sache Ist aber nicht so flexibel wie get und set in C#. Na vielleicht gibts das ja auch in Java 7, wer weiß

Gruß

Mike