A roadmap for Minie Physics

I’m on Java 13 with several warn on reflect used by jme (but it’s not the subject)

1 Like

I’m aware of the warnings, thanks.

I use 11 but maintain compatibility for 1.8 just because not everyone is on 11 yet.

1 Like

Same for me. I use 11, but set the source compatibility in Gradle to 1.8

1 Like

I assume most developers are using Minie class jars, not building from source. So I believe target compatibility (not source compatibility) is what matters.

4 Likes

I am also using Java 11+. (Currently Java 14 at runtime)

1 Like

Stephen I have a requirement for max Java 1.8.0_45 because of hardware limitations of some of the end stations. I work with educational institutes and they don’t upgrade their hardware frequently.
It will be great if you preserve Java 8 compatibility.

2 Likes

What about android?

1 Like

A rhetorical question, I’m sure.

So. What about it?

It requires a max version of 8.

1 Like

I think he’s referring to the fact that android requires java 8 or less.

2 Likes

I have my answer, then. Since there’s significant market that doesn’t support Java 9, the new native-object management system will use phantom references.

2 Likes

I’m curious to know which computer doesn’t support Java 9. My main computer was assembled in 2007 and it runs OpenJDK 14 flawlessly.

1 Like

It is about the operating system. I used to stumble upon these really old Windows servers in my work, some of them were even still on some extended support period. But you couldn’t install any recent Java on them. Not supported by the JRE/JDK anymore.

AdoptOpenJDK works under Microsoft 2008 Server. In the worst case, you have to use the compressed archive instead of the installer, this isn’t a big deal.

It’s a bit sad to stick to Java 8 because of Android but maintaining two flavors would be annoying too. The Java Stream API has some fixes in later versions that weren’t backported in OpenJDK and Oracle JavaSE 8 :s

Yes, hopefully, it is going to be solved when this project gets out. (That is using GraalVM compiler)

3 Likes

Yes, I know GraalVM, it’s extremely promising, it’s even able to use a polyglot API to communicate with WebAssembly but I’m sure that you’re aware using it under Android is very tricky. When it’s more mature, it will be very useful with all Java engines with AWT-free UIs (that’s why I try to implement full NEWT support in each backend when possible) and to bring Java back to the browser without applet support.

1 Like

Yes, very very tricky. But all in good time I hope it gets better.

1 Like

For example HP ProBook 4330s. Try running JME3 based app on in with Java greater than 1.8.0_45 and you will get a run-time exception about OpenGL pixel format or something. The only way to solve it is to downgrade Java. Again, you can run Java greater than 8 but JME apps will not run and it’s not just a matter of updating the driver

@adi.barda It’s a known problem which was most loudly reported by Minecraft players and it has several “solutions”, none are fully satisfying to me because Intel should have fixed its driver, you get this exception because this Intel OpenGL driver crashes under Windows 10 with any OpenGL software marked as “Windows 10 ready” which forces Microsoft Windows to use its crappy Microsoft GDI Renderer instead. These are the possible “solutions”, maybe I miss one:

  • downgrade to Microsoft Windows 8 (so that you use an Intel OpenGL driver that just works as is)
  • downgrade to Java 8 update 45 (so that your software doesn’t use the broken path in the driver)
  • patch Java (so that your software doesn’t use the broken path in the driver)
  • install another graphics card with a working OpenGL driver
  • use Mesa OpenGL driver under Windows 10
  • use GNU Linux (so that you use an OpenGL driver for this chip that still works like a charm)
  • patch the Intel OpenGL driver (to fix or avoid the broken path)

In my humble opinion, it depends on your constraints but my two last solutions are the least painful ones. Using an obsolete operating system or an obsolete version of Java isn’t a satisfying solution for me. I advise you to go to Minecraft bug tracker on Github, a nice guy created a small software to patch most of the faulty drivers.

Yes, your hardware supports Java 9, the Intel OpenGL driver (which is a piece of software) doesn’t. I don’t blame you but I spent weeks (maybe months) in implementing at least 2 render quirks in JOGL, it’s not a very rewarding task, I don’t find it interesting to code and some organizations simply refuse to update their drivers. I don’t find reasonable to ask for Java 8 support for a software incompatibility with Java 9 that can be solved by another mean. By the way, most solutions above are probably known by the maintainers of the OpenGL binding you use with JMonkeyEngine, it’s not up to JMonkeyEngine to take care of this kind of problems and if Intel had done the right job, we wouldn’t even be talking about that now, please remember it when buying yet another laptop or desktop computer under Windows with an Intel GPU.

2 Likes