Clojure beyond Java 6 ?

[Morten Christensen]

I am new to Clojure which I am evaluating using Clojure for a Java 8 based framework with code in clojure, java and possibly other jvm based languages that all need to interoperate.

Clojure has many smart features which I like but there is at least one drawback. I could be wrong (?) but it appears to me that feature-wise it is limited to a legacy version of java - Java version 6 from 2008.

Happily Clojure tolerate running under Java 7/8 but I have found no specific support for Java 7/8 features. In particular there is no support for NIO 2.0 or interoperability support for @FunctionalInterface, java.lang.AutoCloseable, Method parameter reflection, java.util.stream etc.

I could do my own Clojure wrapper for NIO 2 but it seems to be quite hard for that particular tech (other people in the community have tried without being 100% complete and could not find anything that is actively maintained). All the other stuff seems like something that need in Clojure itself along with invokedynamic and other optimizations.

Is there any plans for actively supporting Java 7/8 ?

/Morten

[Alex Miller]

The plan for Clojure 1.8 is to retain Java 1.6 support. After that, it is something we will continue evaluating.

It is possible in some cases to provide jdk-specific features as is done with the fork/join library and a few other things. If you have a specific enhancement request, feel free to file a jira.

Alex

[James Reeves]

Java 6 can be thought of as the minimum version of the JVM that Clojure supports.

Regarding NIO2, it's worth pointing out that Clojure itself only has minimal wrapping around blocking streams, and nothing for NIO1. Using Java APIs directly in Clojure is not uncommon.

Incidentally, java.lang.AutoCloseable should already be compatible with clojure.core/with-open.

A cleaner way of interacting with Java's lambdas would be nice, but I haven't come across any difficulties personally as of yet.

- James

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Elliott]

This fact has become hugely important for me, as it allowed me to host my Clojure-based lighting control system inside Cycling ’74’s Max visual data-flow environment for music, synthesis and video. Their Java integration on the Mac currently requires the use of the legacy Apple VM, which is Java 1.6. I had to fork a couple of libraries Afterglow depends on (the ones which included Java source) in order to get them to compile Java 1.6 compatible classes, but once I had done that, everything worked, and it opened the system up to a focused audience of exactly the kind of motivated tinkerers that it is aimed at.

I don’t know if or when Cycling ‘74 are going to update MXJ, their Max to Java bridge, to be compatible with Oracle JVMs, so I am relieved to hear that Clojure is planning to remain compatible with Java 1.6 for a while.

[Andrew Oberstar]

I may end up in the same incomplete, unmaintained state as the other libraries you've seen, but I'm slowly starting on a Java interop library "cljj" (https://github.com/ike-tools/ike.cljj).

- AutoCloseable - As James (Reeves) mentioned, clojure.core/with-open meets this need.

- NIO2 - Standard Java interop is functional, but can be a pain due to the heavy use of varargs in NIO2 APIs. I'd like to wrap this in cljj.

- Streams - Can add reduce/transduce support by implementing CollReduce protocol. There's not a clean way to support the clojure.core/seq function, that I've seen without wrapping the stream. I plan to support this in cljj.

- Lambdas - I do find these to be a pain, and had a thread on this list a week or two ago. Right now I'm planning to just have functions/macros to wrap/define methods implementing java.util.function interfaces. Ideally, the compiler would support this better. This is the only one that really would require any change to Clojure itself for better Java 8 support IMO.

I can understand James' (Elliott) desire to keep Java 6 compatibility for platforms that are slower to adopt newer JVMs, but I hope that doesn't become an excuse for Clojure to stay moored to the JVM's past for the long-term.

Andrew Oberstar

[James Elliott]

That sounds like a great project. And I know that in the medium to long term, even if Clojure continues to support Java 1.6, eventually Apple will stop supporting their legacy VM, so I just hope Afterglow will catch on enough by then to convince Cycling ’74 to update their MXJ bridge. ;^)

-James

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/PjK0kYP1nCs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Colin Fleming]

El Capitan (the next version of OSX) is going to be the last to support Apple's 1.6 JDK. But that still means that I'm going to be stuck supporting 1.6 until the vast majority of people have moved on from El Capitan - that's a long way off.

[Mars0i]

For whatever it's worth, I do a lot of Clojure programming on two old Macs.  They were both running Snow Leopard until this week; now one is running Yosemite (ugh), and the other will run Snow Leopard until I get a new computer to replace it in a few months.  Since S.L. doesn't support anything past Java 1.6, I'm happy that Clojure has supported 1.6 for as long as it has.

[Didier]

Why not make new versions of Clojure support the latest Java version and JDK features, and people who need to run an old JDK can just depend on an older version of Clojure that works on it? Ideally, bug fixes could still be pushed out for maybe 2 versions behind or something.

[Alex Miller]

At some point we may. You have just casually waved off a bunch of infrastructure and maintenance work though, which has it's own costs.

[James Elliott]

El Capitan is now the current version of OS X (although I have not yet personally been able to update to it, because of some straggling compatibility issues with DJ equipment), so the next version of OS X will no longer support Apple’s 1.6 JDK.

[Alex Miller]

You might also find the nascent https://github.com/ohpauleez/jloj to be interesting for better lambda interop.

[Sean Corfield]

Didier wrote on Tuesday, January 19, 2016 at 11:08 AM:

Why not make new versions of Clojure support the latest Java version and JDK features

Since Clojure 1.7 (and 1.8) run on Java 8 quite happily, I assume you mean "Why not drop support for earlier Java versions with each new version of Clojure"?

The answer — for any situation like this — is that many companies are slow to upgrade fundamental infrastructure like the JVM because they have so many things that rely on it, so it is a major exercise. For Clojure to be adopted by such companies, it needs to run on their existing JVM infrastructure.

Dropping support for older JVM versions is therefore a Big Deal(™) and can not be undertaken lightly. A lot of software generally tries to support current plus two versions back which would mean Java 6 support should likely stay until Java 9 is GA (although it’s true that there is also a lot of software that only supports current plus one version back).

Bear in mind that there are many companies still running Windows XP because upgrading is such an expensive business (in time and effort, as well as any actual costs)!

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Alex Miller]

Although I guess that's maybe more from the Java side.

[James Elliott]

Thanks, Andrew, and to be clear this is an obscure side environment of my main project, and I am resigned to the fact that it seems doomed because the developers of Max/MSP are choosing to respond to Apple’s deprecation of their Java 1.6 environment by entirely abandoning support for working with the Java VM. So I agree, Java 1.6 is very old now, and at some point the burden of maintaining support for it starts slowing down other important progress.

The main thrust of my Clojure development is in the latest release candidate of Clojure on the latest Oracle JVM.

On Saturday, August 8, 2015 at 1:03:38 PM UTC-5, Andrew Oberstar wrote:

[...]

[Paul deGrandis]

Hi All,

Jloj is/was a quick spike into what it'd take to make interop play nicely with later Java features (New trait-like interfaces, FunctionalInterface, Optional, Lambdas, Streams, etc.)  It's mostly focused on making the Java side more Clojure-like, but does have support for loads of interop that works on both sides.
 * From the Clojure side: https://github.com/ohpauleez/jloj/blob/master/src/jloj/core.clj#L227-L269
 * All the Java-written interop: https://github.com/ohpauleez/jloj/tree/master/java/jloj/lang

You'll see that with some Java shims in place, it's easy to get all the things listed in this thread.

Cheers,
Paul

[Joe Python]

You are spot on!
Thanks for the clojure dev team to continue supporting Java 1.6.

[Matching Socks]

Apropos of this week's new clojure.org website, this here is a genuine F.A.Q.

[Max Penet]

I doubt it such a big deal actually.

You can run multiple versions of the java on the same machine. The

only issue would be for legacy projects that are frozen to java 6 and

would like to upgrade to a lib (like clojure) relying java8.  But I

doubt such projects are the norm, and the few that are probably do not

care about upgrading to the latest clojure.

There are a lot of very large projects (such as Jetty, Cassandra, etc)

that just made java8 a requirement for their next/current releases, and I

don't see much complaining about it (quite the opposite).

Also the fact that clojure itself is not getting an avalanche of new

feature at every release makes upgrading not so critical.

[Bozhidar Batsov]

Even Java 1.7 already reached its end of life. I get it that some companies are slow to update their infrastructures, but being constrained to legacy unsupported systems adds both a security risk and some development overhead. It's high time for Java 1.6 to be laid down to rest and for people stuck to it to move forward. I'm guessing Cognitect's enterprise customers are the primary reason 1.6 is still supported. 

[Daniel Compton]

Just a reminder that Cursive needs to support Java 6, as there are still issues with OpenJDK8 on Mac OS X 10.11. So not all people using Java 6 can be written off as enterprise laggards.

--

Daniel

[Didier]

The only reason to maintain compatibility with old JVM is to allow getting new features and bug fixes in an environment that for businesses or technical constraint can not upgrade to the latest JVM.

Such project obviously don't care about bug fixes and new features, since they are stuck with dangerously old legacy JVM versions anyways, which is both a security risk, a risk of added defects, and prevents usage of newer Java features.

It would not prevent them from running Clojure, it would only prevent them from upgrading Clojure to a later version, but I don't think this is a big deal, as they are also prevented from upgrading the JVM.

As I see it, if Clojure does not need any of the new JVM's capability to implement whatever it wanted for it's next release, than it makes sense to target the oldest JVM that works. On the other hand, if the legacy JVM is missing functionality that the new JVM brings, which prevents Clojure from implementing core ideas that it wants to do, I think that's an issue.

Now, maybe this has never happened, and 1.6 has been good enough for every single feature that Clojure decided to adopt. I'd like to know more about this point. Is the vision of Clojure to restrict itself to only the things JVM 1.6 allows it to do, or has it been more that the need for more never presented itself, and so Clojure is happy supporting Java 1.6?

[Colin Fleming]

Such project obviously don't care about bug fixes and new features, since they are stuck with dangerously old legacy JVM versions anyways, which is both a security risk, a risk of added defects, and prevents usage of newer Java features.

Sigh.

I feel like a broken record here, but I'd like to protest again at this characterisation. No-one cares more than me about getting off Java 6, but I have no choice. Oracle refuse to fix serious Swing/AWT bugs in later versions of the JVM, so many IntelliJ (and thus Cursive) users have no choice but to use it. The situation is getting better because JetBrains have actually forked the JDK and are working on fixing the bugs, but their JDK still has hardware-dependent issues, and even once those are fixed users on older versions of IntelliJ may be using Java 6 for years to come. The issue will be forced slightly once the next version of OSX comes out and no longer supports Apple's JDK 6, but until that point (probably two years from now) I'm stuck with it.

The rest of your points are valid, but the situation for Cursive, at least, is 100% Oracle's doing, and has no good solution.

[Sean Corfield]

Colin Fleming wrote on Wednesday, January 20, 2016 at 6:33 PM:

I feel like a broken record here, but I'd like to protest again at this characterisation. No-one cares more than me about getting off Java 6, but I have no choice. Oracle refuse to fix serious Swing/AWT bugs in later versions of the JVM, so many IntelliJ (and thus Cursive) users have no choice but to use it.

And as another data point from another language community:

The Frege project (a Haskell for the JVM) is running into problems with the Java 8 compiler (producing invalid JVM bytecode or just plain ol’ crashing), which is making it impossible to move from Java 7 to Java 8. Given Java 9 builds are starting to appear, the likelihood of these Java 8 bugs getting fixed is close to zero, and Java 9 is far too "bleeding edge" to force even the contributors to the Frege project to jump to it. Which means Frege is stuck with Java 7 at this point.

I’ve defended Clojure’s continued support for Java 6 on the grounds that it makes new versions of Clojure accessible to companies that are still on older versions of the JVM. As Colin says, and as seen in the Frege project, there are many valid reasons why older versions of the JVM continue to be used.

Just because you are not affected by JVM issues doesn’t mean that other people’s reasons for supporting older versions are invalid!

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[Mars0i]

On Thursday, January 21, 2016 at 12:14:33 PM UTC-6, Sean Corfield wrote:

The Frege project (a Haskell for the JVM) is running into problems with the Java 8 compiler (producing invalid JVM bytecode or just

 
Ugh.  Am I making a mistake by using Java 8?  "Invalid JVM bytecode", i.e. it's syntactically incorrect and won't run?  That's OK; I'll know it if I hit such a patch of bytecode, I guess.  It would bother me more if I could run a program successfully but with incorrect results.

[Nicola Mometto]

Do you have a link where we can read about those issues?

[Alex Miller]

By a wide margin, Java 8 is the most popular version used with Clojure and it is what I would recommend using. I know of no reports of somehow "invalid" bytecode with Clojure and Java 8. Clojure does not use the Java compiler (javac) but generates bytecode using the ASM library. The JVM spec has changed very little over the years (significantly less so than Java) and it would be quite surprising to me if the bytecode we generate in Clojure somehow did not work with Java 8.

[Mark Derricutt]

On 22 Jan 2016, at 8:50, Mars0i wrote:

> The Frege project (a Haskell for the JVM) is running into problems with the Java 8 compiler (producing invalid JVM bytecode or just 
>  
> Ugh.  Am I making a mistake by using Java 8?  "Invalid JVM bytecode", i.e. it's syntactically incorrect and won't run?  That's OK; I'll know it if I hit such a patch of bytecode, I guess.  It would bother me more if I could run a program successfully but with incorrect results.

I was reading this on the Frege list the other day and was also initially quite shocked. However, and I've not yet looked into the problem or tried to reproduce it and see exactly what's blowing up - but having seen some of the code generated by Frege, whilst not overly crazy, does make heavy use of anonymous classes, and I suspect the Java 8 specific generator may be generating some quite heavy lambda-within-lambda-within-lambda looking code that may be hitting, and revealing some gnarly corner cases that, if written normally ( and in a non-lazy language ) might never occur.

I suspect it's pushing the type inferencer and lambda/method-handle code to the edges of edgey edge cases "as far as standard java is concerned".

Ideally it would be good to get these fixed in 8, or at least 9 - and I think it would certainly be a good test case for tracking such fixes, so ultimately any fixes will be "a good thing", but that might be a while coming.


--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt

[Sean Corfield]

On 1/21/16, 11:55 AM, "Nicola Mometto" <clo...@googlegroups.com on behalf of brob...@gmail.com> wrote:


>Do you have a link where we can read about those issues?

https://groups.google.com/d/msg/frege-programming-language/MQgmSduKb4M/yW9HvmBRAQAJ

[Sean Corfield]

On 1/21/16, 12:57 PM, "Mark Derricutt" <clo...@googlegroups.com on behalf of ma...@talios.com> wrote:


>I suspect it's pushing the type inferencer and lambda/method-handle code to the edges of edgey edge cases "as far as standard java is concerned".

Yes, true, although for the Java compiler itself to produce bytecode that fails the verifier is… concerning.

I suspect Frege’s issues are more in the compiler than the JVM but I just wanted to offer a comparative data point for folks who are so quick to dismiss reasons for a company to want to stick with a Java stack that "works"…

Sean

[Mars0i]

Thanks Alex, Mike, Sean for clarification about Java 8 in relation to Clojure.  I breath easier now. :-)

[Didier]

> I’ve defended Clojure’s continued support for Java 6 on the grounds that it makes new versions of Clojure accessible to companies that are still on older versions of the JVM. As Colin says, and as seen in the Frege project, there are many valid reasons why older versions of the JVM continue to be used.

I'm not trying to argue that some companies, or people, don't have good reasons to be stuck with an older version of the JVM. I know this is a reality, and I've suffered from it myself in the past. Yet, I can not agree that we should limit the growth of Clojure on the basis of such situations.

By making new versions target newer JVM versions, we're not depriving anyone from Clojure, we're just preventing them from using the newer Clojure versions. If you're happy enough using Clojure 1.7 over Java 6, that won't change, and it'll still be better than using Java 1.6.

Like I said, if the features planned for Clojure can actually be implemented on an older JVM, I think that's fantastic and it should be done so. This just makes everyone happy. On the other hand, I wouldn't agree that some features be dropped or compromised for the sake of working on an older JVM. In that case, even if I was stuck with an older JVM, I'd rather Clojure made the right thing, and implemented the right features, in the right way, even if it meant I'd be stuck with an older Clojure.

I think this fits with Clojure's ideals too. Clojure embraces it's host platforms and enhances it, without trying to replace it. Just as ClojureScript should leverage JavaScripts benefits over the JVM, and ClojureCLR should leverage the CLR's benefits over the JVM, I think Clojure should leverage the latest JVM benefits over older JVMs.

[Andy Fingerhut]

The only person who can say for sure whether there will be Clojure features added that require newer versions of the JVM is Rich Hickey.  Alex Miller may happen to know his thoughts on this matter, if they have discussed it.

I recall seeing a few discussions a few years back in the Clojure Dev Google group whether JVM 7 features like InvokeDynamic would provide benefits to Clojure, or not.  The results of those discussions sounded like it was not a strong unconditional "yes", but a bit more nuanced.  See [1] for at least some of those discussions.

I don't recall if there have been any discussions of whether any features new in JVM 8 would enable enhancements in Clojure.

Andy

[1] https://groups.google.com/forum/#!searchin/clojure-dev/invokedynamic

--

[Alex Miller]

We will drop support for JDK 1.6 when we believe there is some reason for us to do so (and will assess the tradeoffs when we do). At the current time, I do not think there will be any changes in Clojure 1.9 wrt JDK support.

[Sean Corfield]

Didier wrote on Friday, January 22, 2016 at 12:51 PM:

Like I said, if the features planned for Clojure can actually be implemented on an older JVM, I think that's fantastic and it should be done so.

And it has been done. We’ve continued to see Clojure grow as a language and as an ecosystem without compromises being made for the core JVM version. We even have fork/join support in key language features (e.g., reducers) without compromise, working on Java 6 and Java 7+ — the former simply requires jsr166y.jar be added to your project.

Some third party libraries have made different decisions about JVM support when it has been appropriate to wrap / leverage certain Java libraries that no longer support older JVMs. Those decisions are driven by the other library they are wrapping, not Clojure itself.

On the other hand, I wouldn't agree that some features be dropped or compromised for the sake of working on an older JVM.

That doesn’t appear to have happened at any point so far — and I don’t see why anyone should suspect it might start happening at any point in the future either. If there’s some concrete feature proposal for Clojure at some point that critically depends dropping support for an older JVM (such as invokeDynamic), I trust that it’ll get evaluated for overall pros and cons and the right decision made for the language.

The OP was concerned that Java 6 was somehow holding Clojure back, but others rightly pointed to a number of libraries that deal with post-Java 6 language/JVM features — and that’s always been one of Clojure’s strengths: the core can run "anywhere" and the ecosystem/community provides libraries to fulfill everyone’s individual needs.