I am currently utilizing the java logging system and have stumbled on a very weird behavior when run via fantom.

I put a stack dump in the constructor of a custom FileHandler to help track the issue. Also, both stack traces below are truncated for readability but are identical up until the parts shown.

Scenario 1: I run the program from F4 IDE

Stack trace showing success of my constructor from the stack dump

java.lang.Exception: Stack trace
 at java.lang.Thread.dumpStack(Unknown Source)
 at com.kodaro.log.KodaroFileHandler.<init>(KodaroFileHandler.java:48)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
 at java.lang.reflect.Constructor.newInstance(Unknown Source)
 at java.lang.Class.newInstance(Unknown Source)
 at java.util.logging.LogManager$5.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at java.util.logging.LogManager.loadLoggerHandlers(Unknown Source)

Scenario 2: I run the program from the command line:

Fails to load the FileHandler at the same point in the code and this is the error being thrown.

java.lang.ClassNotFoundException: com.kodaro.log.KodaroFileHandler
      at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
      at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
      at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
      at java.util.logging.LogManager$5.run(LogManager.java:965)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.util.logging.LogManager.loadLoggerHandlers(LogManager.java:958)

Hmm... it's going to be something environmental, so I'd check what your FAN_HOME is in each, and then check what Java libs are being loaded.

F4 doesn't do any magic when running Fantom programs, it just launches a Java process via the standard eclipse runtime configurations. It does, however, ensure that pods of any open Fantom projects are included in the Env. But it seems your problem is more Java based than Fantom.

From the console:

C:\Fantom\fantom-1.0.69\bin>fan -version Fantom Launcher Copyright (c) 2006-2013, Brian Frank and Andy Frank Licensed under the Academic Free License version 3.0

Java Runtime:

java.version:    1.8.0_45
java.vm.name:    Java HotSpot(TM) 64-Bit Server VM
java.vm.vendor:  Oracle Corporation
java.vm.version: 25.45-b02
java.home:       C:\Program Files\Java\jdk1.8.0_45\jre
fan.platform:    win32-x86_64
fan.version:     1.0.69
fan.env:         sys::BootEnv
fan.home:        C:\Fantom\fantom-1.0.69

Not sure where I check similar information from the IDE. Also not sure how I would tell fantom to change how it loads the java libraries. Everything is in the same /lib/java/ext directory when running from F4 or the console.

Still looking for a resolution to this issue. Still not sure why fantom from a console differs to the point of failure to resolve the same java classes it does in the ide for the exact same fantom installation.

If it has something to do with how eclipse loads with different runtime configurations to do this properly, what do I have to change in fantom to make it load java correctly when run from the console?

I haven't used F4 for a while. But it usually ships and uses a built-in fantom version. So the version may be different.

My F4 installation is configured to not use the embedded version of fantom.

F4 uses its own JRE normally; while from the command line you're getting the installed one in Program Files.

The error is calling out a missing KodaroFileHandler class in the log package; this is probably a jar that's included in the Eclipse F4 JRE, but not installed in your default Java.

Check for a jar file in the eclipse jre folder, subdirectory lib/java/ext (I think), and copy it also to your JRE in the Program files directory...

The class in question is not part of the JRE, it is part of a custom jar. The jar file that also contains many other classes that resolve without issue. The jar is already in the /lib/java/ext directory of the fantom installation and is where it's loaded from for F4 and the console.

The setup of F4 for fantom is to use my installation locally, not the embedded one.

The setup of F4 for java is to use the one installed by my system, there is no embedded one.

The only difference between running my program in the console vs F4 is that I run it from one location or the other. They both use the exact same java and the exact same fantom. F4 does something right with it's java class loading and fantom without whatever extra configurations F4(eclipse) does fails at this.

To recap:

• com.kodaro.log.KodaroFileHandler is found when run in F4
• com.kodaro.log.KodaroFileHandler is not found when run from the cmd line

So we're looking for classpath differences from running Fantom in the two different ways.

The F4 launcher (that runs Fantom programs) doesn't do any funky java class loading and is actually quite basic.

In F4, expand the Fantom Native Libraries (Java) and JRE System Library trees to see what JRE is being used and what jar files are being picked up, and compare that to the JRE used from the cmd line:

F4 and the command line are both configured to use the same jre.

The jar that has this class is in the fantom installation at /lib/java/ext and so shows up in the Fantom Native Libraries. F4 loads every class in that jar file. Fantom from the command line loads every class from that jar file except that one class. The jar never moves. It is the same jar in the same fanntom/lib/java/ext directory but the command line fails to load that class.

Might want to try and run this command from both environments:

fan compilerJava::ClassPath

After some further research on the topic, this appears to be a known issue with the java class loader and logging, which appears to be sticking around.

https://bugs.openjdk.java.net/browse/JDK-6448699

The reason this appears to work in F4 is because it's built off of eclipse which implements OSGi which handles the dynamic module class loading for the system class loader.

The solution, don't rely on the logging.properties file to load custom file handlers. You'll have to do that in code although you can use it to configure the properties of the handler, just not initialize the class unless you want to also implement OSGi or some other dynamic class loader variant into your runtime.

Wow, I imagine you had a rough time finding the cause of that bug, well done!

I got quite a workout with my google fu on this one.