trptcolin
jline2 is end-of-life
So far the problems only appear to manifest on Windows with Java 25: https://codeberg.org/leiningen/leiningen/issues/105
With recent JDK, to use JLine 2 or other libraries that use JNI or other native access, java gives a warning unless it is passed the option --enable-native-access=ALL-UNNAMED (individual modules can be named rather than the wildcard ALL-UNNAMED).
It's only an annoying warning now, but the plan is for it to be an error in future JDK.
But we should still get ahead of this before it causes any more serious problems.
However, the jline project does not document the differences between jline2 and jline3, nor even (afaict) even any changelog whatsoever, so a naive approach to updating is not likely to be very effective; this might require someone who actually Knows Java.
@technomancy Yeah I think it's a pretty big change, but don't know the details. And unfortunately I'm not likely to work on this - not doing any Clojure at all these days unfortunately.
One note for anyone who wants to pick this up is that @bhauman's library https://github.com/bhauman/rebel-readline does use JLine3 - might make more sense to integrate that to Leiningen and sunset this project entirely. Or alternatively I'd be very open to having someone take this project over, if it makes more sense to upgrade this one.
Thanks for the context. Out of respect for our packagers, I'd like to make an effort to avoid adding new dependencies, so I'll see if I can give this a shot despite my shaky Java. It looks like the changes will really only be needed in two files (reply.reader.jline.completion and reply.reader.simple-jline), so that helps. But it's good to have a plan B.
Would you like to continue handle merging patches and deploying updates, or would you rather hand off the repo and clojars group entirely?
Would you like to continue handle merging patches and deploying updates, or would you rather hand off the repo and clojars group entirely?
Definitely open to the latter!
Went ahead & invited you as a collaborator to the repo for now, happy to add you to clojars too, just let me know if so! 😄
Also no objection on your approach, but one nit / question on this bit:
Out of respect for our packagers, I'd like to make an effort to avoid adding new dependencies
Isn't jline3 already going to require new dependencies? Here are rebel-readline's deps, seems like it's not just a version bump since it presumably goes jline/jline to org.jline/jline-*.
Went ahead & invited you as a collaborator to the repo for now, happy to add you to clojars too, just let me know if so!
Sure; that would be appreciated. Thanks.
Also I'd like to reiterate my thanks for all your original work on reply; even if you can't keep it going it in the future, the work you've put in so far has been appreciated!
Isn't jline3 already going to require new dependencies?
Ah, yes; I should have been more specific--I don't want to add new dependencies that aren't in apt yet, but this one is already there: https://packages.debian.org/sid/libjline3-java
I recall a few years ago I saw some migration guide, but I can't find it right now. (I was looking briefly at the amount of work needed, but I dropped the ball on this) There's a bit of a summary of the differences here https://groups.google.com/g/jline-users/c/Ows5emcYQew
I noticed LLMs seems to provide some migration notes that seem OK, so this might help as well. Given the good test suite our project has perhaps even some LLM agent can keep trying to do the migration until the existing tests pass.
I'll try to tackle the jline3 migration this week. I already did a bit of infra/deps cleanup in #214 to set the stage for this.
And here it is (with a bit of help from Claude Code) - https://github.com/trptcolin/reply/pull/215
The API changes between jline 2 and jline 3 were brutal. Hopefully a future migration to jline 4 will be less painful. We're still blocked on this front until we can drop support for Java 8.