A long overdue article https://metaredux.com/posts/2019/03/29/nrepl-0-6.html
#announcements ?
It was released 2 months ago. 🙂
announce the informative post 🙂
Done!
Does the new nREPL actually require Java 8 for anything? I didn’t realise it had that dependency, and have started receiving issues from users who are using JDK7.
the change points here: https://github.com/nrepl/nREPL/issues/26
all tests pass with :javac-options ["-target" "6" "-source" "6"]
not sure if that's dispositive or not
@dpsutton Thanks! Since the version in Cursive is only used when Cursive starts its own REPL, perhaps I’ll fork a version compiled against Java 6. But in general, it seems like it would be good to support older versions if newer ones are not required for anything.
from the ticket it doesn't look like raising the bar was intended unintended. I guess @bozhidar took 8 to be the current java version rather than the current bytecode version?
it was usually 6 for clojure until 1.10 right?
(unless i'm conflating issues)
Yes, that’s right.
But Cursive is used a lot in enterprise environments, where upgrading is often not a choice.
for sure
is this just in an EAP?
or have you gone full nrepl 6 in the main version?
No, I released it in the latest stable release, I hadn’t realised that it had a Java 8 dep.
ah. shucks
Well, when users start a REPL via lein or deps, you get whatever they use, which is probably 90% of the REPL use. But some users start a REPL in a project not managed by one of those two (e.g. Maven, Gradle, manual project setup or some other means), and then Cursive injects nREPL to start the server.
In that case, it uses the version bundled with Cursive, which is now 0.6