Java 7 FINAL Release bekanntgegeben

[Technoblade]

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]

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]

Ö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]

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]

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.