Forum Discussion
JOVR / Java bindings?
Just dusting off my Rift to have another play with some Java OpenGL. I feel more motivated now we have some specs and direction at last. :) Although I'm wondering if Java is still a good choice now ...
I was on vacation when the 0.5.0 SDK was released. When i got back I discovered two things.
First, the 0.5.0 API was virtually identical to the 0.4.4 API (I think one flag was removed). Second, that the new C API was esentially a shim which located the real runtime library and loaded it, and then proxied all the function calls to it. This is similar to how something like GLEW works. Since this is essentially also how JNA works, this means there's no longer a good reason to embed the OVR DLL inside the jar. Instead, the more sensible thing to do would be to replicate the logic the SHIM uses to find the JAR and load it out of the runtime installed location. However, this was a non-trivial amount of work, I've just changed jobs to work with a VR oriented startup and 0.4.4 still worked just fine, so I put it off.
Eventually 0.6.0 was released and while it now has a drastic change in the API it doesn't support support Linux or OSX, so there's less motivation, personally, to do a bunch (more) free work for Oculus.
Now it should be noted that on Windows, the 0.6 API has a bunch of improvement to OpenGL functionality, so it's a worthwhile target if you're on a Windows platform. If you're not on the platform, and want to stick with Java, I'd recommend sticking with the 0.4.4 code, which should continue to work fine with the 0.6 runtime. But if you want Java/Windows/0.6, I can't give you a timeline for when that's going to happen, at least not from me.
First, the 0.5.0 API was virtually identical to the 0.4.4 API (I think one flag was removed). Second, that the new C API was esentially a shim which located the real runtime library and loaded it, and then proxied all the function calls to it. This is similar to how something like GLEW works. Since this is essentially also how JNA works, this means there's no longer a good reason to embed the OVR DLL inside the jar. Instead, the more sensible thing to do would be to replicate the logic the SHIM uses to find the JAR and load it out of the runtime installed location. However, this was a non-trivial amount of work, I've just changed jobs to work with a VR oriented startup and 0.4.4 still worked just fine, so I put it off.
Eventually 0.6.0 was released and while it now has a drastic change in the API it doesn't support support Linux or OSX, so there's less motivation, personally, to do a bunch (more) free work for Oculus.
Now it should be noted that on Windows, the 0.6 API has a bunch of improvement to OpenGL functionality, so it's a worthwhile target if you're on a Windows platform. If you're not on the platform, and want to stick with Java, I'd recommend sticking with the 0.4.4 code, which should continue to work fine with the 0.6 runtime. But if you want Java/Windows/0.6, I can't give you a timeline for when that's going to happen, at least not from me.