Fork me on GitHub
#nrepl
<
2019-03-29
>
dpsutton16:03:19

#announcements ?

bozhidar17:03:13

It was released 2 months ago. 🙂

dpsutton17:03:29

announce the informative post 🙂

👍 4
cfleming21:03:40

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.

dpsutton21:03:05

all tests pass with :javac-options ["-target" "6" "-source" "6"]

dpsutton21:03:12

not sure if that's dispositive or not

cfleming21:03:55

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

dpsutton21:03:36

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?

dpsutton21:03:51

it was usually 6 for clojure until 1.10 right?

dpsutton21:03:59

(unless i'm conflating issues)

cfleming21:03:13

Yes, that’s right.

cfleming21:03:38

But Cursive is used a lot in enterprise environments, where upgrading is often not a choice.

dpsutton21:03:55

is this just in an EAP?

dpsutton21:03:17

or have you gone full nrepl 6 in the main version?

cfleming21:03:29

No, I released it in the latest stable release, I hadn’t realised that it had a Java 8 dep.

cfleming21:03:38

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.

cfleming21:03:02

In that case, it uses the version bundled with Cursive, which is now 0.6