Since my knowledge and experience with the Java ecosystem and the JVM is somewhat lacking, I was wondering if someone could provide insight or outlook on what this means or could mean for Clojure (in the longer run).
Based on that article, I didn’t see anything that would affect Clojure – especially given that Clojure tends to support many older versions of Java for years anyway.
In particular, I was wondering about the Application Class-Data Sharing section of the announcement, since we had a number of posts here and on blogs talking about reducing Clojure’s startup time. If I recall correctly, a good chunk of the startup time is being used by the class loader.
The article mentions that
[…] JVM does a lot of magic when it’s loading a class. JVM parses the class, stores it into an internal structure, performs some checks on it, resolve and link the symbols, etc. […] So, when we have a shared archive which contains pre-processed classes, it can then be memory-mapped at runtime. As a result, it can reduce startup time, and memory footprint if multiple JVMs share the same archive file.
Is there something here that could be utilized to ameliorate this (arguably major) pain point?
Edit: Looking at the article again, I noticed that it says “Episode 1” – perhaps this thread could be kept alive for further announcements, should they have any relevance
Even if it helps Clojure (which I’m not actually convinced it would), right now Clojure is still supporting Java 6 so how many years would it be before Clojure stopped supporting Java 9?
That’s why I’m skeptical of the “magical thinking” that seems to crop up when a new Java version appears: it’s just not relevant to Clojure for many years.
I’m sorry, but I was not thinking anything “magical” here. I was hoping (and still am) for someone better educated in matters JVM to elaborate on what, and how, could be relevant to Clojure in the development of its host language - or, what not and why that is.
As to the backwards compatibility, I wouldn’t want to make any assumptions here. You seem to assume that new equals incompatible, which I grant it most often is, but I fail to see why it has to. Given Clojure’s emphasis on stability, I don’t at all expect a BC breaking improvement, but I’m curious as to what non-BC breaking options we have, and will have, pretty much regardless of the amount of years it will take
I don’t know about Java 10, but with JDK 9 you can now bundle the JVM with your Clojure App with only 30mb of overhead as described here: https://sunng.info/blog/custom-jre-for-clojure-app-distribution.html
What @seancorfield means is that Clojure doesn’t leverage new Java features, that’s why lambdas aren’t supported for example, and why you can’t interop with them. Clojure tries to be 2 java version behind. But, JDK improvements you get for free, so any performance boost could affect Clojure, like a new GC.
I don’t know if it adds to the discussion or is at all relevant, but I made this little plot of the Java and Clojure releases … Sometimes a little graphic helps put things in perspective.
The Clojure data shows the initial minor release dates (1.0, 1.1, 1.2, etc.). The Java data shows the ranges from initial GA release dates to end of public support (data from Wikipedia and from the Oracle Java SE roadmap document).
The most obvious thing here is the quicker release cycle that has been adopted for Java. Will this impact Clojure? Who knows.
If I could make a wish, then I wish that Clojure would move on to Java 8 bytecode. Today Clojure still produces Java 5 bytecode (yes, the line from 2005 to 2010!). Some newer (interop) APIs like
(Comparator/reverseOrder) can’t be used with current versions of Java. For Java 10 specifically, I don’t think it impacts Clojure in any way.
I had posted about why Clojure didn’t adopt a newer version of Java on the mailing list, and I got a few replies from people saying please don’t, I’m stuck on Java 6 at my work, and would hate having to not be able to use Clojure and go back to Java 6.
I felt their pain. Going from Java 8 to Clojure is already wonderful, going from Java 6 to Clojure must be utter bliss.
As much as I’d like newer interop support, I can understand wanting to support people stuck on old Java versions.
My personal preference would be to drop Java 6 and 7 support in Clojure 1.10. Both are getting increasingly difficult to support in the Clojure CI build infrastructure as all of the build infrastructure itself depends on Java 7 or even 8. Based on the 2018 Clojure survey data, <1% is using Java 6 and only about 6% are using Java 7. Heck, even Java 8 is scheduled to be EOL in less than a year.
The new clj tool sets Java 8 as a minimum requirement as that was necessary for some of the deps (like jgit).
I’m not sure that the change in Java release schedule has a big impact on Clojure releases, just a matter of testing a bigger matrix of stuff.
Cursive was one of the drivers for maintaining Java 6 support (or at least I loudly said that I didn’t want it to go away) but that hasn’t been a problem for a while now - anyone using IntelliJ 2016+ is now using Java 8 and 2015 and previous versions are definitely legacy now - I don’t even release new Cursive versions for them any more.
An interesting development with Java 9/10 that probably not enough people are aware of is that Oracle will stop supporting Java 9 immediately, there will be no more security updates, people are expected to upgrade to Java 10 as soon as it’s available, and it seems that will be the norm going forward: support for the previous version is dropped as soon as the new one is out.
I find it rather baffling that there will be no more overlap between the lifetime of these releases. For comparison: Java 8 will still be supported until December 2019 (link).
This post has more info: http://blog.joda.org/2018/02/java-9-has-six-weeks-to-live.html
I believe they are adopting the LTS system. Java 11 is their next LTS. You can see all of it here http://www.oracle.com/technetwork/java/eol-135779.html