Java, Groovy und die dynamische Objektorientierung

[tasiwaiar]

Hallo Leute!
Ich will euch heute von einer tollen Sprache für die JVM erzählen, mit der ich bisher keine probleme hatte...
Groovy ist in etwa Ruby in der JVM, aber anders.
Groovy erzeugt .class Dateien oder werden Interpretiert
aus a + b wird a.plus(b)
ein int ist ein Integer
eine ArrayList wird [a,b,c] deklariert
a.bla wird zu a.getMetaClass().invokeMethod(this, 'getBla', EMPTY_PARAMS_ARRAY);
Toll, oder?!
Eine super sprache, guckt mal auf die Website
Es gibt bei Hanser ein interressantes Buch dazu, fals es interresiert, sucht nach "Groovy im Einsatz"!
PS: Es wird auch in Netbeans unterstützt!

 

[brebsaron]

Dazu gibt es auch einen guten Artikel den ich erst vor ein paar Tagen im aktuellem Java Magazin gelesen habe.

 

[mermshaus]

Toll, oder?!

Du hättest das für meinen Geschmack für diejenigen, die die Sprache nicht kennen, ruhig etwas ausführlicher einleiten können.

aus a + b wird a.plus(b)

Ich habe zum Beispiel gerade erst bemerkt, dass a + b (und nicht a.plus(b)) vermutlich der Groovy-Code sein soll (obwohl es perfekt aussieht wie Java), also dass die Richtung der Beispiele Groovy => Java ist. (a.plus(b) sieht nämlich vom Stil her nach Ruby aus und du schreibst, Groovy sei wie Ruby.)

Weil ich die linke Seite erst für Java hielt, habe ich mich dann auch gefragt, was bloß an a.getMetaClass().invokeMethod(this, 'getBla', EMPTY_PARAMS_ARRAY); besser sein soll als an a.bla, um eine öffentliche Instanzvariable anzusprechen.

Nach dem ersten Lesen musste ich deshalb auf's Datum schielen, um mich zu vergewissen, dass das kein Aprilscherz sein soll.

Was die Sprache selbst angeht, muss man wohl zwischen den Syntax-"Vorteilen" (dynamische Typisierung :-?) und den Nachteilen, die durch das Aufgeben der Standardsyntax aufkommen (zusätzlicher Abstraktionslayer, Verkleinerung der "Entwicklercommunity" auf einen Bruchteil der Java-Entwickler, mögliche Bugs in Groovy, ...), abwägen.

 

[tasiwaiar]

Das mit der kleineren groovy-Entwicklercommunity stimmt so nicht.
Jedes richtige Java ist auch richtiges groovy!
PS: Ich hab jetzt nicht so viel Zeit und ich kann nur das 1-Finger-System

 

[YpsilonZet]

wieviel geld kriegst denn so für die werbung?
Bin zurzeit in Verhandlungen über Prolog und F#. Wenn die noch nen hunderter drauflegen, post ich da morgen auch 2 artikel drüber

 

[tasiwaiar]

Also, ich bin 13, und ich krieg gar kein Geld...
Ich finds nur ne tolle Sprache in der ich alle meine letzten Applikationen entwickelt hab!

 

[mermshaus]

Das mit der kleineren groovy-Entwicklercommunity stimmt so nicht.
Jedes richtige Java ist auch richtiges groovy!

Ja, das mag technisch stimmen. Ich meinte mit "Community" das gesamte Geflecht aus Foren, Blogposts, vorhandenen Bibliotheken, Mailing-Lists, Projekten, Tools, IDE-Unterstützung usw. Das dürfte beim klassischen Java erheblich dichter gewoben sein als bei Groovy. Das mag im Fall von Groovy nicht gar so entscheidend sein, da sich ja sicherlich eine Java-Anwendung gegen eine Groovy-Bibliothek linken lässt und umgekehrt. (?) Dennoch ist das ein Punkt, den man beachten und über den man sehr genau nachdenken sollte. Das Risiko, mit einer mehr oder weniger unüblichen zusätzlichen Abstraktionsschicht irgendwann in Schwierigkeiten zu geraten, ist definitiv gegeben.

Das soll kein Argument gegen Groovy sein, sondern lediglich ein Hinweis.