Develop Reference

How should I compile my java project targeting Java SE 8?

I have a Java Project (an application to play connect 4) and I want to turn it into an executable file. I created this project in VsCode, and I am using the Java Language Server (see details below). I extracted the .jar file, and used Launch4J to turn it into an executable, and when I run it, I get an error message (see below).
I researched the problem, and it seems that I need to compile my code targeting Java SE 8 rather than 17 (I have 17 currently installed). Could anyone explain to me how I should do this, or is there anything else I'm doing wrong?
The project has multiple files. I'm not sure if this is relevant, but the project has no external dependencies, although it does use javax.swing, javax.sound, and java.awt (as well as java.io.File, java.io.IOException, and java.util.Random, but I'm pretty sure those are irrelevant).
I have eclipse installed if it's necessary, but I only installed it today, and have no experience using it at all. The JDK I am using is (I believe) version 1.8.0_321. (At least this is what I get when I type in java -version.)
The Java compiler version is javac 17.0.2
When I try to run the executable generated by Launch4J, I this is the error I get:
Exception in thread "main" java.lang.UnsupportedClassVersionError: Main has been compiled by a more recent version of the Java Runtime (class file version 61.65535), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$100(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
And the popup error:
Java Virtual Machine Launcher
Error: A JNI error has occurred, please check your installation and try again.
Here are the Settings I used in Launch4J:
Output File: C:\Users\username\OneDrive\Coding\Java Connect 4 v.2\Connect 4.exe
Jar: C:\Users\username\OneDrive\Coding\Java\Java Connect 4 v.2\Java Connect 4 v.2.jar
Don't wrap the jar, launch only: NOT ticked
Wrapper Manifest: none
Change dir: .
Command Line args: none
Process priority: Normal
Both Options NOT ticked
Min JRE version: 1.2.0, Prefer public JRE, but use JDK runtime if newer
Max JRE version: none, First 64-bit, then 32-bit. (This was the default.)
All other settings are default.

Download the latest Java JDK version as .exe file (“x64 Installer”) and install by clicking on the .jar file.
Now the server should start again

#Holger has answered this question. The answer to the problem was to ship a custom JRE image with the application with the help of JLink. That way it can be used regardless of the local version of JRE.

NoSuchMethodError: <init> in com.sun.glass.ui.win.WinApplication.staticScreen_getScreens

Since upgrading to install4j 7.0.5 and Java 10, users that run our application on Windows more and more often report that the application throws
java.lang.NoSuchMethodError: <init>
at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Unknown Source)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Unknown Source)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
UiLauncher (WAITING)
at java.base#10.0.1/jdk.internal.misc.Unsafe.park(Native Method)
at java.base#10.0.1/java.util.concurrent.locks.LockSupport.park(Unknown Source)
at java.base#10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
at java.base#10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown Source)
at java.base#10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown Source)
at java.base#10.0.1/java.util.concurrent.CountDownLatch.await(Unknown Source)
at platform/javafx.graphics#10.0.1/com.sun.javafx.tk.quantum.QuantumToolkit.startup(Unknown Source)
at platform/javafx.graphics#10.0.1/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
at platform/javafx.graphics#10.0.1/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
at platform/javafx.swing#10.0.1/javafx.embed.swing.JFXPanel.initFx(Unknown Source)
at platform/javafx.swing#10.0.1/javafx.embed.swing.JFXPanel.<init>(Unknown Source)
at java.base#10.0.1/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base#10.0.1/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at java.base#10.0.1/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.base#10.0.1/java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.base#10.0.1/java.lang.Class.newInstance(Unknown Source)
at app//...
when starting the application though the install4j created exe file. The error is triggered by creating an instance of javafx.embed.swing.JFXPanel through reflection:
Class.forName("javafx.embed.swing.JFXPanel").newInstance();
We currently suspect that for some reason an incompatible DLL is loaded (glass.dll seems to contain the native method mentioned in the stacktrace).
Does anyone know how to prevent this error? E.g. is there are way to restrict the java.library.path used when executing the application through the install4j-generated exe to the Java runtime environment that was embedded in the installer and installed locally with the application?
According to one user, the error does not occur if the application is started "manually" using the
java -jar app.jar
command. So it seems the problem lies with the install4j created executable.

The workaround to this problem seems to be to remove all occurences of "glass.dll" from your system %PATH%.
I believe a fix must be implemented somewhere else, though; either in the Java runtime or in the Install4j code, but cannot be implemented in the Java code of the actual app:
For some reason the Java runtime version in Install4j checks the bundled JRE last when locating the libraries. In this case the problematic native library is glass.dll which should contain the requested <init> method but if anywhere in your %PATH% there is an older, incompatible version of glass.dll (e.g. from a previous Java 8 installation) that file will be loaded with a higher precedence and then the application will crash natively.
This is not a problem in the code of the application (the java code), nor a problem with the bundled JDK, this is a problem of how the install-4j-generated exe files (or maybe Java internally) tries to resolve native dlls. Instead of checking all path elements first, it should be checking the bundled JRE directory, first.
With Procmon you can see that it loads arbitrarily placed glass.dll files in the path, first: I added one from JDK 1.8 into one of my path elements and got this (plus the crash):

Java 9 Runtime Exception calling org.glassfish.jersey.server.ResourceConfig

My app works great with java 1.8 (and earlier), however when I rebuilt the application to use java 9, I receive the following stack trace. The reason for the update is because I need to use the new ProcessHandle.current(), which does not exist in earlier versions.
c:\>java -jar ./build/bin/DataMover.jar
DataMover Service: starting...
Exception in thread "main" java.lang.reflect.InvocationTargetException
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:58)
Caused by: java.lang.NoClassDefFoundError: org/glassfish/jersey/server/ResourceConfig
at dataMoverServerPackage.Main.main(Unknown Source)
... 5 more
Caused by: java.lang.ClassNotFoundException: org.glassfish.jersey.server.ResourceConfig
at java.base/java.net.URLClassLoader.findClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
For whomever is curious, here is the java version output.
c:\>java -version
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
Here is the relevant main() function.
public static void main(String[] args)
{
try
{
...
final ResourceConfig resourceConfig = new ResourceConfig(DataMoverServerResource.class);
I did research and read that the big difference between Java 6,7,8 and Java 9 is modules. In particular earlier versions of Java included the Java EE JDK, whereas Java 9 includes the java.se module, not the EE. All com.sun.* classes are inaccessible in Java 9, as I read. These pieces of information may or may not be relevant. I do not know the internal makeup of the jersey.server API, just some articles talked of that.
I am using a jar in jar loader, so the jersey stuff is in the base jar.
I am torn between an internal dependency issue on Jersey or the jersey jar. The loader seems happy just fails later at the java.base/jdk.internal, which tells me a module might be missing.
If there were an internal module, such as java.xml.bind, like I read in one post, which is included in Java EE, then the exception trace would indicate that and I would know to add that module using the --add-module option to java, such as --add-module java.xml.bind, but that is not the case here, at least with that module.
Here is a link to one possibly relevant article. Maybe the java.net is the problem, much like the at javax.xml.bind at the bottom of the stack trace in that question was the underlying cause. I discounted the ext folder answer in this question, as that question pertained to 1.8, which works for me and I have jar-in-jar. I note the question here because it keeps turning up on searches. This question was also not relevant, though similar. The list goes on.
I use Eclipse, but build using ant. The Jersey stuff libraries are in my Maven .m2 folder. I did right click on my project and select Maven > Update. That is at 2.7.
I came across this site, which talks about Java 9 migration. In the site, I read that if you add java.se.ee, you will have access to all Java EE modules. That recommendation failed, same output. The command that I tried was:
java --add-modules java.se.ee -jar ./build/bin/DataMover.jar
I did check SO and quite a few other sites but have turned up empty so far. Thoughts?

Lauch Eclipse SWT window application from command line error

First off. I am a newbie and green with respect to Java programming.
I created a Java Eclipse "SWT" "Application Window" on a Eclipse Kepler 4.3.1 (32-bit) running WindowBuilder and SWT (swt.jar). The design view is a composite.
The java application runs fine from Eclipse. I simply press the play button and presto.
Problem:
Issuing
java -cp . PkgNetAccelerator32.netAcceleratorApp
yields the following error message:
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/swt/widgets/Composite
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.getMethod0(Unknown Source)
at java.lang.Class.getMethod(Unknown Source)
at sun.launcher.LauncherHelper.getMainMethod(Unknown Source)
at sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)
Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.widgets.Composite
at java.net.URLClassLoader$1.run(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 6 more
I was doing some research and several posts on other issues suggested that the cure is to create a manifest. I saw an article that said something like:
Select the src folder, right click and select export, then Java, then JAR file, specify Manifest.jar and a path on the folder, make sure the "Generate the manifest file" is selected, and press finish.
I created the manifest file and tried launching it with the following command line:
java -jar ../Manifest.jar -cp . PkgNetAccelerator32.netAcceleratorApp
That yielded the same error message above.
I saw another article that said that one should add in the swt.jar file, but that is taken care of by the manifest. No? Specifying "swt.jar" instead of the manifest that I created resulted in an error message:
no main manifest attribute, in ../swt.jar
That error message makes sense.
I am at a loss. How do I run the java application?
I am testing on my Windows 7 Professional 64-bit desktop, but I need to run on CENTOS too. That should be no problem, as I assume whatever the fix on Windows is, will work on CENTOS.
UPDATE:
I placed the two lib files in a /lib folder to match the answer given. I then issued the following command line and got the following error message.
C:\SoftDev\Projects\NetAccelerator\JavaWorkspace\NetAccelerator32>java -cp "bin/*;lib/*" PkgNetAccelerator32.netAcceleratorApp
Exception in thread "main" java.lang.UnsatisfiedLinkError: Cannot load 32-bit SWT libraries on 64-bit JVM
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.C.<clinit>(Unknown Source)
at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source)
at PkgNetAccelerator32.netAcceleratorApp.open(netAcceleratorApp.java:43)
at PkgNetAccelerator32.netAcceleratorApp.main(netAcceleratorApp.java:33)
I found the following article, which produces a command line that works, just that is not reasonable for sending. I much rather use the answer.

Lets assume you have a eclipse project structure similar to this:
Workspace
-> Project
-> src (source code directory)
-> bin (compiled byte code directory as JAR)
-> lib (jar directory)
-> .classpath (eclipse file)
-> .project (eclipse file)
I am assuming that you are exporting the JAR as an executable JAR.
So in order to run a class in that exported JAR with another JAR from the lib directory (swt.jar) while your working directory is the Project directory you will need to execute:
java -cp "bin/*:lib/*" PkgNetAccelerator32.netAcceleratorApp
Using wildcards requires Java 6 or later
Please note: CENTOS requires : as a path separator. Windows uses a semi-colon.
This will add your classes and the swt classes onto the classpath and run your main class PkgNetAccelerator32.netAcceleratorApp
SWT 32bit vs 64bit
You will either need to use a 32bit JVM locally or continue to use a 64bit JVM and use the 64bit version of swt; see swt on windows 64 bit. I would suggest you match your version of your local JVM (32bit or 64bit) with the version that you will be running on the CENTOS machine. You will however need a different swt jar for CENTOS.

Unable to run jetty start.jar

When I run start.jar I get the following error:
Exception in thread "main" java.lang.UnsupportedClassVersionError: org/eclipse/
jetty/start/Main : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: org.eclipse.jetty.start.Main. Program will exit.
According to the Jetty documentation (http://www.eclipse.org/jetty/documentation/current/quickstart-running-jetty.html), all I need to do is download the zip, extract, and run start.jar. Google doesn't seem to provide me with any people having similar issues.
Thanks,
Sam

Take a look on the following discussion and specifically on the most popular answer.
Shortly you have a problem of class version incompatibility. Your jetty is compiled with compiler of java 7 while you are trying to run it with JVM of previous version. The solution is: go forward to Java 7: upgrade your JDK and configure eclipse to use java 7 and start enjoying the new features.

This could happen when you have some code compiled using higher JDK, try to check the JDKs used to compile your code.
Besides according to the documetnation Jetty 9 needs JVM 1.7.
Further links:
What Version Do I Use? (Jetty Documentation)
https://code.google.com/p/googleappengine/issues/detail?id=6768
Unsupported major.minor version 51.0 but everything is set to JDK 1.6

The newest release of Jetty needs Version 1.7 of the JVM. Update your JVM or use an older version of Jetty (not recommended).
You can see the Jetty-versions here: http://www.eclipse.org/jetty/documentation/9.0.2.v20130417/what-jetty-version.html#d0e75

java.lang.UnsupportedClassVersionError happens because of a higher JDK during compile time and lower JRE during runtime.
So upgred your JRE to the version of compiled time version of JDK.

The Java compiler is an advanced version, and the virtual machine is not. Make it uniform either by upgrading your JVM or downgrading your compiler (JDK). I recommend the second option. Gook luck !!!!

This can also happend if you are configuring for example Jetty 8.1 server, but your Jetty installation directory is higher than that, for example 9.1.
So download proper Jetty installation, in Eclipse go to Windows -> Preferences -> Servers -> Jetty -> Edit -> browse to your newly downloaded installation directory.