Re: Next Gen JDEE

(Resent after bounce -- apologies for lateness)

Paul Landes <[email protected]> writes:
> Question in order of importance:
> - Who has the time and initiative to help out (I can't do it all myself with current time constraints)
> - Should the project have a new name or carry the same name? My feeling was
> start a brand new project for the purpose of name space and maybe create more
> "buzz" as a "new" Emacs java development library.
>
> Given all of this, I'd like to hear others opinions how to proceed with
> JDEE--especially from the previous contributors of JDEE, which I've seen more
> of lately.

First up as it impacts on the everything I say next -- I have limited
time to help as I don't write a lot of Java any more.

Having said that, here is what I would do:


1)  I would split JDEE up into three separate subprojects.

These would be: the JDEE major mode, which would essentially be an add
on to Java mode as at the current time, but which could move a little
bit more quickly that Java-mode in core. I haven't been keeping up with
JDEE nor Java mode, but it was a long, long time getting generics (it
has them now right?). Does it do lambda's yet? The major mode should do
*only* major mode type stuff -- so indentation, fontification, semantic
parsing maybe.

A minor mode for interacting with an inferior process, what every that
would be. This is quite a well-path trodden Emacs wise, from
slime/swank, clojure-mode/cider and so one. People could mix and match
then as they wanted. Two of these actually already exist: malabar-mode
(which is maven-centric) and eclim (which turns eclipse into a build
tool -- entirely hideous but I think necessary for android devs).

A nrepl server (probably just reusing the Clojure one) with Java support
services for, well, doing all the stuff we do with beanshell at the
moment. The nrepl server launch would be someone elses problem (maven
already supports it, as does leiningen for mixed Clojure/Java projects).
This would probably also need completion libraries and the like. Java
can't really do "evaluation", but can do class file reloading; advanced
functionality would *require* saving to file and compilation. Having
this work over an Emacs buffer would be great, but is just more effort
than it is worth.

Discussions need to be had malabar and eclim devs. Two ways forward
exist to ease to user experience: a common minor mode with several nrepl
served backends -- one for Maven (already exists), a simple one
launching JDK direct, an ant one if anyone cares, leiningen/boot for
Java/Clojure projects (already exists), SBT for Java/Scala (perhaps
exists).

2) I would be ruthless and kill everything we do not need and which
better functionality exists for.

So, all prj.el and project code would go. Some of this is found in
projectile (for example). Some duplicates dir-locals variables. If we
need a cute GUI for setting this (a motivation for the project system,
which reuses customize), then really, this needs to be in core.

And, let's face it, most of it is a throw-back to when JDEE wrapped the
JDK. I strongly suspect that no-one uses JDK direct to build their code
nowadays. (Well, except me when I am teaching, ironically, where all the
project tools are too heavy, but this can be solved with a generic nrepl
server which just compiles to a local directory and has no other
options).

All the tempo and templating stuff would go. Changing templates in
customize was always a pig anyway. And, everyone has their favourite
templating system (yasnippet for me), and these templates already exist.

3) Steal and support other functionality from core and outside. So,
auto-completion should come from company mode, working with
out-of-the-box techniques in the major mode, and with the nrepl server
for more intelligent completion. Malabar already has some debug support
(I believe). Projectile I mentioned. Helm for searching or what ever.

So, in short, a lighter, meaner JDEE (people always use the phrase
"height-weight" when talking about JDEE and always complain about the
configuration -- and this is now, when Emacs performance is not an
issue).

4) Documentation: Someone already mentioned a texi port. Org-mode is
another good option. Core documentation should version with the code
base.

5) Debugging: Complex, and it is something that is needed. At the
moment, there is one as part of JDEE, and malabar mode has one as well
(which is GUD integrated).


Taken together, this would focus JDEE on where it needs to be focused --
Java source code. Interacting with the JVM would be farmed out to a
JVM server. Interacting with everything else would be via byte-code;
whether that is written in Java, Clojure, Scala, Groovy or anything else
is, I think, not a hugely important decision.

My thoughts. Apologies if this overlaps with what other people have
said. I am in seriously asynchronous Email mode at the moment.

Phil



------------------------------------------------------------------------------