We Keep Coding

java.lang.InternalError: platform encoding not initialized when running EXE4J .exe w/ Java14 on PATH

So this error is a weird one...
I'm using EXE4J 6 to build a .exe file for my JavaFX Application. This has worked with no issues through Java version 13.0.1. I recently upgraded my environment to use Java 14.0.1 and now I get the following stacktrace whenever I try to run my application through exe:
java.lang.RuntimeException: Exception in Application start method
at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(Unknown Source)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.InternalError: platform encoding not initialized
at java.base/java.net.Inet6AddressImpl.getLocalHostName(Native Method)
at java.base/java.net.InetAddress.getLocalHost(Unknown Source)
at org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:54)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:612)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:669)
This error happens when trying to initialize my Log4J logging. however if I just made a direct call to InetAddress.getLocalHost() I can replicate this error out of .exe. Running my application directly out of my Eclipse (EE 06/2020) works just fine. After doing some debugging. I determined that removing Java from my PATH allowed the application to run. My .exe4j configuration file is set up so that the application should look for a separate Java 14 jre and not attempt to use my PATH for java.
<searchSequence>
<directory location="../java/jre64" />
</searchSequence>
The jre64 is built through ANT using the 14.0.1 jdk that I have and only importing the modules I need. Again, this all worked through 13.0.1 prior to my upgrade to 14.0.1
From research and testing on other computers, I think this boils down to an environment issue on my computer. However I've run out of places to look. Any thoughts or ideas would be much appreciated. Specifically why EXE4J would try to use the Java on my Path instead of the one in the search sequence.
Other Notes:
Running on Windows 10 Latest Updates
Path points to OpenJDK 14.0.1 (causes break) (java -version is correct in cmd)
I've confirmed that the working exe, after removing java from my Path, is still running on version 14.0.1 through the jre64
Application is built with and Eclipse Workspace/project JRE also points to same OpenJDK 14.0.1
Running on other computers with similar versions & environment works & doesn't cause this issue.

I was finally able to determine what the issue was.
I was using Exe4J 6.0 which was not compatible with Java versions 10+. I was surprised that I wasn't getting outright errors when trying to run exe4j to compile my executable, however it seems that exe4j was sucking in an older 1.8 java version from my registry and using a 1.8 jdk that I never cleaned out of my "C:/Program Files/Java" folder. When I deleted all my old JDKs, exe4j started complaining about missing a Java VM (even though 14.0.1 was set on path).
Upgrading to Exe4J 7.0 solved the issue for me.

In my case the problem was the PATH environment variable pointing to one jre directory.
I had 2 applications in different directories:
Application A had a jre directory included in the PATH environment variable and was working fine.
Application B had another jre directory NOT included in the PATH environment variable and was throwing this error.
After removing this jre directory from the PATH environment variable everything worked ok.

Izpack installler failing on Windows with java.lang.NullPointerException

Updated application to use bundled version of Java 14, was previously using Java 8
Worked okay on Windows dev machine , but on other machine failing on unpacking the data with:
com.izforge.izpack.api.exception.IzPackException: An error occured
in java.lang.Thread.run() at Thread.java:832
in com.izforge.izpack.installer.unpacker.UnpackerBase.run() at UnpackerBase.java:241
in com.izforge.izpack.installer.unpacker.UnpackerBase.unpack() at UnpackerBase.java:319
Caused by: java.lang.NullPointerException: null
in com.izforge.izpack.installer.unpacker.UnpackerBase.unpack() at UnpackerBase.java:299
in com.izforge.izpack.installer.unpacker.UnpackerBase.unpack() at UnpackerBase.java:475
in com.izforge.izpack.installer.unpacker.UnpackerBase.unpack() at UnpackerBase.java:528
in com.izforge.izpack.installer.unpacker.UnpackerBase.unpack() at UnpackerBase.java:627
in com.izforge.izpack.installer.unpacker.UnpackerBase.extract() at UnpackerBase.java:673
in com.izforge.izpack.installer.unpacker.LooseFileUnpacker.unpack() at LooseFileUnpacker.java:92
in java.io.File. () at File.java:362
Can't see why, does it not work reliably with Java 14 ?

There are some difference between jdk. Try to use jdk from:
https://adoptopenjdk.net/
https://www.oracle.com/java/technologies/javase/jdk14-archive-downloads.html
Be sure that you change system path for new jdk, and you use another jdk that earlier.

Does the other machine have java 14 jdk installed?
You can check the following folder on windows:
C:\Program Files\Java
if you do have jdk-14 installed, try running inside the command prompt the following:
"C:\Program Files\Java\YourJdkVersion\bin\java" -jar YourCompiledJar.jar
If the app runs correctly using the command above, it's because of the environment variable.
In that case, do the following:
Right click My Computer and select Properties.
On the Advanced tab, select Environment Variables, and then edit
JAVA_HOME to point to where the JDK software is located, for example,
C:\Program Files\Java\jdk1.6.0_02. (should be something like jdk-14 in your case)
from docs.oracle.com

Has been compiled by a more recent version of the Java Runtime (class file version 57.0)

I get this problem Using IntelliJ. But I have the newest version of everything newly installed on my system.
... has been compiled by a more recent version of the Java Runtime (class file version 57.0), this version of the Java Runtime only recognizes class file versions up to 52.0
I've set:
PATH as C:\Program Files\Java\jdk-13
JAVA_HOME as: C:\Program Files\Java\jdk-13
JRE_HOME as: C:\Program Files\Java\jre1.8.0_221
I've set the path, tried to find a change in the Project structure
COMPLETE ERROR MESSAGE:
H:\087-JAVA\HelloWorld\src>java com.codewithmosh.Main
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/codewithmosh/Main has been compiled by a more recent version of the Java Runtime (class file version 57.0), 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)

You need to double check the PATH environment setting. C:\Program Files\Java\jdk-13 you currently have there is not correct. Please make sure you have the bin subdirectory for the latest JDK version at the top of the PATH list.
java.exe executable is in C:\Program Files\Java\jdk-13\bin directory, so that is what you need to have in PATH.
Use this tool to quickly verify or edit the environment variables on Windows. It allows to reorder PATH entries. It will also highlight invalid paths in red.
If you want your code to run on lower JDK versions as well, change the target bytecode version in the IDE. See this answer for the relevant screenshots.
See also this answer for the Java class file versions. What happens is that you build the code with Java 13 and 13 language level bytecode (target) and try to run it with Java 8 which is the first (default) Java version according to the PATH variable configuration.
The solution is to have Java 13 bin directory in PATH or above instead of Java 8. On Windows you may have C:\Program Files (x86)\Common Files\Oracle\Java\javapath added to PATH automatically which points to Java 8 now:
If it's the case, remove the highlighted part from PATH and then logout/login or reboot for the changes to have effect. You need to Restrart as administrator first to be able to edit the System variables (see the button on the top right of the system variables column).

This is a setting in IntelliJ IDEA ($JAVA_HOME and language level were set to 1.8):
File > Settings > Build, Execution, Deployment > Gradle > Gradle JVM
Select eg. Project SDK (corretto-1.8) (or any other compatible version).
Then delete the build directory and restart the IDE.

The easiest solution is to change the Java version in your IDE. In Intellij, go to File --> Project Structure and change the Project SDK to the one that is supported by your Java Runtime (in your case it's 52 which corresponds to version 8 or less). Here's a table that shows the mapping between Java SE Version and Major Version:
Java SE
Major version
1.0.2
45
1.1
45
1.2
46
1.3
47
1.4
48
5.0
49
6
50
7
51
8
52
9
53
10
54
11
55
12
56
13
57
14
58
15
59
16
60
17
61
The table is taken from: https://docs.oracle.com/javase/specs/jvms/se16/html/jvms-4.html

I also encountered similar problem which is asked here. The issue was that some applications come with their own JRE and sometimes the installed JDK appears at lower priority level in environment path. Now there are two options:
Uninstall the other application which has their own JDK/JRE.
Sometimes it is not possible to remove the other application, which was my case. So I moved JDk installed by me to higher priority level in environment path.
I also removed the path as suggested by #CrazyCoder

I had similar problem with IntelliJ when tried to run some Groovy scripts.
Here is how I solved it.
Go to "Project Structure"-> "Project" -> "Project language level" and select "SDK default". This should use the same SDK for all project modules.

how i solve it in Eclipse
go to the properties of the project
go to Java compiler
change in the Compiler complicated level to java that my project work with (java 11 in my project)
you can see that it your java that you work when the last message disappear
Apply

I was facing same problem when I installed JRE by Oracle and solved this problem after my research.
I moved the environment path
C:\Program Files (x86)\Common Files\Oracle\Java\javapath below H:\Program Files\Java\jdk-13.0.1\bin
Like this:
Path
H:\Program Files\Java\jdk-13.0.1\bin C:\Program Files (x86)\Common Files\Oracle\Java\javapath
OR
Path
%JAVA_HOME%
%JRE_HOME%

For me it worked after removing the target folder 🗑

For eclipse IDE,
Please follow the below steps -
Right Click on "Project" -> "properties"
Click on "Java Compiler"
Check "Enable Project Specific Setting"
Correct the "compiler compilation level" ( ref pic is attached )
If needed, verify and correct java build path for the project as well.

On Linux, I got this error when trying to run SoapUI. Installing the latest OpenJDK JRE package fixed the issue, for example with Ubuntu: sudo apt install openjdk-17-jre.
I found this question on a search engine, so maybe it will help other people.

I got the problem after an upgrade to java 17. Then I was running the older Run/Debug configuration and needed to update the path to the JDK

The problem is that you compiled the code with java 13 (class file 57), and the java runtime is set to java 8 (class file 52).
Assuming you have the JRE 13 installed in your local system, you could change your runtime from 52 to 57.
That you can do with the plugin Choose Runtime. To install it go to File/Settings/Plugins
Once installed go to Help/Find Action, type "runtime" and select the jre 13 from the dropdown menu.

I have run into this issue When I recently upgraded my IntelliJ version to 2020.3. I had to disable a plugin to solve this issue. The name of the plugin is Thrift Support.
Steps to disable the plugin is following:
Open the Preferences of IntelliJ. You can do so by clicking on Command + , in mac.
Navigate to plugins.
Search for the Thrift Support plugin in the search window. Click on the tick box icon to deselect it.
Click on the Apply icon.
See this image for reference
For more detail please refer to this link java.lang.UnsupportedClassVersionError 2020.3 version intellij. I found this comment in the above link which has worked for me.
bin zhao commented 31 Dec 2020 08:00
#Lejia Chen #Tobias Schulmann Workflow My IDEA3.X didn't installed Erlang plugin, I disabled Thrift Support 1.4.0 and it worked. Both IDEA 3.0 and 3.1 have the same problem.

For Intellij IDEA 2021.2.3
After updating Module SDK to openjdk-17 it worked for me.
openjdk version "1.8.0_272"
File > Project Structure > Modules (Project Settings) > Module SDK (select openjdk-17)
If openjdk-17 not there then from dropdown select Add SDK > Dwnload JDK and add openjdk-17.

File
Settings
Build, Execution, Deployment:
Compiler
Java Compiler
in Project bytecode version choose 8

I had this problem with Android Studio.
I fixed it by updating Gradle to 6.5, and Gradle plugin to 4.11.

Did I skip necessary steps for my JRE and in Launch4j to cause my exe file to fail?

There were some initial issues with my javac.exe not working with the rest of the software to be able to compile and run the code, yet I was able to get a .class and .java for the program, so I thought I could use Launch4j to still create the application to execute normally by itself. However, I don't know why the .exe produced does not provide the output I expect.
I used a guide that you are probably aware of to learn to test a "HelloWorld" program since I am new to java and turning actual code into applications. Following the procedures, I was able to get up to testing the javac.exe file, to which I found out my JDK version somehow does not properly install one. I learned from here to check if the javac.exe exists, and that somehow the folder with the java version overrides a similar folder with the javac.exe when installed (yet I couldn't find out how to download and install without that happening). So I decided to just install the newest version of the JDK. I checked and there was a javac.exe file in a separate folder, but the update didn't seem to override the previous version. Following the guide, I was able to check everything, but the output in the end produced an error about the compiling java not matching the runtime. I thought of copying the newer java version with the javac.exe to be in the same path of the runtime [the java folder for the newer version was in Program Files like with the guide but the java folder for the original version was in Program Files(x86) to which I had to adapt the environment variables path accordingly], but that didn't fix anything.
Since I learned that Launch4j could bundle the steps with various versions, I thought of seeing if I could just wrap everything to work in an exe file. I was able to produce a file that had no output. Looking here, someone said they could fix their issue by checking off "console" on the "header" tab instead of "GUI" but the only thing that did for me with the new exe file was open the command prompt to show me nothing. I am not sure what to check in the command prompt or if I should know it is the same issue as before. Or perhaps Launch4j can work as is but I just don't know what to put in the environment variables (I think I was able to get the exe without a proper input there in the JRE tab since I didn't have a guide this time)? Should I uninstall the previous version even though the command prompt seems to look there or will something else be missing if I do?
C:\Users\User>java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) Client VM (build 25.201-b09, mixed mode)
C:\Users\User>javac -version
javac 11.0.2
C:\Users\User>cd C:\JavaTest
C:\JavaTest>java HelloWorld
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.UnsupportedClassVersionError: HelloWorld has been compiled by a more recent version of the Java Runtime (class file version 55.0), 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)
C:\JavaTest>
C:\JavaTest>dir
Volume in drive C has no label.
Volume Serial Number is 68EF-F43A
Directory of C:\JavaTest
01/28/2019 12:46 AM <DIR> .
01/28/2019 12:46 AM <DIR> ..
01/31/2019 12:56 AM 426 HelloWorld.class
01/27/2019 10:41 PM 25,839 HelloWorld.exe
01/25/2019 12:55 AM 751 HelloWorld.jar
01/22/2019 12:29 AM 114 HelloWorld.java
01/25/2019 01:07 AM 798 HelloWorldconverttoexe.xml
01/27/2019 10:41 PM 802 HelloWorldconverttoexe2.xml
01/25/2019 01:09 AM 1,146 launch4j.log
01/28/2019 12:46 AM 5,102 questiontostackoverflow.txt
8 File(s) 34,978 bytes
2 Dir(s) 561,260,572,672 bytes free
C:\JavaTest>
Despite the output I got showing a JNI error and the version checks not matching, I thought I could get the proper output manually. When that didn't work, I expected the "HelloWorld" message (which is what the program code simply is) to appear from creating an exe file with Launch4j, but both attempts resulted in no output when opening the application (the first time didn't even open the command prompt yet the second time briefly did before closing it out). It seems there is no issue with the actual software and certainly not with the program code, but with the process of running the code after compiling it, and I suppose this continues regardless of the variables for Launch4j. I feel that having the program folder "JavaTest" separate and directly in the local drive is harmless since none of the guides gave me any reason worry about that. I feel if I change anything else, I will make the problem worse. Specifically, if I uninstall the Java 8 version (which oddly is listed as an update even though I am sure I got the whole JD kit from Oracle), I feel I will lose a different part than the javac.exe, as the command prompt doesn't fully direct to version 11 for everything. Any help is appreciated.
EDIT: To clarify how I modified my system variables, JAVA_HOME originally had the value to "C:\Program Files (x86)\Java\jre1.8.0_201" with the bin folder missing "javac.exe"; after installing the newest JDK, I tried both "C:\Program Files\Java\jdk-11.0.2" and "C:\Program Files (x86)\Java\jdk-11.0.2" when copying the "jdk-11.0.2" folder to the same location as the previous version in Program Files (x86), but the command prompt still outputs the older version when I input "java -version"; the same error is produced when I input "java HelloWorld" from the JavaTest folder in the local drive. The "Path" variable has always started with "Program Files (x86)\Common Files\Oracle\Java..." to which I edit in "%JAVA_HOME%\bin" with my confidence in the syntax. With this, I can't see how everything can't be found in the newest JDK, including the initial version check in the command prompt, especially when echo %PATH% command does indeed seem to point to the the newest "jdk-11.0.2" version based on the output in the command prompt.
EDIT2: I am not sure if using the update feature to either automatically or manually update to 11 instead would've prevented the Java system on the control panel from only recognizing the Java 8 version as it does now, yet even with installing Java 11 from a direct download, I am able to work with the control panel configuration. On the user side, when I uncheck the path to Java 8 being enabled and add Java 11 paths both from Program Files and from (x86) either with javaw.exe or the whole folder, the command prompt gives the same result. The systems tab does not even allow me to add a path from the Java 11 version yet does allow me to uncheck enabling the Java 8 version (which still makes no difference).
I have noticed a couple of other differences with my situation from the guide, though I don't know if it matters. The guide's user environment variables seem to still include Java in the path yet the only directions for me were to edit the system variables to go to the Java path. The output from "dir" in the guide shows everything with the same date, yet "dir" in my command prompt only shows an update to the date of the "HelloWorld.class" file (I have added the output for this edit at the end of the code section of the question), which may make sense as I know the older launch4j attempts would not be affected.
I am okay with Java 8, but if uninstalling everything and reinstalling Java 8 does not get the javac.exe file, would moving only the javac.exe file of Java 11 to the bin folder of the Java 8 jre folder work (after resetting the paths to Java 8 and finding a way to get rid of the remainder of Java 11)?

check your PATH, you can check the environment variables or run in windows command prompt (CMD)
echo %PATH%
you should be pointing only to one JAVA version, I suppose that you are pointing to java 1.8.0_201 and to javac from another java (maybe java 11?).
I suppose that you see javac in JDK11 but you do not see javac in JRE8.
If you want to use Java 8 then download JDK for java 8 and point to It.
In case you want java 11, remove links to java 8 in your PATH

Inconsistency in ant command - CentOS 6.3

I'm in CentOS 6.3 and I'm attempting to recompile a .java file using the ant command however I'm getting these two results.
When I run ant:
Caused by: java.lang.ClassNotFoundException: org.apache.tools.ant.launch.Launcher
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: org.apache.tools.ant.launch.Launcher. Program will exit.
When I run sudo ant:
Error: JAVA_HOME is not defined correctly.
We cannot execute java
When I run *echo $JAVA_HOME*:
/usr/lib/jvm/java-1.6.0-openjdk/
Before anyone suggests that I should be using the JRE instead of the JDK, I just need to mention that my installation manual for the software I'm running - OpenGTS - specifically requests the JDK. Any ideas as to what I'm doing wrong?
Thanks in advance.

ant is script to launch a java program. It appears that script could not figure out a value for ANT_HOME. On linux the script tries to load /etc/ant.conf which reset the ANT_HOME. Your symptoms does not match, but it is worth checking.
Quote from site
The cause of this is that there is an old version of ant somewhere in
the class path or configuration.
A version of this problem may be seen on some linux systems. Some
linux systems (Fedora Core 2 for example), comes with a version of ant
pre-installed. There is a configuration file called /etc/ant.conf
which if present, the ant shell script will 'dot' include. On Fedora
Core 2, the /etc/ant.conf file resets the ANT_HOME environment
variable to /usr/share/ant. This causes the problem that an old
version of ant (1.5.x in this cause) will be used with a new version
of the ant script file.
One can check if this is the case by doing ant --noconfig -version.