Use JShell instead of beanshell

[kostafey]

https://blogs.oracle.com/java/entry/jshell_and_relp_in_java

It requires java 9, but it's native to java. And what is the finally roadmap decision? Go to clojure nrepl (it's cool, but it depends on lein whereas java projects uses maven in general) or ensime server or groovy or... JShell looks like a good solution.

[plandes]

I'm still a fan of Clojure, but nothing is stopping you from writing a plug in.

On Apr 5, 2016, at 9:30 AM, kostafey notifications@github.com wrote:

https://blogs.oracle.com/java/entry/jshell_and_relp_in_java

It requires java 9, but it's native to java. And what is the finally roadmap decision? Go to clojure nrepl (it's cool, but it dependent from lein whereas java projects uses maven in general) or ensime server or groovy or... JShell looks like a good solution.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[phillord]

The clojure backend that I produced doesn't depend on lein, actually. I built a maven plugin which launches an nrepl-server.

I like the idea of JShell, because with Java 9 it will just be there. But, then, we would still need to do a degree of integration. It would be nice to have something like nrepl which does not require parsing of a shell output. With clojure and nrepl we have a connection to the JVM all there. At the cost, of course, of introducing an extra dependency.

At the same time, I am not actively working on the clojure backend. Any solution is going to require significant work. Whoever, I think, is willing to do the work gets to make the decision. I've made a proof-of-concept which basically works. But, to get more functionality into, to even reach parity with the beanshell functionality, is going to require effort.

[kostafey]

@phillord, where can I find your clojure backend?

[phillord]

https://github.com/jdee-emacs/jdee/tree/clojure-backend

Actually, I hadn't realised how much work @udalrich had done on it, so it's not really "my" backend any more, much more his.

[pwojnowski]

Sorry for late reply. IMHO we could drop Beanshell and merge Clojure backend as our JVM connection. This way a separate branch wouldn't need to be maintained.

There's a lot of work to do on "frontend" part of JDEE, which is common to any backed. And when/if JShell will be available we could consider what to do next. Maybe by that time we'll have backend code hidden behind some interface, which would make replacements easier.

If there will be agreement on this, who is going to merge it? If nobody from clojure-branch devs will, then I can do it, but it JDEE may be broken for sometime. :-)

[phillord]

I think at this point making a decision is better than not so I would vote for #bexit (beanshell exit).

We need to pick a way forward, and we have nothing that is more advanced than the clojure backend. That clojure is very well supported in emacs (and by emacs developers) will also make extensions easier.

I have done very little on this since the start, and at least till emacs-25 is out, have little time to work on it, so am happy for @pwojnowski or @udalrich to do the merge.

I said a while back, that we should be prepared to break JDEE if we needed to, and I think this still holds.

Be good if we can do a final, beanshell release first though!

[plandes]

I'm not a huge fan of being broken for any significant time and it sounds like it will be for a while. Any outstanding reason why we need to move. I'm usually not a fan of keeping something like benashell, but it does work ATM and there is still a (small) community supporting it.

On Jun 24, 2016, at 10:06 AM, Phil Lord notifications@github.com wrote:

I think at this point making a decision is better than not so I would vote for #bexit (beanshell exit).

We need to pick a way forward, and we have nothing that is more advanced than the clojure backend. That clojure is very well supported in emacs (and by emacs developers) will also make extensions easier.

I have done very little on this since the start, and at least till emacs-25 is out, have little time to work on it, so am happy for @pwojnowski or @udalrich to do the merge.

I said a while back, that we should be prepared to break JDEE if we needed to, and I think this still holds.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[kostafey]

@plandes, since JShell hasn't released yet, it may be just plan to move. The only way I see at this time, is to make an experimental branch for JShell backend. Anyway benashell is outdated and the lagging will increase in the future. At the same time, JShell is embedded to JDK, so it will be actual to the all future changes and it reduce third-party dependencies.

bexit :+1: :)

[phillord]

@plandes I think we are broken, though. @kostafey JShell is attractive cause it's in built. But clojure has a nice, defined interaction protocol (nrepl). Moving away from parsing shell output would be a big advantage.

[pwojnowski]

If it would be possible to have both Bsh and Clojure in the same branch (choosable by user) it would be great. We would be able to restructure the code to move in either direction (Clojure or JShell), without breaking anything. Having two active branches basically makes that impossible.

@phillord, @udalrich is it possible with clojure-backend?

[kostafey]

@phillord, Clojure is great without question! But is it possible to pass to nrepl pieces of java code like to JShell?

[phillord]

@kostafey Yes, in the abstract. nrepl is actually protocol, and can be implemented anywhere. So, there is a nrepl server implemented in R now, I think. In this case, I am suggesting, though, the nrepl server implemented in clojure with cider as the client. This nrepl-server can take middleware, and theoretically it could take any middleware implemented in any JVM language. In practice, it might end up being very clojure like Java, but it would be possible. Probably,this process could be eased with a Java facade.

Bottom line is, that the current infrastructure for clojure provides a rich, and well-supported connectivity to the JVM, which is much better than beanshell. But to access that connectivity and support requires us to use cider, the nrepl-server and that was not designed for this purpose. The middleware is pluggable and can be changed, but cider comes as a single package.

A valuable thing, and brilliant time saving, or a disaster in the making. #bexit (as with #brexit) is a jump in the dark with little evidence. @udalrich has done more on the branch than I, though, and probably has a more informed position.

[plandes]

@phillord: can you explain how we are broken? At the risk of taking a brittle approach, I think what we have works. Whoever makes the change to a new backend (clojure or otherwise), IMO should do it in a separate branch. Believe--the move will be painful. I've dealt a lot with that (beanshell) code and it is pervasive in the whole application. It's responsible for all kinds of things (reflection, class/interface override/implementation, class/package resolution etc) and removing is not as trivial as just replacing the default functionality.

Some of the code is to do some of this generation is in Java--so there is some savings there.

@kostafey Remember that most of the code "snippets" actually original from beanshell constructing Emacs Lisp symbolic expressions. Clojure is naturally a better fit for this since there is (to my knowledge) any Emacs Lisp it couldn't create as a native Clojure data structure.

[phillord]

@plandes JDEE is working with a technology that is well out of date. I agree it pervasive, all the JVM functionality comes from it. Working on a branch is fine but has two problems. First, the effort in maintenance, and second if the "main" build comes from the bsh branch, then no one tests it. I am in favour of saying "this is where we are going" (whether this is clojure or bsh).

A middle option would be to "fork" JDEE on melpa. So, we'd have JDEE (as now) and JDEE-ng (with clojure, jshell or ensime, or what ever). Then it would be easy for people to install the ng functionality.

The cider/nrepl functionality works via call-backs and call-back handlers, rather than constructing elisp in java which is then evaled.

[pwojnowski]

IMHO we don't have enough devs to start a fork.

I'm for moving clj-backend code into the master to keep both along and then reduce dependencies on bsh. It's not ideal, but would allow smooth migration.

[plandes]

@phillord so the -ng functionality is the new beanshell replacement repo correct? @pwojnowski : wouldn't the two options be the same amount of work? As new bug fixes come through, applying them to both repos shouldn't be an issue given how little things changes--at least compared to other projects.

[phillord]

@plandes Yes, either the clojure/nrepl solution or a JShell solution. I think we need a concrete statement to say "no more beanshell releases". The beanshell branch could be maintained with backports where possible, but as you say, the integration of beanshell goes deep. Anywhere the code gets close to beanshell this is going to be hard.

As always, I have done very little on JDEE for a long time, so take my opinion with a pinch of salt. But, if we are going to switch to something new with few developers we need a) least effort and b) as many users moving to new branch as quickly as feasible. That way breakages will be reported.

If the breakages go on for too long, I agree, no one will use JDEE. It's a risk. The same risk was taken with Clojure when it switched from slime/swank to nrepl, and then again when changing names from nrepl to CIDER. It was a pain because, after dropping slime/swank the functionality got worse, not better, and it lasted for a year. But, in the immortal words of Paul Rodgers, it's alright now.

[pwojnowski]

To break status quo...

I can work, on the current master, towards constraining use of Bsh to allow replacement with some other backend (e.g. clojure). Also I could merge changes from clojure-backend branch to develop only on one branch, because with time it will be only harder to merge changes between branches. This is not ideal situation, but would allow us to (slowly) progress towards a new backend.

If any of you feel to have enough time to create a fork/project with a new backend then just do so and lead the project. Most probably I will be able to help.

[plandes]

I like this--and to further this idea, when you merge, you could create a new namespace for the clojure back end. Maybe at some point we can list out function aliases to make it easy to remap from beanshell to clojure and back. The idea being that beta enthusiastic users can use clojure as the back end until it doesn't work and then switch back.

On Jun 30, 2016, at 3:13 PM, Przemysław Wojnowski notifications@github.com wrote:

To break status quo...

I can work, on the current master, towards constraining use of Bsh to allow replacement with some other backend (e.g. clojure). Also I could merge changes from clojure-backend branch to develop only on one branch, because with time it will be only harder to merge changes between branches. This is not ideal situation, but would allow us to (slowly) progress towards a new backend.

If any of you feel to have enough time to create a fork/project with a new backend then just do so and lead the project. Most probably I will be able to help.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[arichiardi]

@phillord can I ask you a bit how to use the clojure-backed branch? I am very familiar with Clojure and I might be of help here ;)

EDIT: disregard that, the error was due to the fact that the source has been moved to jdee-lisp, I have now fixed.

EDIT2: where should I report issues? I am trying to check if jde-wiz-implement-interface works but no success. Funnily I can use cider-open-classpath-entry to verify that the interface I want to extend is actually there.

EDIT3: from a cider contributor, the cider-nrepl version I see is super old ;)

[fommil]

something to be aware of is that ensime is GPL3, which is incompatible with the EPL of clojure. So you can't depend on ensime-server nor can ensime-server depend on the clojure library (or anything that also uses EPL).

Also, since JDEE is GPLv2 (not GPLv2 or later) it is not possible for ENSIME to depend on JDEE either (which also excludes the ability to use netbeans), nor can JDEE depend on ENSIME.

However, if everything is done over the wire, from separate processes, then we are compatible.

We already have two s-expression protocols (we'd decommission the old one if anybody had time) and adding a third one is really bottom of the list of things to do. There are so many other things that could improve the java development experience in ENSIME. I've already spoken to bbatsov about protocol alignment and we concluded it would be an academic endeavour.

[phillord]

"something to be aware of is that ensime is GPL3, which is incompatible with the EPL of clojure. So you can't depend on ensime-server nor can ensime-server depend on the clojure library (or anything that also uses EPL)."

This is not true, I think, because of the standard interface clause in GPL. The "clojure library" is part of the standard interface of Clojure, so a GPL code base can link to it. It's the same clause that allows building Emacs, for example, on Windows, linked against the non-GPL windows code base.

"Also, since JDEE is GPLv2 (not GPLv2 or later) it is not possible for ENSIME to depend on JDEE either (which also excludes the ability to use netbeans), nor can JDEE depend on ENSIME."

Ah, that is a PITA.

So, by "academic" you mean your discussion with bbtasov concluded that protocol alignment would be impossible? Or not worth the effort?

[fommil]

I don't agree about the standard interface close in this case. Ah runtime it's just a library like any other. The standard interface is the jvm. If your logic were true, in word be possible to write gpl clojure apps.

Yeah, no benefit as we could see.

[arichiardi]

I just wanted to share here the idea I was already sharing on https://github.com/ensime/ensime-server/issues/345

In particular there could be a nrepl middleware project called, for instance, jdk-nrepl which contains code useful for all of the Clojure/Scala/Java projects, then a specific cider-nrepl for cider, ensime-nrepl...jdee-nrepl...

The above middleware approach makes sense (at least to me) also because we could mix and match code from many different places (I am thinking about refactor-nrepl) and people like @Malabarba, myself (Clojure peeps) could pitch in and write code in the language they are more comfortable with.

Just my 2c.

[phillord]

"I don't agree about the standard interface close in this case. Ah runtime it's just a library like any other. The standard interface is the jvm. If your logic were true, in word be possible to write gpl clojure apps."

It is possible to write GPL clojure apps, in the same way that it is possible to write GPL Java apps when the standard interface is C.

"in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language."

So, you can write a GPL app in Java, or Clojure. You cannot include a GPL library in a non GPL java implementation. This is my interpretation, of course, but I am happy to ask the FSF for clarification is necessary.

[fommil]

@phillord I think you'd be best asking the FSF on this. It'll boil down to your app needing to link to EPL code at runtime. There may be an argument that the application can be GPL, use the Standard Interface, but you can't distribute it with the clojure libraries, or something like that, which is just incredibly awkward and nobody wants to be doing that sort of thing.

And you don't need to ask Eclipse for their opinion https://eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE

you may not combine EPL and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3.

[phillord]

@fommil I have asked FSF and will clarify when I get their answer. My interpretation remains the same. Yes, you are correct that you cannot distribute with the Clojure libraries directly, because in that instance they cease to be a system library. I don't see that as awkward at all, though; in fact, that's quite normal and is what CIDER does (it runs lein, or boot, which have to be installed and they download (or bundle) Clojure).

[phillord]

@arichiardi Happy to answer questions on the Clojure backend -- although when I wrote it, it was a proof-or-principle. I think @udalrich has probably done more work on it that I. The point was to show that it is possible. Unfortuntately, I don't have the time to push this to completion, as most of my emacs time is taken elsewhere.

[arichiardi]

@phillord thanks! I just need a starting point and probably the first thing I will try to do is to create a jdk-nrepl project out of cider and jdee, how does it sound?

[fommil]

@phillord ok, I can see that might work. Ensime is corporate friendly and has a single jar download variant (for where a connection to a nexus is either firewalled or banned by security policy). We'd have to stop doing that, which would mean I couldn't use it, which means we're not doing it.

[plandes]

I also am for using nrepl with JDEE, and I also don't have time to complete the work @phillord started. @arichiardi My recommendation is starting with that.

[phillord]

@arichiardi That's a good idea -- and it's already started; jdee-nrepl on the clojure-backend branch is precisely a set of middleware components, for nrepl. jdee-nrepl-maven allows maven to start the backend, IIRC.

I guess the first place to start is to write a README!

[phillord]

@fommil Not quite sure how we go onto this, but your point is that Ensime-server works because Scala is BSD? And your single Jar download works without having to have scala on the local machine? Just a JDK.

This makes sense, and I'd agree. Clojure's EPL is a PITA, for a variety of reasons, and that is one of them.

[fommil]

@phillord yes and not just scala but all our middleware.

[phillord]

@fommil we could do what Cider has done -- Emacs side is GPL, Clojure side if EPL, communicating through a socket, if we really cared to. Still, I think that this is fairly hypothetical. Either the ensime infrastructure or the cider infrastructure could be used to provide JDEE with access to the JVM. But we lack the development effort, unless @arichiardi is willing.

[arichiardi]

Yes I am willing...but I have to say that I have started a new job AND I have a Clojure boot feature to complete first 😀

On December 7, 2016 7:28:02 AM PST, Phil Lord notifications@github.com wrote:

@fommil we could do what Cider has done -- Emacs side is GPL, Clojure side if EPL, communicating through a socket, if we really cared to. Still, I think that this is fairly hypothetical. Either the ensime infrastructure or the cider infrastructure could be used to provide JDEE with access to the JVM. But we lack the development effort, unless @arichiardi is willing.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/jdee-emacs/jdee/issues/51#issuecomment-265477051

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.