1

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.
Steve
  • 981
  • 1
  • 8
  • 22

2 Answers2

0

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.

Steve
  • 981
  • 1
  • 8
  • 22
  • I'm getting this with JDK 17 using the launcher produced by jpackage, but pointing it to my own customized runtime. – swpalmer Sep 20 '21 at 20:37
0

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.

Aramis Rodríguez Blanco
  • 187
  • 2
  • 7