VerifyError at glfwInit

Started by princec, February 15, 2019, 00:07:32

Previous topic - Next topic
Print
Go Down Pages1
User actions

princec

February 15, 2019, 00:07:32
What's this all about then...
Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    org/lwjgl/glfw/GLFW.glfwGetError(Lorg/lwjgl/PointerBuffer;)I @8: invokestatic
  Reason:
    Type 'org/lwjgl/PointerBuffer' (current frame, stack[0]) is not assignable to 'org/lwjgl/system/CustomBuffer'
  Current Frame:
    bci: @8
    flags: { }
    locals: { 'org/lwjgl/PointerBuffer' }
    stack: { 'org/lwjgl/PointerBuffer', integer }
  Bytecode:
    0000000: b200 0f99 0008 2a04 b800 192a b800 1ab8
    0000010: 001b ac                                
  Stackmap Table:
    same_frame(@11)

	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:

Exception in thread "main" java.lang.ExceptionInInitializerError
	at org.lwjgl.system.APIUtil.apiCreateLibrary(APIUtil.java:122)
	at org.lwjgl.system.Library.loadNative(Library.java:338)
	at org.lwjgl.system.Library.loadNative(Library.java:322)
	at org.lwjgl.system.Library.loadNative(Library.java:239)
	at org.lwjgl.system.Library.loadNative(Library.java:205)
	at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:673)
	at spgl3.game.Display.init(Display.java:83)
	at spgl3.game.DisplayTest.main(DisplayTest.java:7)
Caused by: java.lang.SecurityException: sealing violation: can't seal package org.lwjgl: already defined
	at java.base/jdk.internal.loader.BuiltinClassLoader.getAndVerifyPackage(BuiltinClassLoader.java:852)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineOrCheckPackage(BuiltinClassLoader.java:817)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.defineOrCheckPackage(ClassLoaders.java:211)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:789)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	at org.lwjgl.system.MemoryStack.create(MemoryStack.java:85)
	at org.lwjgl.system.MemoryStack.create(MemoryStack.java:74)
	at java.base/java.lang.ThreadLocal$SuppliedThreadLocal.initialValue(ThreadLocal.java:305)
	at java.base/java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:195)
	at java.base/java.lang.ThreadLocal.get(ThreadLocal.java:172)
	at org.lwjgl.system.MemoryStack.stackGet(MemoryStack.java:764)
	at org.lwjgl.system.MemoryStack.stackPush(MemoryStack.java:773)
	at org.lwjgl.system.windows.WindowsLibrary.<clinit>(WindowsLibrary.java:23)
	... 8 more


So finally I extract the natives from the jars myself and point at them directly with -Djava.library.path and eventually get to...
Exception in thread "main" java.lang.SecurityException: sealing violation: can't seal package org.lwjgl.opengl: already defined
	at java.base/jdk.internal.loader.BuiltinClassLoader.getAndVerifyPackage(BuiltinClassLoader.java:852)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineOrCheckPackage(BuiltinClassLoader.java:817)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.defineOrCheckPackage(ClassLoaders.java:211)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:789)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:700)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:623)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	at org.lwjgl.opengl.GLCapabilities.<init>(GLCapabilities.java:6318)
	at org.lwjgl.opengl.GL.createCapabilities(GL.java:466)
	at org.lwjgl.opengl.GL.createCapabilities(GL.java:322)
	at spgl3.game.Display.init(Display.java:117)
	at spgl3.game.DisplayTest.main(DisplayTest.java:7)


A similar problem to before, and it looks distinctly like something to do with JDK11's brainf*ck module system.

Cas :)

spasi

#1
February 15, 2019, 08:19:01
Hey Cas,

This can only be explained if there are multiple versions of LWJGL in the classpath/modulepath.

princec

#2
February 15, 2019, 09:05:24
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...

Cas :)

spasi

#3
February 15, 2019, 10:50:57
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.

Quote from: princec on February 15, 2019, 09:05:24I 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?

princec

#4
February 15, 2019, 11:31:55
The jars are ... now ... working fine on the classpath.

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.

Cas :)
Print
Go Up Pages1
User actions