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?
Related
How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it tries to load classes?
In particular, what file paths is it TRYING to access, only to perhaps discover whatever it's looking for is not there, at least as it interprets the specification given? There was a way to get that information, but I can't find it now.
Note that this is Java version "1.8.0_333" on Windows 10.
I've tried every flag known to me, via the -h and -X flags, and I strongly suspect what I'm looking for is (was) an X flag that's been removed, just as the -X help output warns. And so, there must be an OS way to figure this out, I sure hope!
You might ask why? Whatever for? What are you trying to do? Well, that's the bulk of this question's text. To wit:
As one of the very early users of Java (I started with 1.1) way back in the '90s, I had an issue moving an application suite I'd written for my company on Linux to MS Windows and I got it working by using Cygwin. Along the way, this same sort of issue came up and I quite vividly recall having found a mechanism for getting the Java launcher to articulate just what file specifications - paths - it was actually using in searching for the appropriate class. And through using this, I found that the CLASSPATH was being specified incorrectly, and with some experimentation, I got it working reliably. Now I need to do that again!
This flag I'd used was immensely helpful in figuring out just what the file specification format CLASSPATH needed to be (we're not talking semicolons here) this combination of OS, Java, and Cygwin. After some hours of what I hope was reasonable hunting, I'm wondering if this capability has been removed at some point? Either that or "I'm looking for the wrong thing." Heck, since the source is available (I think!), maybe some brave soul has hacked the java utility to do such a thing?
It may help to understand that for this application I wrote for my company, it was a major goal to have the source work pretty much the same on all Windows and Linux / Unix systems (and at the time, macOS), and just use a configuration file to tell the code what's different. And that wasn't easy to figure out, but with this flag, it wasn't that hard, either.
But, unfortunately, I haven't needed this knowledge since I figured it all out all those years ago, and apparently, this little kernel of knowledge is very hard to find today. Or, it's no longer pertinent to the modern version(s).
I don't think this has anything much to do with the actual problem, but it may help in people's thinking if they understood the scenario: The current situation is that I have a fully functional installation of this software on Windows 7 to use as a comparison for how to configure things on Windows 10 (and hopefully younger). The Windows 7 is running a pretty modern Cygwin installation and very nearly the most modern Java - just a sub-version away from the new installation from last week on a Windows 10 box. (Everything's bright and shiny new on the new box.)
The required format for CLASSPATH on the nearly identical but fully functional Windows 7 system is:
CLASSPATH="C:/opt/OurInstallationDir/lib"
And that's it.
This value is picked up in several places as the code later needs to launch Java itself to do some unusual things. However, the java command that gets it all going is launched from a C program - not that that matters for this problem - but the C program (compiled under Cygwin, but perfectly runnable from any Windows environment) helps ensure that the Java environment is secured (policy file contents and so forth) before getting into Java, else it refuses. And this program on Windows 11 launches Java just fine, it's just giving it a CLASSPATH that isn't useful, apparently, even though the files are there where they should be, etc.
Configuring things as before just doesn't work, even from the command line. No version of specifying CLASSPATH seems to work if it's more than a dot; the only thing that works, is being in the /lib directory when starting and using "-cp ." ... But that's just not going to fly for so many reasons! To be a little more clear, I've tried reversing the slashes, using /cygdrive/c/, and whatever else I could think of. But, at least we know that if you're in the directory and use -cp, it will find and launch the program. So, there's nothing wrong with the Java, just pointing the java utility at it.
Again: How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it's trying to load classes?
You use this construct on the JVM:
java -XX:+TraceClassPaths -cp "C:\opt\SomeDirectory\lib" myClass
I was able to get confirmation of what Java was using, not only for my CLASSPATH, but "internally" by using the above.
The fact that it echoed back both what I was doing and what it was doing somehow gave me the insight to check everything about it. Java itself doesn't work (at all) if it's installed in a location that it thinks has a link in it, and it's own fetches go right back to the system disk specification.
From that I found that Java on Windows won't take a CLASSPATH that has a link in it!
Simply ensuring that the whole tree was specified "from the top" of the drive it's on works. If it's not, it won't.
It's now working happily using the syntax noted above.
This is quite different from every other application I've seen on Windows. But, well, it's Java!
This really came from a pointer from Mark Rotteveel who commented above about this article: How to track when class is loaded and destroyed in jvm? And therein I learned how to get the list of all the options the presently in-use JVM supports. All Java developers should be aware of this in my opinion, so thanks to Mark for that.
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.
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.
I just wonder something about java applet with awt. I quite disappointed with this problem and want to throw it away sometimes. Below are my descriptions:
I already created one application using java applet with awt controls on my own computer, let's say computerA using Window 7 32bit Operating System. To up and running this application, I update java version to the latest one.
Application is working fine with computerA. However, this application also need to run on the others as well. As my own situation, I run with another computer, let's say computerB using Window 7 64bits Operation System. I knew that the application created with 32bits java version, thus I decided to install this java version on computerB. However, when I run the application it can only display interface on browswer, but some of its function did not work.
Yet I didn't throw it away, I decided to configure in the last computer, let's say computerC. This computer use Window 8 32bits Operating System. I did configure as I did with computerA and computerB. The result is still exact as computerB.
I also checked up this solution on here, but it is not fit my problem.
Here are my questions:
What is the exact problem on here?
Where does the problem come from?
Is it solvable?
How can I solve this kind of problem? Any helps?
Update:
PostgreSQL Database also install in other local computers as well.
I noticed that If I convert my code into eclipse project, it worked fine. No problem at all.
Thanks in Advance.
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!!)