at spgl3.game.Display.init(Display.java:83)at spgl3.game.DisplayTest.main(DisplayTest.java:7)

Running OpenJDK11 (Zulu 11.2.3) on Windows 10 64-bit, LWJGL, LWJGL 3.2.2 SNAPSHOT build 1.Basically it's the first thing I've tried to do and it ain't working. With -noverify it gets past this problem but then I get this, using the various windows-natives jars on the classpath:

Hmm yes. So I went down the whole route of trying to make all my projects in Eclipse into JDK11 modules again and ... the module system just doesn't work. It just does not work. It's obscure, complex, and opaque. One can no longer simply browse stuff to see how it fits together. I think it's the worst thing to have happened in the entire history of Java, solving a problem only a tiny, tiny minority of developers actually had at the expense of making a huge, complicated problem for everybody else.

I've reverted back to the released LWJGL and removed all the module bullshit, and I've finally got it to run at 2am. It must have been picking up some strange classpath stuff somehow but as I've never installed LWJGL3 on this machine before I am baffled as to how it was getting mixed up versions. Four hours just to get a window to show!

I still can't get it to work with just the native jars in the classpath - I have to extract and use -Djava.library.path - but I'm fine with that and honestly I think it's a better solution.

Thanks for the reply Spasi... probably going to have a few more questions over the next week or so as I finally migrate 15-year old tech...

It's very likely that the issues you faced were caused by Eclipse itself. I don't know if there's been a recent release that's supposed to fix the support for modules, but so far Eclipse has been a constant source of trouble since Java 9. Things that are easy and simple with modules, become impossible in Eclipse because of bugs in the IDE. My recommendation has been: configure the Eclipse project to use the classpath for everything and maybe build releases of your program with Maven/Gradle/etc., if you need jlink or the (theoretical?) benefits of modules.

In general, I would also recommend exploring the various new java/javac parameters and new utilities (jdeps/jlink/etc.) that come with the JDK. There are many ways to diagnose issues that haven't been yet exposed in any IDE afaik.

I still can't get it to work with just the native jars in the classpath - I have to extract and use -Djava.library.path - but I'm fine with that and honestly I think it's a better solution.

Extracting the natives is fine if it matches your workflow and build process. However, using the classpath is very convenient and I haven't heard of issues related to the automatic extraction lately. Could you please try again with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true and attach the output here?

This is the sort of random shit that Eclipse / JDK11 is pulling on me constantly. Nothing seems to work properly for no well-explained reason. If I go and make a cup of tea, something else breaks, or something else starts working. Eclipse is proving infuriating and I'd ditch it if I weren't already so totally fluent in using it in every other way. Looks like I'll have to wait a couple of years for them to get their act together.