Hm. Speziell bei diesem Thema ist das wohl etwas anderes. JOGL/JOAL/JOCL & Co sind Anbindungen von fremden APIs an Java. Und die APIs (ja, auch „meine“) sind üblicherweise ziemlich direkte 1:1-Übersetzungen der original-APIs. Die Art, wie man damit programmiert, läßt einem echten, eingefleischten Java-Programmierer die kalten Schauer mit 50 kHz den Rücken rauf- und runterlaufen Zwar sind die APIs bei genauerer Betrachtung tatsächlich objektorientiert, aber … wie objektorientiert so eine C-API eben sein kann
Soweit ich das bisher (angefangen bei ganzen anderen Bibliotheken die da so kreuchen und fleuchen, über Aparapi und Rootbeer bis Sumatra) mitverfolgt habe, geht es hierbei - also speziell bei dem, wozu im Projekt Sumatra die Grundlagen erarbeitet wurden - NICHT um eine neue API. Und schon gar nicht um eine Bibliothek, die irgendein Wirrkopf sich zur Anbindung einer API aus einer Fremdsprache ausgedacht hat, und die jetzt zum „Standard“ erhoben werden soll.
Stattdessen geht es um eine direkte Unterstützung der GPU aus der JVM heraus. Vollkommen transparent für den Programmierer. Das ganze speziell im Zusammenhang mit der Internen Iteration und den Streams+Collections, die ja jetzt endlich in Java Einzug gehalten haben. Sinngemäß geht es wohl wirklich darum, bei einem Konstrukt wie
void increaseAge(Person p) { p.age += 42; }
persons.parallel().foreach( p - p->increaseAge() }
aus dem „increaseAge“ einen OpenCL-Kernel zu machen, der zur Laufzeit compiliert und dann parallel auf der GPU ausgeführt wird.
(Das sieht jetzt VIEL ZU suggestiv aus - da steckt richtig Arbeit dahinter. Bestimmte Konstrukte gibt es auf der GPU nicht (z.B. Exceptions), andere existieren nur mit sehr eigener Semantik (Synchronisation mit Barriers & Co), und andere sind zwar denkbar, aber extrem schwer nachzubauen (speziell sowas wie Garbage Collection oder Rekursion). Dazu kommt das leidige Problem: Wo liegen die Daten? Auf dem Host („CPU-RAM“) oder auf dem Device („GPU-Speicher“)? Zum Glück arbeitet die http://hsafoundation.com/ daran, das ganze zu … homogenisieren? (pun intended :D))
Ich denke, dass das schon sehr bald ein Killerargument FÜR eine Sprache wie Java werden wird. Einerseits ist klar, dass parallel computing immer wichtiger wird, und es schick wäre, wenn Java das „gut“ unterstützt. Andererseits werden die Geräte, auf denen Programme laufen sollen, immer heterogener: Vom Single-Core-Smartphone über das 4-Core-Tablet und den 8-Core-Desktop bis zum 64-Core-Server, und auf jeder Ebene sind CPUs und „GPUs“ (bzw. irgendwelche Chips) gemischt. Man kann kein Programm schreiben, das für all diese Welten gleichermaßen geeignet ist. Wenn aber die JVM die Verantwortung dafür übernimmt, die zu erledigenden Aufgaben sinnvoll auf alle zur Verfügung stehenden Recheneinheiten zu verteilen, wird „Write once, run everywhere“ wieder aktuell, und ggf. sogar erweitert um ein „…as fast as possible“
EDIT: @Spacerat , wegen Java3D: Ich fand das eigentlich nicht schlecht. Tatsächlich wurde die offizielle aktive Entwicklung eingestellt (oder „an die Community übergeben“, wie es so euphemistisch heißt ;)), aber… vom Ansatz her war es ja nicht verkehrt, zu versuchen, eine Szenegraph-basiete API anzubieten, die mehr „high-level“ ist als JOGL oder LWJGL. Warum es sich nicht wirklich durchgesetzt hat, ist schwer zu sagen. Stattdessen wurden eher Libs wie die jMonkeyEngine populär, was vielleicht (!) ein Indiz dafür sein könnte, dass die Bereiche, in denen ein wirklich breiter Bedarf für so eine Lib bestehen könnte (nämlich Spiele), von Java3D nicht geeignet addressiert wurde (Java3D hat eher Elemente, die in Richtung von „VR-Anwendungen“ gehen, aber über Details könnte man streiten). Dass während der aktiven Zeit von Java3D die eine oder andere Revolution stattgefunden hat (z.B. OpenGL Version 1.1 über 3.2 bis 4.x - wie viel ist da gleich geblieben? Und jetzt noch Dinge wie WebGL…) mag sicher auch dazu beigetragen haben.