Today I found that Scala's classloader is a bit of a comprise. The details are murky, but JDK libraries that subsequently load non-JDK libraries can have troubles. My guess is that there is some conflict between the bootloader and the regular classloader.
In my case, I have a custom java.util.logging.Formatter class that I have used for years of pawing through gigabytes of server logs and test output. I got one previous coworker hooked enough that he extended this Formatter with a few options, and then wrote a filter to color code and correlate threads.
When moving over to Scala, I couldn't get the scala(1) invoked JVM to load my Java class. I was always left with the ugly and nearly unusable SimpleFormatter output. From verdant wilds of a rain forest island, David suggested that I invoke the whole app from java(1) rather than scala(1), and include the scala jar in the classpath. Works just fine.
My tcsh wrapper went from:
setenv JAVA_OPTS "-ea -esa -Djava.util.logging.config.file=trace.properties"
scala -classpath classes EntryClassName
to
java -ea -esa -classpath /Users/john/scala/lib/scala-library.jar:classes -Djava.util.logging.config.file=trace.properties EntryClassName
July 8, 2008
Subscribe to:
Post Comments (Atom)
1 comment:
This should not happen. You can have a look at the command line built by 'scala' by setting JAVACMD to 'echo' (bash syntax):
JAVACMD=echo scala -cp classes ....
Maybe that reveals something, and it would be nice to hear back. It should be easy to fix in our next release.
Post a Comment