Java 10 announcement; implications for Clojure


#1

As mentioned in the current The REPL newsletter, there is a What’s new in Java 10 announcement.

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).


#2

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.


#3

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 :slight_smile:


#4

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.


#5

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 :slight_smile:


#6

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.


#7

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.


#8

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.


#9

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.


#10

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.


#11

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


#12

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


#13

True, but you kind of switch immediately from 8 to 11 as soon as 11 is out. And so you might want to go to 9 and 10 also, to not have to many surprises. I wonder how it’s gonna turn out.


#14

FYI, Clojure 1.10 will switch to minimum Java 8 (latest alphas have made that switch).

We are studying the new Java release schedule and what it means for Clojure support. In particular we are wondering whether it makes any sense to officially support Java 9/10 at all once 11 comes out. I’m not exactly sure what “not supporting” Java 9/10 would even mean.

Would be interested in feedback.


#15

Is Clojure currently ‘officially supported’ (tested?) on OpenJDK? Going forward?

Oracle has committed to get OpenJDK on par with the Oracle JDK sometime soon, the only difference being that the Oracle JDK is commercially supported.

At the very least, there will likely be an increase in people using OpenJDK going forward.

But (in theory at least) there is also the possibility that the Java community might port bug-fixes from Java 11 to OpenJDK 9 & 10, making those ‘viable’ longer term platforms. (I don’t know if that would be practical or even legal).

Personally I would find it completely acceptable if Clojure only ‘officially’ supported the officially supported / LTS Java versions, but I think it would be useful (and would appreciate it) if the Clojure team could give their opinion on this. Thanks.


#16

We test against both Oracle and Open JDKs in our test matrices. There is no “official” support definition other than Java 6+ for Clojure 1.9 and Java 8+ for Clojure 1.10 (right now). In some sense, there is a question as to what a “supported” release even means from a Clojure perspective. That we test against it? That we bugfix if something doesn’t work? etc…

I believe Red Hat intends to backport fixes from the latest Oracle/OpenJDK into older versions so there may still be a stream of OpenJDK updates even on older versions. The current situation, particularly prior to Oracle JDK 11 release, is confusing and we are trying to work through what the best path forward.


#17

I think of it as byte code compatibility and reliance on Java’s standard compatible sdk.

Like if Clojure were to rely on a SDK class added only in Java 9, it would not be compatible with earlier versions. Or if it compiled down to byte code that only runs on JDK 10, etc.


#18

FTIW, I ran a Clojure dev environment on IBM Java 8 for weeks if not months without even realizing. I had switched the default Java on my Linux system for a support case in a different program and forgot to switch back.

Worked like a charm. I wouldn’t be surprised to see a raise in usage of IBM’s JDK in enterprises.


#19

Stephen Colebourne posted this useful summary of the JDK situation:


#20

I’m curious, how are other languages dealing with this. Like how long is CPython supporting old versions for security patches and by who?