We Keep Coding

LWJGL GLFW hangs on native glfwInit call

I originally posted this question on GameDev stackexchange however I'll also ask the question here to try and get more outreach, especially since I wasn't sure my problem was specific to game development since it's a problem with a Java native call.
For the past months I've been working on creating my own game engine for personal use in LWJGL using pieces here and there, especially from developer ThinMatrix's rightfully credited code, to learn as much as I can while building it. Only recently there has been strange behavior happening when I launch the engine from IntelliJ for testing:
After about 6-10 individual times I click run, all subsequent runs suddenly take about 60 seconds for the window to appear.
Whenever I restart my PC this hanging resets and I have another 6-10 runs before it hangs everytime again.
I located the issue to glfwInit, more specifically at the call to the native method:
#NativeType("int")
public static boolean glfwInit() {
long __functionAddress = Functions.Init;
return invokeI(__functionAddress) != 0; // Right here
}
I also noticed that this issue only started when I attempted to implement text support in my engine using the STBTrueType library. It was perfectly fine before that. I tried removing the TrueType code but it didn't fix it.
Here's a list of things I've tried:
Clearing my temp folder in case a buggy or corrupted file was present.
Recompiling and rebuilding the entire LWJGL jars twice.
Building glfw.dll from the GLFW sources and replacing the glfw.dll in the native jars with the former.
Reinstalling Java and actually upgrading JDK versions (from 13.0.2 to 14.0.2)
Switching IDEs even if I suspected it wouldn't work.
Updating my NVIDIA drivers, and reinstalling them.
I'm quite confused as to what it could be, and I'd be more than happy to share code, thread dumps, or debug info if you deem it necessary. Here is the Github repository with the latest, "faulty" code (fault in quotes because I'm not too sure the code is the problem.)
Thank you very much for any guidance.
P.S: Please tell me if this is better asked in StackOverflow instead of here.

So I fixed the issue, it turns out it wasn't even related to anything to do with programming, or STBTrueType, or the library itself. The problem was as pointed out in this StackOverflow post, where this hanging behavior was due to a faulty driver or, in my case, my keyboard USB being plugged in the "wrong" USB port. I moved my computer at the same time I started working on text in my engine, hence why I wrongly linked the issue with the TrueType library. If you're having the same issue, look at the aforementioned post or if that doesn't work, look for a peripheral that might cause interference.

java 8u31 plugin causes signed applets to load much slower

i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.
To reproduce the issue i did this:
I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (e.g. 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....
Has anyone else seen something like that?
It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.
I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help,
TIA

Same here. I thought already I'm getting crazy. Thanks for sharing this.
We are using Java Web Start, but it's sharing the same problem of re-indexing all jar files (in our case it's an app with quite some jars, so starting takes ages).
Aside from the fact that Oracle suddenly decided to check the certificate of the deploy TLS, which caused some hickup on Linux and Macs (we used a StartSSL certificate there, which isn't included in the Java keystore - on Windows it works as it uses the platforms root certs, too).
And, to make it even worse, on Windows x86 the 8u31 silently dies if -XX:+DoEscapeAnalysis or -XX:+OptimizeStringConcat is present in the JVM arguments, though both parameters are standard in Java 8 (but not in 7, that's why they've been included, still). The 64bit engine doesn't have that problem.
The next thing they changed is they now overwrite the start icons if they've been changed (we changed them to put the 64bit engine's path in there), so it stubbornly changes the path back to the 32bit engine every time.
The behaviour of Oracle is not helpful at all, as they didn't announce any of these changes in their changelogs, let alone announcing the certs changes a few days ahead.
I would like to hear from anyone who's sharing the problems and possible workarounds.
Patric

Have you been able to solve this issue? Have you had a reaction from Oracle?
UPDATE START
I've tried everything I can think of and haven't managed to solve the
issue, so I posted my own question on this issue.
A similar bug report can be found here and is backported to at
least Java 8u51 which I tested. Yet again they managed to increase
startup time for our application.
END UPDATE
We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed.
Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:
7u?? (<60): +2s (10s)
7u60: +5s (13s)
7u75: +15s (23s)
8u31: +12s (20s)
8u40: +21s (29s)
8u51: +23s (31s)

Have you tried your jnlp without versioning? In my experience Java jnlp is very buggy specially if you change the jnlp default values. Versioning support is disabled by support, so try it without versioning and see if it still slow?
For me, I noticed some bugs when I used update="background" value, so I no longer change the default update method. My theory is that Oracle only tests jnlp against default values before they release new Java versions.

Truncation of web socket chunk while uploading a file

I have tried searching for this strange issue I am facing but could not find anything on web.
Following is what I am trying to do.
Upload File from User browser to Play server running on some different environment
Following is the issue I am facing.
The chunk is getting truncated before reaching to Play server
Observations:
Chunk is created at client side properly from java script and websocket.send() is passing proper chunk to Play.
On Play server, the chunk is coming as a String event object which is truncated.
Very strange thing about this problem is This is happening only from some machines/networks, for all others it is working fine
When tried with different chunk size, it has been observed that for smaller chunks many of initial chunks gets received properly and later one fails
We have tried bypassing Firewalls and Proxies as well on some network to check what happens if there are no such restrictions, but it is still failing
Please give your inputs which can help me debug this and fix this. Any additional things you want I can provide, not pasting code as it is working on majority of machines and networks but failing on a few, so it does not seem to be a code issue
PS. This question can have many answers based on people's views, to all SO users, I just need help on what could be the thing which can go wrong, so please do not flag this as inappropriate

I have figured it out, the issue was with latest update of google chrome. I downloaded the chrome from here (Version 37) and it started working fine.
I came to know after a period of time that this issue was because of the implementation changes in chrome V38 for multiple frames for single message, initially it was getting transferred in a single frame so ultimately the implementation from your server side also need to be changed in order to handling the same.
I was using older version of Play framework which wasn't having this multiple frame handling implementation so it was breaking.
After updating Play to 2.2.3 it started working properly as they have implemented multiframe handling in that version. Some useful links below
Issue With Latest Chrome
Play Changelog
Changes for Continuation frame handling for WebSockets in Play 2.2.3

jzlib 1.0.7: ArrayOutOfBoundException in ZOutputStream.write()

I have a simple test case producing a sure ArrayOutOfBoundException in jzlib
1.0.7 depending on the data subsequently written to one and the same instance
of ZOutputStream.
Stacktrace:
java.lang.ArrayIndexOutOfBoundsException: 587
at com.jcraft.jzlib.Tree.d_code(Tree.java:149)
at com.jcraft.jzlib.Deflate.compress_block(Deflate.java:691)
at com.jcraft.jzlib.Deflate._tr_flush_block(Deflate.java:897)
at com.jcraft.jzlib.Deflate.flush_block_only(Deflate.java:772)
at com.jcraft.jzlib.Deflate.deflate_slow(Deflate.java:1195)
at com.jcraft.jzlib.Deflate.deflate(Deflate.java:1567)
at com.jcraft.jzlib.ZStream.deflate(ZStream.java:133)
at com.jcraft.jzlib.ZOutputStream.write(ZOutputStream.java:102)
at com.jcraft.jzlib.JZLibTestCase.main(JZLibTestCase.java:51)
at JZLibTestCase.main(JZLibTestCase.java:28)
The problem occurs very rarely and depends on the data subsequentially
written to an open ZOutputStream from jzlib.
Do you have a hint how to fix this? Have you ever heard of this?

Near as I can tell you might've found a bug with JZlib. While searching around I came across other places that have your post with attached source and data files. It does not appear that you're doing anything wrong. You should be able to stream any sequence of bytes to ZOutputStream.
Is there a particular reason you're using JZlib? The two main reasons I understand to use it are support for Z_PARTIAL_FLUSH mode and licensing. If you don't need that flush mode and you're using the Oracle JVM, you should be just fine with the included DeflaterOutputStream. Substituting it in your code for ZOuputStream works without an exception.

I haven't found a concrete reason for using jzlib asking my co-workers, but for sure there has been a bug using java.util.zip somewhen in JRE 1.4 on multi-processor systems, although no one has been able to tell me concretely which one. From that time on we have been using jzlib, which has worked good for many years. Most probably it is already fixed. Nevertheless, using java.util.zip works with my simple test data in the same manner jzlib failed with, that's true.

Dependency on 3rd party at runtime?

We have created an applet with javafx and it seems that in order to load the applet several jar, jnlp and js files are required to be downloaded from dl.javafx.com. I tried to work out which files were needed so I could host them on our own server but after spending an hour or so on it I got tired of reading code and gave up. Doesn't it seem bizarre that to use javafx the client has a dependency on the javafx server? There was an instance a few months ago where their server was down which is completely unacceptable. I feel like scrapping it and starting again in something else but I can't throw a years work away.
What are everyone else's views? Have you experienced/solved this? Any suggestions where I should go from here will be gratefully accepted.

This issue has come up a few times and it is one of the main gripes people have with JavaFX. There is a dependency on the runtime, however I believe it is technically possible to distribute an app "offline" (though I've never tried it). See here and here.
I am not sure whether or not it is a breach of the license to distribute offline.
I have sympathy with your frustration, but I would argue that it would not be worth scrapping a year's work. I imagine the uptime of the Oracle servers would be no worse than any outage that could be expected of any web application.