LWJGL 3 debug output gives pointer to string

[theagentd]

The callback from GLDebugMessageARBCallback looks like this:

public void invoke(int source, int type, int id, int severity, int length, long message, long userParam)

Am I supposed to somehow retrieve the message from that pointer manually or is this an oversight? I would really prefer to get a String object instead.

[theagentd]

Never mind, found this: http://forum.lwjgl.org/index.php?topic=5811.0

[Mickelukas]

While it's nice that LWJGL 3.0 is using a more or less raw version of OpenGL and that GLFW gives more direct access to the hardware it made it a lot more complicated. While it isn't supposed to be drag and drop as it is a programming library it used to be a lot easier to explain than it is nowadays.

[spasi]

I'm afraid in this particular case I had no choice but go with the lowest-level option. We want to have a single method (for lambda compatibility) and we want flexibility/performance at the same time. Only the low-level interface provides that. If LWJGL 3 could afford to drop Java 6/7 support and require Java 8, we could have done something better with default methods.

it used to be a lot easier to explain than it is nowadays.

I would argue that LWJGL 3 is a lot more consistent. If you get a good grasp of the basics, you can understand everything in the library.

[abcdef]

Would it not be possible to provide a function that wouldn't lose the single method methodology but also remove the low low level stuff that most of us are not interested in?

An example would be

public void invoke(int source, int type, int id, int severity, int length, long message, long userParam)

Becoming

public void invoke(int source, int type, int id, int severity, String strMessage, long userParam)

Where

String strMessage = memDecodeUTF8(memByteBuffer(message, length));

Is injected before the method is returned to the end user so that is already per converted?

I'd like to add I know nothing of how this method is actually implemented so I am asking very much from an "is it possible" perspective.

[spasi]

Yes, it is possible, but you lose the flexibility/efficiency part.

For example, say a user wants to log any output to a file. With String in the signature, you're forcing deserialization from UTF-8 to char[], then serialization again to the UTF-8 file (plus the GC overhead). With the raw pointer, you can do it with zero overhead.

Another issue is text encoding, which is not specified in the spec. I used UTF-8 here, which covers ASCII, but it could be anything I guess. With a String argument you're stuck with whatever LWJGL implements. With the raw pointer, you can use ASCII decoding for efficiency or anything else if UTF-8 happens to produce garbage. This is the reason why "unsafe" function versions are publicly exposed in LWJGL 3: if LWJGL does something stupid, in any API and any function, you can be sure that you will be able to implement a workaround without having to wait for LWJGL to fix it.

In any case, what I would like to do, after LWJGL 3.0 is released and if it turns out to be as stable as I hope it will be: a fork that will be maintained in parallel with the original library, but refactored for the latest official Java release. That means Java 8 now and it would make callbacks very friendly. There are a few things that could also be supported once Java 9 is out (e.g. VarHandles). By the time Java 10 is out, we could move the official library to Java 8 and the fork to Java 10/Project Panama.

[Cornix]

Can you not simply add your own custom LWJGL callbacks that are more user friendly and hide away the GLFW stuff?
You would still expose the raw GLFW interface, but you would provide an additional LWJGL interface on top of that for ease of use. How does that sound?

[SHC]

I also went with the Cornix's option, and wrote a completely object oriented wrapper on the glfw calls for the entire GLFW api. I think you can make use of the window class and the callback interfaces from that.

https://github.com/sriharshachilakapati/SilenceEngine/tree/master/src/main/java/com/shc/silenceengine/core/glfw

[spasi]

Lets move the discussion here.