Phil talked about his new pipeline for Java3D, I agree with integrating his stuff as it would help Java3D to go on working in better conditions longer but if he gives up, I won't implement a brand new pipeline alone.
There is no point of maintaining tons of scenegraph APIs doing similar things; in my humble opinion, I would be more efficient if I could concentrate myself on fewer scenegraph APIs and if some contributors spent some time in maintaining their favourite ones which is exactly what is happening for LibGDX. As I don't want to favour any API by relying only on my own tastes, I prefer seeing some participations of other developers and I won't try to implement some features in some scenegraph APIs with very serious design flaws when I know that it's extremely hard or impossible to achieve, i.e I won't entirely rewrite Java3D to use directly JOGL canvases and windows and I will probably not allow JMonkeyEngine 3 to support multiple windows. There is no "perfect" API that would fit into everyone's needs:
- JMonkeyEngine 3 is modern, it is very actively developed, it has a huge community and a nice integrated game development environment but it's not the best bet outside gaming especially if you need something very reliable (some developers admitted that they have had to rewrite most build-in shaders for their projects) and supporting multiple windows. Note that it can't work with OpenGL < 2.1
- JogAmp's Ardor3D Continuation is less modern (written with the fixed pipeline in mind but supporting shaders and OpenGL ES), it is developed and maintained (less actively as I'm mostly alone), it has a tiny community but it is by far the most reliable scenegraph API supporting JOGL (the bugs are fixed within days or two weeks in the worst case), it has an excellent support of multiple windows, it's less suited for gaming than for visualization (it has some very useful utilities to write a visualizer including some manipulators and numerous loaders, ply and stl supports are on the way, it has a good OBJ exporter). It works with OpenGL 1.2 to 4.x
- LibGDX is less high level which is an advantage if you look for something lighter but it puts much more responsibility into the hands of the developer, it has a large community but as far as I know it can't work with old OpenGL versions like JMonkeyEngine 3
- Java3D has still a surprising huge user base with tons of examples on Internet but it can't work without the fixed pipeline for now and it has some important design flaws that none of the APIs above has because it was designed with Direct3D and OpenGL in mind instead of fully relying on JOGL
Metal doesn't get any hype in the Java community.
As far as I know, Vulkan support is vaguely planned in LibGDX (but improving OpenGL ES 3 support first is a priority) and JMonkeyEngine (not in the current major version, not a priority). I will improve the support of OpenGL 4 and OpenGL ES 3 in JogAmp's Ardor3D Continuation (not a trivial task) before supporting Vulkan.
Anyway, the JOGL backends of all those APIs will remain maintained. It seems to be difficult to merge JogAmp's Ardor3D Continuation into JMonkeyEngine as they have diverged a lot too much.
Yes the GPU manufacturers can provide the drivers but I'm not sure it would be possible if Apple prevented the install of OpenGL drivers somehow.
Ardor3D != JogAmp's Ardor3D Continuation: the former was abandoned almost 2 years ago whereas the latter is still under development. JogAmp's Ardor3D Continuation already has a partial support of OpenGL ES, it is able to emulate the fixed pipeline thanks to JOGL when only the programmable pipeline is available which means that even its current JOGL renderer is more capable than the one of Java3D, it's particularly useful as some Macs support only OpenGL 2.1 and OpenGL 3 core without the ARB compatibility extension, it will be more useful with drivers supporting only OpenGL >= 3 core.