Develop Reference

Java Virtual Machine Launcher Error: Unable to access jarfile bin/Eaters_TankSoar.jar

I have an AI game we use for class written in Java. It works fine on my Surface Pro with Windows 10 but I cannot get it to work on my HP EliteBook. The error is displayed in a Java popup and says:
Java Virtual Machine Launcher Error: Unable to access jarfile bin/Eaters_TankSoar.jar
I have setup identical environments between the two systems including the same (older) version of Java that works fine on the original system. I checked the environment variables, permissions, policy files, etc. I have found several posts with the usual suggestions (launch from same directory, check permissions, Java version, run as admin, etc.) and none have led me to the solution and the file and structure are copied exactly from the working version.
It is launched from a .bat file:
#echo off
set SOAR_HOME=%~dp0bin
set PATH=%SOAR_HOME%;%PATH%
start javaw -jar bin\Eaters_TankSoar.jar config\eaters.cnf
Is there some sort of security setting for Java in Windows that would prevent this on one machine but not the other? Even though I have found posts mentioning a Java Control Panel, there does not seem to be any such thing in the current version of Windows for this Java version which is:
java version "14.0.1" 2020-04-14
Java(TM) SE Runtime Environment (build 14.0.1+7)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

Any way to sandbox an application dependent on an older (non-working) version of JRE?

I have a very old application (published in 2001) I am trying to get working in Windows 7/8/10. There is a setup.exe part of it that is using Java in some capacity, and not working correctly. I suspect it is using java because I decompiled the JAR file packaged with the application and there are references to several setup steps within the .java files (along with a file named setup.java). There is also a jre folder published with the application as well, running the following (dated) version:
F:\jre\bin>java -version
java version "1.3.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0_01)
Java HotSpot(TM) Client VM (build 1.3.0_01, mixed mode)
At first I suspected the application was using the systems environmental variables to use the currently installed version of JAVA, but I ruled that out by completely purging JAVA from the system and retesting - same results.
I next tried to simply update the folder to the latest version. As expected however, there were calls being made that were no longer supported (error message was referencing _JVM_IsVMGeneratedMethodl).
At this point I am running out of options. I could always run this application in a VM (and it works fine), but I would prefer to somehow package it in a nice streamlined way for easy distribution and install. Is there anything I can do? I was thinking something along the lines of application virtualization but still reading up on it.

It's hard to tell without "being there", but I'm guessing that the old (1.3) JVM just isn't compatible with the more modern versions of Windows.
Your best bet is probably running it against whatever version of Windows the app was originally developed on, in a VM.
If you have / can get the complete source code, you could try recompiling it with the version of Java supported on your current system. But it's probably a long-shot.

If it is containing a JRE folder, then you could skip the installer and add some batch file to launch that .jar with the specific JRE via a command of this form:
java -jar pathToYourJAR
btw, you could also consider options to convert to executable, some older are mentioned here:
How can I convert my Java program to an .exe file?
some of them may allow you to select which JRE to bundle/use

Java Applets prompt for update/block/later; updated to requested version, then newest version

Any applet I click on from the web prompts me to update Java, even though I had the most recent version. The prompt directed me to a download (on the real Java site, don't worry) so I installed it. I went back to the applet, and the prompt persisted.
I searched for help and found another forum post that said the prompt directs you to an outdated version of Java - it's a bug in the Applet manager. Okay, I downloaded the newest version of Java available on the website and had it uninstall all older versions on my computer. I looked at another applet, and the prompt was still there.
What am I doing wrong? Applets in general can't be broken - they must have tested it.
C:\...>java -version
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode)
If I understand correctly, the applet version can be different than your regular version of Java. When I go to http://java.com/en/download/installed.jsp, I get the same prompt, but the filename is marked with (2), because I've downloaded it and installed it twice.
Update: I visited the same page again, and Java crashed, nearly taking out my browser in the process. It recovered and told me it needed to uninstall 8 update 5 so it could install 8 update 20, but it failed to uninstall (probably because it crashed Java.) Meanwhile, checking in Programs and Features, as well as the -version check I posted above, I can see that version 8 update 20 is installed.
I'll post the updates as I go - I'm uninstalling all Java from my machine in the hopes that one was interfering with the other somehow.

Java Code Compatability issue (my binary is also not working)

I have written a Java application using Eclipse Juno on Fedora 17. I have JRE 1.7 installed, but I changed the Java build path to 1.6, I believe. Everything works fine there. I can then build a .jar file which runs on a Windows 7 virtual machine without problems. However, if I try to run it on the school computers (Windows 7
java version "1.6.0_18"
Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
Java HotSpot(TM) Client VM (build 16.0-b13, mixed mode, sharing))
it gives an exception like: java.lang.IllegalArgumentException: cannot add to layout: constraint must be a string. This is apparently something to do with CardLayout, which I believe is a standard Swing component.
I am using miglayout library and sqlite-jdbc driver if that could be related.
I would really appreciate help with this

I found the problem.
cardLayoutPanel is a JPanel
cardLayout is obvious
identifier is a String
cardLayoutPanel.add(container);
cardLayout.addLayoutComponent(container, identifier);
turns out that in Java 1.6 this doesn't really work because it should actually be:
cardLayoutPanel.add(container, identifier);
without the second line
Java 1.7 doesn't complain for some reason. Weird.

Java applet in firefox linux makes Java application launcher crash/exit

I have a Java applet that downloads data from where it's hosted, using HTTP. The applet has default permissions for an applet, that is, not many. Randomly during download, maybe 90% chance of reproductibility, at a specific part of the log, the java executable hosted by Firefox will exit abruptly, and the Java Console will be closed.
I thought it was my first JVM crash after just a few weeks of Java, but could not find the Fatal Error Log. Until I found out that when Chromium is used to open the applet, it works 100% (many tries in various conditions, alterning with Firefox)
Both browsers execute use the same commandlines for the java executable
Firefox: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=20972388862 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.5712.287531591049678510.AF_UNIX
Chromium: /usr/lib/jvm/java-6-sun-1.6.0.26/jre/bin/java -D__jvm_launched=20858056974 -Xbootclasspath/a:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/deploy.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/javaws.jar:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/plugin.jar -Djava.class.path=/usr/lib/jvm/java-6-sun-1.6.0.26/jre/classes -Dsun.awt.warmup=true sun.plugin2.main.client.PluginMain write_pipe_name=/tmp/.com.sun.deploy.net.socket.5428.6724684151611746860.AF_UNIX
Then I booted a Windows 2000 partition and also noticed that the applet was working 100% with the same version of Firefox and JRE. Could not try Chrome, not available on this platform.
Now I'm not necessarily asking for a solution as my 'client' will use Windows 2000 to run the applet. I was posting this to know if someone experimented with java crashes could find an explanation to this. Is it the communication between Firefox Linux and java that could make java exit? If you had to make this work, how would you proceed? Try to produce an SSCCE for Mozilla?
Versions:
Firefox 9.0.1 (both on Linux and Windows 2000)
Chromium 9.0.597.45 (70550) Built on Debian 6.0, running on Debian 6.0.2
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
EDIT: I found more information. When listening to Firefox's stderr, running the applet and then exiting Firefox after java exits, I get this. Not so useful though, it just tends to show that Firefox didn't even know that java exited.
Exception in thread "main" netscape.javascript.JSException: Plugin instance for applet ID 1 was already released
at sun.plugin2.main.server.LiveConnectSupport.getInfo(LiveConnectSupport.java:405)
at sun.plugin2.main.server.LiveConnectSupport.shutdown(LiveConnectSupport.java:41)
at sun.plugin2.main.server.JVMInstance.unregisterApplet(JVMInstance.java:1300)
at sun.plugin2.main.server.JVMInstance.recycleAppletID(JVMInstance.java:385)
at sun.plugin2.main.server.JVMManager.recycleAppletID(JVMManager.java:316)
at sun.plugin2.main.server.MozillaPlugin.stopApplet(MozillaPlugin.java:325)
at sun.plugin2.main.server.MozillaPlugin.destroy(MozillaPlugin.java:225)

Try to produce an SSCCE for Mozilla?
Yes. (I recommend that.)
You will need it for a bug report to either Oracle or Mozilla. Unless reported, problems do not get fixed.