Google und Oracle stehen immernoch vor Gericht und noch immer geht es um Urheberrechtsverletzung der Java “API”.
Ich habe mit OpenJDK nie gearbeitet aber ich gehe mal davon aus dass die API auch bei OpenJDK genauso wie bei Dalvik zum offiziellen JDK die gleiche ist?
Damit wäre vor Gericht auch keine Ruhe und Android würde immernoch auf Java 6 sitzen bleiben.
Da Oracle aber nicht gegen das OpenJDK klagt muss es sich um ein anderes Interface handeln und dann wäre meine Frage: Ist das OpenJDK noch Java?
Ich habe immer mit Oracle JDK gearbeitet, weil das OpenJDK teilweise inkompatibel ist bzw. Probleme bei der Programmausführung macht. Daher war es immer eine der ersten Arbeiten, die ich auf einem frisch aufgesetzen Ubuntu gemacht habe, das OpenJDK rauszuwerfen und das Oracle JDK zu installieren.
Naja, auch wenn das OpenJDK als “offizielle Referenzimplementierung” behandelt wird, so gibt es halt abgesehen von der in der API beschriebenen “grundlegenden” Klassen im Hintergrund halt Vendor-Spezifische implementierungen. Ist ja z.B. auch ein Grund dass es noch zu Zeiten als die IBM und M$ -VMs verbreitet waren für sehr spezifische Anwendungsfälle immer Kompatibilitätsprobleme gab.
Ich hab jetzt nicht nachgesucht, aber ich denke dass man die Pakete wie com.sun in einer IBM (vermutlich com.ibm) und M$ (com.M$ oder sonst irgendein Schrott) vergeblich suchen wird. Darum ist ja gerade bei Reflections oder Zugriff auf VM-Spezifische Details immer Vorsicht geboten.
Sollte man daher bewusst “gegen” (im Sinne von "gegen ein Interface/API) programmieren, die eigene Impl bevorzugen oder sich nur auf SE-API beschränken und den Rest im versteckten Hintergrund machen lassen? Gerade wenn ich an eine für mich wichtige Änderung mit Java 7 und dem URLClassLoader denke, dass dieser seit Java 7 endlich public auch Closeable anbietet, was man vorher durch “Hacks” über Refelctions mit sun.*-Klassen machen musste, dürfte doch damals bei App-Servern, die ja das dynamische entladen schon vorher anbieten mussten, sicher schon von vorher einiges an Eigengemurkse gegeben haben (gab mal irgendwo “drüben” einen entsprechenden Thread worum es genau darum ging und dann halt die Antwort kam: “App Server müssen sowas können”, und auf die Rückfrage “Wie?” nur “Implementierungsdetail” kam).
Naja, was halt die SE-API nicht hergibt muss man entweder über native oder halt Vendor-Spezifisch implementieren.
Sollte es darum ein “geschlossenes” System wie bei DotNET geben wo es halt nur M$ und keine andere Implementierung gibt? IMO definitiv NEIN!, aber mit OpenJDK und der dadurch vorhandenen “kompletten” Referenzimplementierung geht man schon mal den richtigen weg. Jetzt muss man dies nur noch als “Standard” durchdrücken, so dass die Oracle-VM als “Nebenprojekt” exisitiert, und nicht umgekehrt wie es aktuell der Fall ist.
Bzgl. des Lizenz-Chaos und Linux, na dass wird sicher noch ein paar Jahre brauchen. Und ich wette jetzt schon darum dass irgendwer auch in einer “freien” Implementierung sicher wieder Ansprüche erheben wird.