[FIXED] LWJGL 2.8.0 doesn't work with Scala

Started by escalate, October 11, 2011, 15:21:57

Previous topic - Next topic

escalate

Hi,

I tried to upgrade from LWJGL 2.7.1 to 2.8 using the official lwjgl-2.8.0.zip from sourceforge but the Scala Compiler (2.9.1) refuses to compile my projects because opengles.PixelFormat$Attrib is missing.
I don't need or use OpenGL ES but opengl.Display seems to depend on opengl.PixelFormat.

Exception from Scala Compiler:

java.lang.AssertionError: org.lwjgl.opengles.PixelFormat$Attrib
       at scala.tools.nsc.symtab.classfile.ClassfileParser$$anonfun$enterOwnInnerClasses$1.apply(ClassfileParser.scala:1130)
       at scala.tools.nsc.symtab.classfile.ClassfileParser$$anonfun$enterOwnInnerClasses$1.apply(ClassfileParser.scala:1127)
       at scala.collection.mutable.HashMap$$anon$2$$anonfun$foreach$3.apply(HashMap.scala:102)
[...]

Mickelukas

I had the same kind of issue with the lwjgl-debug jar (not usable anymore due to the opengles part missing). maybe it's possible to only compile the normal jar?

escalate

I didn't use the lwjgl-debug.jar, just the normal one.

Now I tried lwjgl-debug and I have the same error as you because PixelFormat is not found in lwjgl-debug.


spasi


escalate

I have a different error with nightly build #1385 now, PixelFormat depends on EGLDisplay:

error while loading PixelFormat, Missing dependency 'class org.lwjgl.opengles.EGLDisplay', required by lwjgl-2.8.1/jar/lwjgl.jar(org/lwjgl/opengles/PixelFormat.class)

spasi

The situation with OpenGL ES is problematic and I could not find a clean solution. At least without major refactoring and API breakage. Hopefully this mess will be sorted with LWJGL 3.0.

Try the next build, it should be fine now.

princec


spasi

No, the debug build had a similar but unrelated problem. It seems the issue here is that the Scala compiler is too eager with resolving classes. A simple solution would be to include the whole GLES package with the normal LWJGL distribution, but I think I've managed to avoid that, for now. It's a hacky solution to a hacky architecture, only a non-backwards-compatible restructuring will provide a clean fix. The current codebase has more serious problems than this anyway.