Java 9 incompatibility #2149
Comments
|
I had a similar problem just running lein. To make sure it was not a problem with my set up, I fresh-installed Oracle JDK 9 on my Ubuntu 16.04 LTS installation, and downloaded Output: I am not a Java person, so do not really have a clue as to what is happening, but it seems related to this issue. Thanks |
|
I'd like to get to the core of this and find out how to resolve it, but I myself would like to wait for feature freeze in Java 9 first. Others are free to look into this of course, and I'll happily take patches for this. |
|
Running a REPL with JDK-9 crashes immediately
$ lein repl
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:374)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForName(RT.java:2177)
at clojure.lang.RT.loadClassForName(RT.java:2196)
at clojure.lang.RT.load(RT.java:443)
at clojure.lang.RT.load(RT.java:419)
at clojure.core$load$fn__5677.invoke(core.clj:5893)
at clojure.core$load.invokeStatic(core.clj:5892)
at clojure.core$load.doInvoke(core.clj:5876)
at clojure.lang.RestFn.invoke(RestFn.java:408)
at clojure.core__init.load(Unknown Source)
at clojure.core__init.<clinit>(Unknown Source)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:374)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForName(RT.java:2177)
at clojure.lang.RT.loadClassForName(RT.java:2196)
at clojure.lang.RT.load(RT.java:443)
at clojure.lang.RT.load(RT.java:419)
at clojure.lang.RT.doInit(RT.java:461)
at clojure.lang.RT.<clinit>(RT.java:331)
at clojure.main.<clinit>(main.java:20)
Caused by: java.lang.ClassNotFoundException: java/sql/Timestamp
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:374)
at clojure.lang.RT.classForName(RT.java:2168)
at clojure.lang.RT.classForNameNonLoading(RT.java:2181)
at clojure.instant$loading__5569__auto____6869.invoke(instant.clj:9)
at clojure.instant__init.load(Unknown Source)
at clojure.instant__init.<clinit>(Unknown Source)
... 23 more |
|
A compilation of Clojure with JDK 9 should give the problem(s). There's a lot of libraries refactoring. |
|
I can build Clojure HEAD of master and 1.8.0 with 9-ea+144, so I don't think that's the issue. I was able to get the repl to start by editing You can replicate this with just the Clojure jar with: |
|
Was just bitten by this. Downgrading to Java 8 for now. |
|
Might be interesting to focus on this soon, as Java 9 is around the corner. |
|
Warning, it seems to me there is a '_' variable in the Java code for Clojure. It's now a keyword...https://blogs.oracle.com/sundararajan/entry/underscore_is_a_keyword_in |
|
I'm working on a solution that seems to work with the Clojure REPL concerning the Timestamp. |
|
Any updates on this, guys? |
|
I, too, wonder if anything is happening here :) |
|
If the only issue is that Lein is ran from the bootclasspath, then this is trivial. Not running from the bootclasspath is time consuming for users though, so I'd be slightly hesitant to fix this immediately. I can do some measurements on startup time and see how hard we're penalised by not using the bootclasspath. |
|
I have the same problem after a fresh clojure + lein install on Ubuntu. @hypirion Can you explain? |
|
@mtexier The references to If you're having problems with version 2.7.1 that is expected at this point. |
|
@hypirion I did some benchmarking of startup time with and without the bootclasspath (averaged over 100 invocations of
For me, the difference between Java 8 w/BCP and Java 9 (where loading from the BCP isn't an option) is about 28%. So, it's not terrible, but I know it is a larger margin on slower hardware (I've done some benchmarking on an old linux machine and have seen a more marked difference, but don't have access to that machine atm to confirm). @technomancy I suspect issues with loading from the bootclasspath won't be fixed in Clojure 1.9, but maybe we can chat with Alex at Clojure/West about it to see. |
|
@technomancy I'm not sure this is the right issue, my exact issue is this one:
|
|
@mtexier That issue isn't caused by leiningen, but does have the same root cause as this issue had originally: tobias/dynapath#5. I'll comment further on the refactor-nrepl issue. |
|
@tobias thanks ;) |
|
It was pointed out to me that I haven't actually said how to get existing from the |
|
I just committed a patch which checks for $LEIN_SKIP_BOOTCLASSPATH, but
of course if you want to use 2.7.1 or older you'll need to edit the
shell script yourself.
|
|
@hypirion cool, thanks! It still fails on Java 9 unless someone knows what is wrong, and that they need to modify bootstrap args. Broken seems more user-hostile than slower. |
|
same here, wanted to try some clojure on my new mac, can't start lein. Pretty much stopped me in my tracks … |
Lein isn't ready for Java 9 yet technomancy/leiningen#2149 https://github.com/tobias/clojure-java-9/issues
* Update dependencies Removed jline dev dependency. Not sure what that was for. Not updating lein-doo yet - it has lots of annoying reflection warnings Not updating clojure or clojurescript in cljs profile yet. Some bleeding edge pain there still. * Document 2.0.1 changes * Document changes since 2.0.0 * Add Java 9 to travis test config * Rm Java 9 from travis config Lein isn't ready for Java 9 yet technomancy/leiningen#2149 https://github.com/tobias/clojure-java-9/issues
|
Just as an aside, when I opened this issue over a year ago, the reason Java 9 broke compatibility was completely different than the current one. It's pretty shocking that no one in the OpenJDK team tested major alternative JVM languages effectively enough to find this problem as development moved forward (at times recklessly, e.g. when the sun.misc package was removed). Also, Gradle was completely devastated by the loss of sun.misc.Unsafe, and somehow they were able to make that known and incline the OpenJDK developers to restore it. It would be nice if Leiningen development could have a voice in that kind of area, though I don't know how that whole ordeal resolved itself. While the OpenJDK and especially Oracle side has me feeling disheartened about the future of the JVM, it's encouraging to see not just comments, but commits, by both Leiningen and Clojure developers to fix this issue. It looks to me like Java 9 will be unsuitable for my usage for some time (the LWJGL3 graphics library still isn't especially compatible), but I'm sure by the time most libraries have fixed compatibility issues, Clojure will already have a new stable release (maybe more than one), and Leiningen will be working out-of-the-box once more. Thanks for all your hard work on this, Clojurers and Leiniacs. |
|
What I did to solve this issue (temporarily) was reverting the Java version from 9 to 8. In Homebrew is simple as (assuming Java 9 is currently installed): 🤷♂️ |
|
Just on "tommyettinger" comment: "It's pretty shocking that no one in the OpenJDK team tested major alternative JVM languages effectively enough to find this problem as development moved forward". That seems a bit unfair. Early access builds of JDK 9 were published very week and Clojure was on the list of projects that were mailed regularly to test with JDK 9 (see https://wiki.openjdk.java.net/display/quality/Quality+Outreach). On the specifics, sun.misc.Launcher was an undocumented/internal class used to support the On -Xbootlcasspath/a then it works as before in that the classes will be loaded by the boot loader. However, there is ongoing defense-in-depth and security work in the JDK that has moved several non-core modules away from the boot loader. There is no reason for the classes in the java.sql module to be loaded by the boot loader with all permissions for example. This so-called de-privilging work may break code that is deployed in unusual ways as there is no guarantee that all classes in all modules are visible to the boot loader. There is an issue tracking it (tobias/clojure-java-9#1) and I hope the maintainers will find a way to move away from using -Xbootclasspath/a. The startup regression that is mentioned above is worth exploring further. Part of it may be just to move to use G1 as the default collector. There was never a plan to remove sun.misc.Unsafe in JDK 9. There was discussion on whether to encapsulate it or not, all the details on that topic are in JEP 260 (http://openjdk.java.net/jeps/260). |
|
@AlanBateman There was certainly an intent to remove sun.misc.Unsafe; see this from Donald Smith, senior director of product management at Oracle: http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017028.html . I think a quote from that post should make said intent clear -- "Let me be blunt -- sun.misc.Unsafe must die in a fire. It is -- wait I haven't even bothered to install the current stable version of Java 9; it was too much of a train wreck working with it in development and I don't see any features in the final release that would actually benefit my everyday development. From what I can gather from other Java developers, I'm far from alone in sticking with Java 8. If the compact profiles turn out to be good for distributing bundled JVMs, I might try it, but I haven't found any documentation or support code describing how that would work with the new module structure. But now I'm off-topic. This issue has been closed; it may be worthwhile to post a link to the tracking issue regarding the bootloader in either the pull request that closed this issue, or a new issue if there is a chance that the bootloader solution won't stay valid. |
|
sun.misc.Unsafe does need to die but it will take many years and releases to get there. The JDK 9 early access builds did not encapsulate sun.misc. Most of the work on JEP 260 to move or remove undocumented internal classes from sun.misc was done in JDK 9 long before we brought the module system into the main line. |
|
I have a hard enough time convincing the Clojure core team to listen to my concerns; honestly the idea that it would be worthwhile to try to talk to people who work at Oracle never even crossed my mind.
Unfortunately that's not the case; forcing us off the bootclasspath affects everyone regardless of whether they're using Java 9, so we're in the unfortunate case that Leiningen 2.8.0 will be worse for everyone out of the box in that regard. You can still get back to the original speed if you set |
|
@tommyettinger as @AlanBateman mentioned, I have long been on a mailing list that notifies me of Java 9 releases to request testing of Clojure with them. I have periodically tested Clojure's build and/or runtime with these releases and have fed back information about things like the need for a sun.misc.Signal break handler to use in the repl. Clojure itself does not have an issue with Java 9 (older versions of Clojure work with it just fine too). I do not typically test every tool in the Clojure ecosystem with one of these releases and so had not discovered some of the problems in Leiningen or Boot. When we did discover the problem with the use of an unavailable class in the bootclasspath (not something Clojure explicitly states support for by the way), we evaluated alternatives, and implemented a fix in CLJ-2077 to conditionally load those features). That fix has been applied in the Clojure 1.9.0 development builds since before Java 9 was released. |
|
Also having same problem on Java 10 :( |
|
Hi. I'm new to Clojure and Leiningen. I'm getting Help (other than reinstalling old Java), please. |
|
@peter-kehl you might get better help at https://clojurians.slack.com/messages/C0AB48493/ |
and others
Due to restructuring in the JDK's internal-use packages,
sun.miscis very different in Java 9, and much of it is not available due to the "Project Jigsaw" modularization of the JRE actually making internal-use packages internal. This affects Lein because, at the bare minimum,sun.misc.Launcheris used even when running the commandleinwith no args. This class,Launcher, is likely being restructured because a newsun.launcherpackage is present in the root module, whichexports a small subset ofsun.miscand other internal-use packages. This subset notably includes theUnsafeclass, but that one may be limited to JRE builds that include the modulejdk.unsupported, which is discouraged already and a likely candidate for removal in Java 10.The information on this is scattered around the OpenJDK site, but this JEP is the most relevant: http://openjdk.java.net/jeps/260 , and this section on modularization should also be useful: http://openjdk.java.net/projects/jigsaw/ . I'm using the 4th preview release of the Zulu OpenJDK 9 builds, available here: http://zulu.org/zulu-9-pre-release-downloads/
The exact stacktrace I get when running
leinis:That's run with a subset of the modules in the normal JDK, but the error is identical if I run with the non-limited module set of a normal OpenJDK 9 installation.
This isn't at all urgent, but I hope there's an easy fix for using
sun.*classes that can be applied sometime before Java 9 starts to become more commonly used.The text was updated successfully, but these errors were encountered: