Hello Stackoverflow Community!
I am facing a problem,
when I want to execute my self-written JavaFX runnable Jar file program (it is a Chess game).
When I execute the program it needs about ten seconds to start.
After the start, when I want to select a piece or the menu items there are two possible options:
The Gui freezes completely after startup
I may click on a piece and it needs around 5 sec. to select it and when I want to hover (no self-written event) on the JavaFX menubar, the PI freezes for about 5 sec. and then displays the blue hover color.
I have a Raspberry PI 3.
I have currently installed the Java Environment: ,,openjdk version "1.8.0_40-internal" ($ java -version)
I added manually the JavaFX files (they are not included in this openjdk version) as it is mentioned at:Gluonhq -section 2.1.4
I run the Jar file with: java -jar Chess.jar -> Chess.jar is jar file
The game runs without these errors on Linux Mint (openjdk version "1.8.0_131") and Windows 10.
I don´t know what is the source of the problem. Maybe JavaFX on the PI is simply not a good idea?
Anyway thanks for the help,
Alex
Thanks for your quick answers and suggestions, but today I found the solution (tldr; including images of the meeples lead to exceptions, which lead to a bad performance. Removing the images improved the performance):
#Joe C - with my next question I will specify the problem more clearly ;)
#sillyfly - no but thx. for your answer
#Josê - Yes I tried. The first program I used gave me the same bug, but today I tried another self-written one -> this one worked fine -> see below
The problem was that the PI couldn't render my Meeples (they were basically images). I found this out using the stack trace of the PI. Two days ago I couldn´t access the stack trace, due to an impossibility of exiting the game, now I developed an exit function, and here goes the stack trace. It showed me, that there is a null pointer at com.sun.prism.impl.BaseGraphics.drawTexture(BaseGraphics.java:4000) - this is for rendering Images (as far as I know).
Today I removed my meeple images. I don´t know why the PI can´t render these images but it works fine now :)
-Alex
Related
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.
For quite some time I have encountered this issue that when doubleclicking a runnable .jar file it won't execute. Today I thought I'd have a look into solving this issue and read a bit through various SO articles regarding this topic.
First of all I have to say the following:
The problem occurs on my company's notebook running WIN 8 as well as on
my private WIN 10 desktop
I'm pretty sure about 1.5 - 2 years ago on the laptop doubleclicking worked
On the desktop however even directly after installation (which was in October last year) doubleclicking didn't work and it might be that I even already tried fixing the issue by reinstalling the JRE
As opposed to many situations described in various posts I can properly run the applications by calling "java -jar application.jar" in cmd but doubleclicking AS WELL AS trying to "open with" Java SE platform binary results in nothing happening
As suggested by several posts I tried running Jarfix however now the behaviour is as follows:
I had written a client-server application for my bachelor thesis which worked perfectly fine, I actually ran the application yesterday through cmd. After using Jarfix I'm now able to start the server by doubleclicking whereas the client side won't do anything when doubleclicked. I already checked for the correct filetype association as described in this post and everything looks correct.
Also I of course checked this with different programs as well and not only with my own applications. The same issue also appears for example (on my WIN 10 desktop) when trying to run Life in the Woods (for those not knowing it, it's a quite popular Minecraft mod pack) whereas it worked perfectly fine on my previous WIN 10 desktop when doubleclicking.
The problem that I have with this issue is not that I'd not be able to bypass it by running cmd commands but on the one hand it's simply annoying to always cd to the desired location and run this command and on the other hand it's simply something that has to definitely work after installing a JRE. It doesn't make any sense that for most people it works and for some few people random stuff happens - all more or less under the same conditions, that's not how any kind of software should behave.
I'd be really happy if anyone could help me solving this or point me towards anything I might have overlooked and forgot to check.
EDIT:
As pointed out by #VGR file operations using relative paths might be the reason for the problem hence below the two cases where file operations are being used:
Server-side:
File file = new File("C:/Util/authHashes.lvs");
Client-side:
systemProperties.put("javax.net.ssl.keyStore", "C:/Util/auth/labkey.jks");
systemProperties.put("javax.net.ssl.keyStorePassword", "password");
systemProperties.put("javax.net.ssl.trustStore", "C:/Util/auth/labtrust.jks");
What is weird is that both classes use absolute paths but the server starts when doubleclicking while the client does not. If both use the same kind of path shouldn't they both behave exactly the same?
I wrote a java program, which manipulates Word documents (docx) with Apache POI. It runs fine within Eclipse, and it runs fine as a runnable JAR on my computer (Windows 10).
I copied that JAR to another computer, and it is starting up normally. The GUI behaves like expected.
The problem is the Word document I write out (docx).
I am performing two types of changes. The first one is the addition of new paragraphs or concatenation of content to the runs. If I stay with this, the document gets written into the file system correctly. The second type is the simple replacement of content within the runs (changes of words and some grammatical changes). I would see that part as the "simpler" one, but if I stay with this or if I combine both change types, no document is written out at all. It does look like there is a bug, but there isn't one because it worked fine on my system.
I wrote myself a function to write out an error log (txt) to get information about that issue. This one worked on both systems. But the log didn't get any information, why the document was not written out.
I suppose there are some Windows security settings which interfer with my program or something like that. The computer that does not like to run my program has Win 7 installed on it, and there are some security domain settings, which affect all other computers in the local network.
Does anyone experienced something similar yet? Any suggestions what to check? Suggestions how to find out if an error happened are appreciated as well.
OK, the problem got solved by simply updating the Java version. I saw that update icon in the system tray, which didn't open update the update dialog. So I wanted to update the Java-version at least.
When I wanted to de-install the current Java version first, I noticed that the Win7-machine hadn't a Java-update for three years now. It was just installed in 2014. As soon as the recent version was installed, everything worked like expected again.
The strange behavior that some parts of my program worked and some not, confused me. I hoped that the Java update would fix this, but I doubted that. I didn't knew that old versions make programs run unpredictably.
Im trying to get a project with JOGL running and from second one I've run into problems. I have downloaded jogl-all.jar, gluegen-rt.jar and gluegen-rt-natives-windows-amd64.jar and jogl-all-natives-windows-amd64.jar version 2.3.2 from the release website of JOGL. I have extracted gluegen-rt.jar and jogl-all.jar, added them as a library to my project and put all the native files into lib/natives/windows-amd64. So far so good, I then set up a simple method doing the following:
System.out.println("Start");
GLProfile profile = GLProfile.getDefault();
System.out.println(profile.getImplName());
I hit the run button in IntelliJ and it printed "Start". Thats it. I started checking some logs, browsing the internet about that issue and suddenly, like 2 minutes later I realized in the corner of my eye that the output changed and it printed GL4bc. A little bit confused i thought this might be some IntelliJ related issue or so and started it in the command line. Same thing there, it consistently takes 1-2 minutes to execute GLProfile.getDefault(). What's this madness? I mean, I never choose Java for performance reasons, but that's a little bit too much :D.
What am I missing here? Or is this 'as designed'? Thanks for any help in advance and have a nice day!
I'm having a problem that, at this moment, I don't even know how to investigate properly. Any recommendations on how I can get more information are welcome and appreciated.
My company sells a product with a WinXP PC at its core. One of the product's tasks is being able to start a video player on demand -- VLC, in this case. (To be specific, VLC 0.8.6d; it's several years out of date, but upgrading is problematic for a few reasons.) The application responsible for starting the player and performing many, many other tasks is written in Java.
I have a test rig sitting next to my desk. It used to work just fine. But for some reason, it now gives a "Send Error Report" window when the Java app tries to start VLC: "VLC media player has encountered a problem and needs to close...." You know the one.
Clearly, I've done something that buggered things up. Problem is, I know neither what it could be nor how I would go about fixing it.
Stuff I know:
It's not a code bug. I run the same software on my development desktop machine, and it doesn't have this issue.
It's not the VLC install, nor is it a malformed video file. When I capture the command used to start it from Java and manually enter that command from a "cmd" window, it works fine.
It's not that sneaky bastich bug where Java punishes you if you don't manually drain STDERR and STDOUT when making a system call. I've got that covered.
I'm not getting any error messages or output when it fails; it just fails and gives me that pop-up window.
I'm stumped. Recommendations for either what it could be or how I can figure out what it is are very welcome.
Well, I’m not familiar with java and VLC, but I would do the following things:
Check that you have identical java virtual machines in both of your desktops. Just in case…
Check the process’s environment variables. They depend on parent process. Maybe VLC uses some of them.
Try to debug crashing with native debugger like WinDbg. Perhaps the call stack will give you more ideas.
Good luck!
My suggestions:
Create a simple java app that just launches VLC
Use your app to launch a simple command line windows program
Use your app to launch a complex program
Check to see if there is a memory constraint issue. Is VLC getting too little memory to run?
This really sounds like a memory/environment issue.
A number of things I would try
Make Sure both test and development machines are identical in every respect, the operating syste(if possible installed from same OS Disk), same JVM version, same memory allocation to JVM (you know those -X-ms stuffs). My fear is not with Java/JVM per se, it is with windows.
Make sure you can lunch for example Notepad from a Java app, and then something like Windows Media Player or MS Word.
Try and launch other versions of VLC to see if it is a VLC version problem.
Finally try and wipe the test box and re-install it(with Windows, you can never tell, a fresh installation might just do it!!)