# Java 7 FINAL Release bekanntgegeben



## SE (9. Juli 2011)

Da stöber ich so nichts ahnend in meinen Mails rum und denke : naja Spam kannst getrost löschen ... gehe rein ... auf ein mal n Mail von Oracle : Java 7 Launch

Laut der Mail wurde das offizielle Release für den 28.07.2011 GEPLANT.
Wenn also alles klappt dürfen wir ab August mit vielen Updates für fast alle großen Java-Applikationen auf die neue Version 7 hoffen.

Als weitere Anmerkung stand weiterhin drin :

Der Support für Java5.0 soll mit dem Release von Java7 auch eingestellt werden.
Damit fällt natürlich ein Großteil der immer noch "nötigen" Kompatibilität zu älteren Versionen raus da man sich voll und ganz auf Java6 und Java7 konzentrieren kann. So kann man nun also von seinen Kunden verlangen das diese doch bitte wenigstens auf Java6 updaten und das Java5.0 nicht mehr unterstützt wird *wobei als Anmerkung natürlich ein Verweis auf die dann aktuelle Version 7 gegeben sein sollte*.

Ich persönlich begrüße Java 7 mit offenen Armen. Nicht nur da ich ja sowieso schon längere Zeit nur noch mit Java7 arbite sondern weil ich es dann auch "verlangen" kann.
Es gibt viele Dinge in Java7 von denen ich bereits gebrauch mache *z.B. das neue java.nio.file - Paket*.

Also ... jetzt ist eure Meinung gefragt !

Ist die Informationtechnik schon bereit für den Schritt auf Version 7 ?
Sollte man sich jetzt hauptsächlich darauf konzentrieren ?
Wie soll man mit Kunden umgehen die immer noch veraltete Versionen *5.0 und älter* verwenden und sich weigern zu updaten ?

Ich hoffe das wird hier eine schöne Diskusionsrunde in der jeder zu Wort kommt.


----------



## genodeftest (9. Juli 2011)

Wo gibts Java7 offiziell zum Download?
Ich hab bisher nur Downloads von Beta-Versionen gesehen, 
http://jdk7.java.net/download.html (Version b147 für alle Plattformen)
https://launchpad.net/ubuntu/+source/openjdk-7 (Version b136, in .deb-Paketen für Ubuntu 11.10)

*[EDIT:]* auf der offiziellen Download-Seite gibt es nur 6u26, siehe http://www.oracle.com/technetwork/java/javase/downloads/index.html 
Ich wäre auch mit OpenJDK 7 final zufrieden, zwischen OpenJDK7 und Oracle's JDK 7 soll ja kaum noch ein Unterschied sein.*[/EDIT]*


----------



## SE (9. Juli 2011)

Hehe ... da hast du aber das Datum voll überlesen : *28.07.2011*
Außerdem ist es erstmal nur *GEPLANT* ... also kann sich das Datum noch ändern.

Was das OpenJDK7 angeht : laut Mail soll mit Version7 das OpenJDK die offizielle Referenzimplementierung sein. Damit dürften die Unterschiede auf ein Minimum reduziert werden *sicher wird es noch einige Klassen in com.sun.* und sun.* geben die Oracle so nicht rausrücken wird ... aber diese sollen in offenen Namensräumen als Referenz trotzdem verfügbar sein*.


----------



## genodeftest (9. Juli 2011)

Ich hab aber gestern ein Feed von irgend einem Oracle-Mitarbeiter gelesen, dass Java 7 jetzt (vorgestern?) fertig sei. Die haben es also Ready-to-Release und veröffentlichen es nicht?

Zu den Unterschieden:
Ja, das Problem ist ja bekanntlich, dass es einige "Altlasten" proprietärer Software gibt, die nicht OpenSource sind (und damit nicht ins OpenJDK aufgenommen werden) und auch nicht auf alle Platformen portiert werden (können). So weit ich gelesen habe, hat das in Java7 abgenommen, da in Oracle's JRE/JDK einiges an proprietärer Software durch OpenSource-Software ersetzt.


----------



## zerix (9. Juli 2011)

Hallo,

Momentan gibt's den ersten ReleaseCandidate zum download. 

Gruß

Sascha


----------



## SE (9. Juli 2011)

Also ich sehe auf keiner Seite was von einem RC ... lediglich das schon länger verfügbare pre-Build *aktuell Build 147* ... aber das gibts schon länger *glaube Build 35 war das erste was ich hatte*.
Es wird jetzt nur so groß als RC propagandiert ... ist aber nichts anderes als ein Early-Access-pre-Build mit anderem Namen.


----------



## zerix (9. Juli 2011)

Nach Downloads hab ich noch nicht geschaut. Ich bin jetzt hier von aus gegangen. 

http://mreinhold.org/blog/jdk7-rc

Gruß

Sascha


----------



## SE (9. Juli 2011)

*facepalm*

Ich sage jetzt mal NICHTS zu der Tatsache das sich das auf das *OPEN* JDK bezieht.

*Wenn du schon so ne "witzige" Signatur hast solltest du dir auch langsam mal angewöhnen das nicht alle "ALLWISSEND" sind um zu wissen das du dich bei deinen Aussagen aufs OpenJDK beziehst ... aber schön zu sehen das du scheinbar auch nicht wusstest das ich mich eben NICHT aufs OpenJDK beziehe ... womit deine Signatur widerlegt wäre.*


----------



## zerix (9. Juli 2011)

Naja in deinen Kopf kann ich dir leider nicht reinschauen. ;-)
Ich hab allerdings auch leider nicht alle Beiträge durchgelesen, da ich vorhin noch unterwegs war als ich geantwortet habe. 

Aber auch sehr interessant, dass du zu allem einen Spruch hast. ;-)

Gruß

Sascha


----------



## genodeftest (9. Juli 2011)

b147 ist der Release Candidate


----------



## javaDeveloper2011 (11. Juli 2011)

Hi zusammen,

ich freue mich zwar über die neuen Möglichkeiten - auch wenn Closures nun nicht mit dabei sind - aber ich befürchte biss man es wirklich von den Usern verlangen kann, ist noch ne Weile hin.
switch mit String ist zwar keine so große Veränderung, wird aber wohl oft nützlich sein.

javaDeveloper2011


----------



## sheel (11. Juli 2011)

Hi

ein bisschen OT, aber:
Was kann man denn als Programmierer überhaupt "verlangen"?

Im OpenSource-Bereich gibts zu den meisten Programmen Alternativen,
auf die ein unzufriedener Benutzer umsteigen kann.
Und im Kommerziellen hat noch immer der Chef bzw. Kunde das letzte Wort.
Sicher kann man empfehlen, auf etwas neueres umzusteigen,
aber wenn er einfach nicht überreden lässt?
Wenn man für siene Arbeit auch bezahlt werden will, muss man wohl mitspielen.

Etwas wirklich verlangen kann man nur dann, wenn die gesamte Konkurrenz mitmacht...

Gruß


----------



## javaDeveloper2011 (11. Juli 2011)

Hi sheel,

mit "Verlangen" meinte ich einfach dass bei Open-Source eine annehmbar große Zahl an Usern mein Programm ausführen können ohne dass weitere Installationen nötig sind.

Gruß


----------



## SE (11. Juli 2011)

Naja und mein "Verlangen" bezog sich auch nicht auf OpenSource-Software für Leute die Ahnung von soetwas haben. Mein "Verlangen" bezieht sich eher auf CloseSource Software bei der man das Risiko trägt das potentielle User die sich einfach nicht zum Update bewegen lassen diese Software halt nicht nutzen können. Außerdem gibt es bei Java einen großen Pluspunkt beim Thema Versions-Update : Software welche für ältere Versionen geschrieben ist *funktioniert trotzdem*.

Natürlich ist es in der [ironie] freien [/ironie] Marktwirtschaft wichtig auf die Wünsche des Kunden einzugehen ... und es mag auch stimmen das ein Kunde vom Entwickler "verlangen" kann für eine ältere Version *so lange noch vertretbar ... was im Falle von Java allerhöchstens Version5.0 wäre ... drunter würde ich auf keinen Fall mehr gehen* zu entwickeln ... so lange der Preis stimmt. Aber ich finde auch gerade um die Konkurenz auszustechen sollte man auf die Vorteile hinweisen welche ein Versions-Upgrade mit sich bringt *String für switch-case wäre nur ein Beispiel* ... denn schließlich wäre man so der Konkurenz diesen Schritt vorraus ... und das bei "gleichem" Preis. Du siehst also worauf ich abziele oder ... ?


----------



## genodeftest (11. Juli 2011)

Was man sicher nicht vergessen sollte: sämtliche gängigen "stable" Linux-Distributionen werden sich noch einige Monate/Jahre Zeit lassen, auf Java 7 umzusteigen. 
Beispiel Debian: Debian ist eine der "großen" Linux-Distributione und hat einen Veröffentlichungszyklus von ca. 2 Jahren. Das letzte Release (squeeze) war am 6.2.2011, das nächste wird also für 2013 erwartet. Vorher wird Java 7 (offiziell) keinen Einzug in Debian finden.
Ähnliches gilt bei Ubuntu: Das nächste LTS (Long Term Support)-Release von Ubuntu wird Version 12.04, also im April 2012 erscheinen.

Was man auch nicht vergessen sollte: einige Firmen (und vereinzelt auch Privatanwender) werden noch lange nicht auf Java 7 umsteigen, denn: "Never change a running system"


----------



## zer0 (12. Juli 2011)

Also ich bin sehr heiß auf Java 7. Vorallem weil endlich Fenstertranzparenz einzug in die API genommen hat und man keinen Umweg mehr über AWTUtilities gehen muss!


----------



## oneof6 (12. Juli 2011)

Naja, 

ich frag' mich ehrlich gesagt, wie's mit JAVA in Zukunft weitergeht...Oracle ist ein Wirtschaftsunternehmen und will Geld verdienen. Die bieten ja jetzt schon eine kostenpflichtige VM an. Hoffentlich wird die freie VM nicht irgendwann zu einer Lite Version degradiert und um was anständiges zu machen, benötigt man dann die kostenpflichtige?
Was Java 7 angeht, werd' ich mir's mal anschauen, allerdings entwickle ich immer noch voll kompatibel zu 5.

Well...time will tell!


----------



## genodeftest (13. Juli 2011)

Laut heise.de wird es vorerst offiziell kein Java7 für Mac OS geben:
http://www.heise.de/developer/meldung/Java-7-auf-Mac-OS-X-installieren-1278721.html

Wer will, kann es aber trotzdem installieren:
http://raibledesigns.com/rd/entry/installing_openjdk_7_on_os


----------



## SE (13. Juli 2011)

Wow ... super Beitrag zum Thema. Das es offiziell erstmal kein JDK 7 für Mac geben wird weil es an den Verhandlungen scheitert ob es nun OpenSource werden soll oder nicht ist schon ganz schön krass. Aber wenn man sich vorstellt das es Oracle mal in Erwähgung siehen könnte Java konstenpflichtig zu machen *ich bin sicher dass das kommen wird* dann wäre das ein Anzeichen dafür das es wirklich so kommen könnte.


----------



## genodeftest (14. Juli 2011)

Ich kann mir ehrlich gesagt nicht vorstellen, dass Oracle Java kostenpflichtig macht. Sie werden natürlich weiterhin eine kostenpflichtige JVM anbieten (das hat Sun auch schon gemacht), aber Java SE (OpenJDK) wird nicht kostenpflichtig werden, das verbieten schon die Lizenzbestimmungen.
Und wenn... Es gibt um Java so viel Industrie- und Hobbyprogrammierer, dass man innerhalb weniger Tage ein alternatives Projekt auf die Beine stellen würde, das in kürzester Zeit besser ist, vgl. OpenOffice vs. LibreOffice.


----------



## Technoblade (14. Juli 2011)

Ich glaube um ehrlich zu sein, dass es, vorrausgesetzt man stellt es richtig an, sogar marktwirtschaftlich gut sein kann Java kostenfrei zu belassen.

Denn gerade dadurch, dass Java so frei und offen ist hat es in so vielen Bereichen Einzug gehalten. Denn durch das kostenfreie ist es jedem der will möglich in Java zu programmieren. Dadurch steigt das Angebot an Programmen und somit auch der Bekanntheitsgrad von Java allgemein.

Unter diesen Umständen wäre es dann ggf. marktwirtschaftlich sinnvoll die JVM für eine komerzielle Nutzung kostenpflichtig zu machen. Das würde weiterhin eine sehr hohe Zahl an Hobby-Programmierern, zu denen hier denke ich sehr viele zählen, zulassen.


----------



## genodeftest (14. Juli 2011)

Genau so sehe ich das auch.
Dadurch, dass Java kostenfrei ist, hat sich einiges an kostenloser Literatur (z.B. Java ist auch eine Insel, Tutorials, Foreneinträge, ...), aber auch kostenpflichtige Literatur (v.a. Bücher) gebildet, was die Sprache selbst wertvoller macht. Wäre Java kostenpflichtig, gäbe es weniger Autoren, die darüber schreiben, weniger Programmierer, die Java nutzen und damit auch weniger Nutzer, die Java installieren. Auf diese Abwärtsspirale wird sich Oracle kaum einlassen.


----------



## SE (14. Juli 2011)

Öhm ... Sun hatte damals bereits schon ne konstenpflichtige VM angeboten. Das wusste ich bis jetzt ja noch garnicht *erstaunt*.
Aber wo man ganz klar unterscheiden muss ist : JavaSE != OpenJDK
Im OpenJDK sind viele Klassen und Namensräume von sun.* und com.sun.* in die offenen Namensräume umgesiedelt wurden. Dementsprechend wurden natürlich auch alle Klassen die darauf zugreifen geändert. So kann es sehr schnell zu Kompatibilitätsproblemen führen wenn ich z.B. in meiner Klasse Aufrufe nutze welche so zwar auch im OpenJDK verfügbar sind ... aber durch den expliziten Namensraum sun.* oder com.sun.* hätten wir ganz schnell RuntimeExceptions.

Desshalb bin ich auch der geteilten Meinung dass das "normale" Java SE kostenpflichtig wird und nur das OpenJDK auf Grund seiner Lizenzen kostenfrei bleibt.

Gerade bei Reflections welche explizit auf sun.* Klassen zugreifen wird das sicher spürbare Probleme geben.


----------



## genodeftest (14. Juli 2011)

Auf Klassen in den Paketen sun.* und com.* (aus der Java SE API) sollte man auf gar keinen Fall zugreifen. Das steht so in jedem (guten) Java Buch/Tutorial und wird auch von Sun/Oracle so propagiert. die Pakete sun.* und com.* sind nicht in der Spezifikation der Java SE enthalten, sondern nur eine Implementierung der Java SE API (die bei OpenJDK nun mal anders ist – wie bei den anderen JVMs wie J9 (IBM) und JRockit (Oracle), IcedTea, CACAO, Kaffe, ...)

Das OpenJDK ist vollständig Java SE -kompatibel, es entspricht voll den vorgegebenen Standards. Wenn du aus den o.g. Paketen Klassen/Interfaces benutzt, musst du damit rechnen, dass dein Programm auf anderen JVMs fehlerhaft bis gar nicht läuft und Oracle die interne Implementierung jederzeit ändern kann und darf – auch in Sicherheitsupdates/Bugfixes.

und wegen der kostenpflichtigen VM von Sun: da habe ich mich getäuscht, es gibt/gab wohl keine.


----------



## SE (14. Juli 2011)

Hmm ... meine sorge liegt hier ganz besonders auf URLClassLoader.close()
Ich habe mal an anderer Stelle gepostet wie man das auch unter Java6 lösen kann ... wofür man aber mit Reflections auf Klassen in sun.* zugreifen muss. Ich habe jetzt bei meinem letzten JDK-Intall das src.zip leider nicht mitinstalliert ... aber ich glaube das es fast genau so auch im offiziellen jdk7 gelöst ist wie ichs mal im Netz gefunden habe.

Wenn man jetzt allerdings in Java7 nur URLClassLoader.close() aufruft sollte es eigentlich egal sein wie die VM das implementiert solange es zum Erfolg führt.


----------

