tobias
java.sql.* classes not available from the boot classpath
Not all of the java standard library is available to the boot classloader, which prevents Clojure from loading if put on the boot classpath. This manifests as a failure to load clojure.instant, since it imports java.sql.Timestamp. This can be recreated with:
java -Xbootclasspath/a:clojure-1.9.0-alpha14.jar clojure.main -e "(require 'clojure.instant)"
This prevents Leiningen from working at all with Java 9, since the lein uberjar is loaded from the boot classpath to reduce startup time. See https://github.com/technomancy/leiningen/issues/2149
I can't comment on why -Xbootclasspath/a is being used but I'm curious why clojure.instant uses java.sql.Timestamp. I would think the java.time API (in the java.base) would be a better choice.
@AlanBateman because this predates the existence of java.time, which was added in Java 8. Clojure currently supports back to Java 6.
@AlanBateman: -Xbootclasspath is used to reduce startup time (it skips bytecode verification and some other things). Some benchmarks were provided over at http://dev.clojure.org/jira/browse/CLJ-2077
Okay, I just wanted to make you aware of java.time in case it was overlooked. It may be that clojure.instant could use that in the future.
As regards the startup impact then has anyone profiled this to see if there are any opportunities? If Clojure is compiled to JDK 6 then I assume version 50.0 class files with stack maps, is that right? Just wondering if the verification is being done by type inference rather than type checking. In any case, if it is common to deploy it with -Xbootclasspath/a then the only types that you depend on being visible are the types in the java.base module. Yes, this is an incompatible change and stems from the effort to improve the security of the platform by moving non-core modules from the boot loader to the platform class loader (platform class loader replaced was used to be called the "extension" class loader).