Gestern war es soweit. Java 7 wurde released und kommt mit einer Menge sehr guter Performance Verbesserungen:
Java 7 Features
Discuss! (Auch wenn hier wahrscheinlich viele rum rennen die Java nur aus 1.0 Zeiten kennen^^)
Gestern war es soweit. Java 7 wurde released und kommt mit einer Menge sehr guter Performance Verbesserungen:
Java 7 Features
Discuss! (Auch wenn hier wahrscheinlich viele rum rennen die Java nur aus 1.0 Zeiten kennen^^)
Oh ja... Java 1.0... ich erinnere mich noch an die bin
Java1.bin:
That's just trolls
Ne, ernsthaft.. mal schaun wie performant es jetzt geworden ist...
okayokay... nur weil MC Java benutzt heißt daas nicht unbedings das es an Java liegt...
.....
The Code lies in the eye of the programmer.
10 PRINT HOME
20 PRINT SWEET
30 GOTO 10
Gibt’s irgendwo eine Liste mit wichtigen Neuerungen, für die ich mich nicht durch zig Webpages durchwühlen und die 95% irrelevanten Kram rausfiltern muss?
http://de.wikipedia.org/wiki/Java_%2...k%29#Version_7 < Ich hoffe mal, das überhaupt dieses Java gemeint ist.![]()
Anstatt Bling-Bling-Effekte für Swing zu implementieren, hätten sie sich mal um die Layout-Manager kümmern sollen. Die sind weiterhin ein extremer Krampf.
Ansonsten kann ich bis jetzt noch keine Performancegebesserungen feststellen. CPU Auslastung und Speicherreservierung sind bei meinen Programmen, wie eh und je. Zumindest wurde nun dieses überflüssige Warndreick entfernt.
Warum denn genau Whiz? Wie genau würdest do es denn gern haben? Ich war immer der Meinung: compontent.setLayout() ist der Gipfel der Einfachheit. Dazu noch die Tutorials von Java (Ja damit hab ich gelernt die im Schlaf zu behandeln).
Ich glaub eh das sie das wegen c# gemacht haben, dort kann man ja so krasse sachen machen mit seiner Gui (auch wenn ich da echt ohne Gui-Generator nicht klar komme... doofes XML, mit dem steh ich oft auf Kriegsfuß)
Es gab ne Seite die Benchmakrs gemacht hat... wenn ich sie denn jetzt mal finden könnte :/
Übrigens wird grad von einem Bug mit Loops berichtet aber ich finde bei Gott keinen Sample Code der mir das beweisen könnte... Gut, da Eclipse noch kein Java 7 unterstützt (okay, das kann man Netbeans lassen, cool dass es da schon geht) daher nutz ich eh noch die jdk 25 (bzw 26).
R.D., du bist jetzt der einzige, den ich kenne, der meint, dass die Layout-Manager einfach seien.
Alle Programmierer, die ich kenne, die mal mit Java eine komplexere Oberfläche mit den Layout-managern basteln mussten, sagen, dass die Layout-Manager sehr suboptimal sind. Auch ich hatte schon diverse Probleme gehabt, eine Oberfläche damit zu basteln. Anscheinend reagieren die Layout-Manager oftmals nicht so, wie man es eigentlich erwartet. Man kann oft an Stellschrauben drehen, aber es passiert einfach nichts. Eine manuelle Größenangabe für die Komponenten geht bei 90% aller Fälle schief, da die Layout-Manager bestimmen, wie groß eine Komponente wird. Da bringt selbst setDimension() nichts.
Manchmal klappt es dann mit setPreferedSize(), setMinimumSize(), setMaximumSize() oder in Kombination mit allen drei Methoden.
Tja klar man sollte schon Ahnung von Swing haben. Aber setPrefferedSize() funzt immer, jedenfalls bei meinen Sachen (Ich hab schon winige komplexe Sachen gemacht, einfach ums zu testen). Das mit min und max hat mich auch am Anfang irritiert, aber mittlerweile... easy as saidBisher haben die bei mir immer das gemacht was ich wollte, ja sogar oft mehr. (zb das man GridBagLayout fremdendwenden kann um eine Komponenten beim resizen immer in der Mitte eines Panels bleibt usw
).
Mich hat damals auch oft gestört das die Gui-Generatoren alles so doofen Code machen, daher hab ichs mir auf die harte Tour selbst beigebracht. Wusste gar nicht das damit so viele Probleme haben^^
Hab hier mal einer der Gui's hochgeladen falls du mal schauen willst: (leider ohne resize... alter build eben :0)
RPG-Maker Color Theme Editor
Das ist für eine Projekt von Cherry gemacht (was den RPG Maker, unter anderem halt syntax highlighting ermöglicht).
Wie’s aussieht, haben sie Java 7 (wissentlich) mit einem JIT-Compiler-Bug released, der Crashes, Code Corruption und inkorrekte Ausführung verursacht. Ganz groß, Oracle.
Woa Fedprod, wenn du nix intelligentes zusagen hast, dann lass es bitte, danke :/
@Mq
Genau den Bug meinte ich in meinen Post, danke für den Link. Echt schlimm das Oracle den Entwicklern ne Deadline gibt... Oracle suckt echt derbe bei sowas :/ Unter Sun war das nie so ein großes Problem.
(auch wenn ich den Fehler nicht reproduzieren konnte )
Übrigens liegt das an einer Flag die von Oracle -in dem Wissen es wurde kaum getestest- ab Version 7 immer gesetzt ist. Lustigerweise war das in den Ver. 7 Builds nicht so... das müssen dir auch kurz davor entschieden haben xD
Ich find die Neuerungen nicht wirklich spannend.
Am meisten hätt ich mir Operator Overloading und Properties gewünscht aber die werdens wohl nie in java reinschaffen.
Einfach nicht aber ich finde sie trotzdem Klasse. Das einizge Problem ist, dass man gerade für GroupLayout und MigLayout, meine 2 Favoriten, unbedingt einen GuiBuilder nehmen sollte. Dafür den Code selber schreiben ist horror...Zitat
Und eigene LayoutManager lassen sich auch sehr sehr einfach schreiben.
Geändert von nudelsalat (31.07.2011 um 10:09 Uhr)
Huch? Es gibt doch Properties in Java. http://download.oracle.com/javase/6/...roperties.html
Oder was meinst du genauer?
--
Mit Properties mein ich eine Alternative zu getter und setter, ähnlich wie es sie in C# gibt.Anstatt dass man für jede Variable getter und setter Methoden schreibt greift man einfach direkt auf die Variable selbst zu und kann, falls nötig, eine Methode definieren die ausgeführt wird wenn die Variable gesetzt oder returniert wird.
Nicht das ich wüsste aber wenn man doch mal vorhat statt einem getter die Variable public zu machen und später draufkommt, dass man beim Zurückgeben der Variable doch noch code ausführen muss also doch einen getter braucht, dann muss man nachher nicht hunderte von Variablenzugriffen refactoren. Und auserdem find ichs mühsam und hässlich wenn eine vielzahl von Klassen für 10 und mehr Variablen jeweils 2 total triviale Methoden dazubekommt, egal wie schnell sich diese beiden Methoden von der IDE generieren lassen.
Dito. Dazu kommt, wie ich finde, dass, neben den Methodenrümpfen, das ganze manchmal auch echt unangenehm beim Programmieren ist. Ich finde ein Frame.visible = true deutlich angenehmer als ein Frame.setVisible(true). Solche setMethoden finde ich, solange man nur ein Parameter hat eher hinderlich und nicht wirklich schön. Auch wenn ich vielleicht gleich verspottet werde, in ObjectPascal (aka Delphi, wobei ich lieber Delphi auf die IDE reduziere) sind die properties echt wünschenswert gelöst. Ähnliches täte Java auch gut.
Außerdem Frage: sind diese ganzen getter und setter, sofern sie nur aus Zuweisen und Auslesen bestehen, nicht ein overhead auf den man eigentlich verzichten könnte? (schlagt mich nicht, ich hab halt keine Ahnung)
Mein eclipse hat mir gerade gesagt, dass Binary Literals wie "0b1000_0000" erst mit java 1.7 funktionieren. Gleich mal auf 1.7 umgestellt und..geht wirklich!
Java 7 hat doch nützliche neuerungen. :3
Ich war auch sehr überrascht, aber positiv. 0b0000000000000000100000000000000 ist eher semioptimal zu lesen. Bei 0b00000000_00000000_10000000_0000000 weiß man sofort was lost ist. :3
Geändert von nudelsalat (29.10.2011 um 15:14 Uhr)
Und 0x8000 ist evtl. noch besser.Also ich kann binären Literalen kaum was abgewinnen, hexadezimal ist da kaum schlechter. Und weit verbreiteter.
Die Unterstriche, naja – so lange Nummern schreibt man selten, und wenn, merkt man eh schnell, was sie sein sollen. Hin und wieder könnten sie aber wohl praktisch sein. *shrug*
--A human is a system for converting dust billions of years ago into dust billions of years from now via a roundabout process which involves checking email a lot.