Re: Next Gen JDEE

Stephen Leake <[email protected]> Wed, 15 Jul 2015 02:31:29 -0500
Newsgroups gmane.emacs.jdee.devel
Message-ID <[email protected]>
Paul Landes <[email protected]> writes:

> Again, my earlier plans were to create a brand new project and port
> over pieces from JDEE. Starting new I think is necessary to start the
> ball rolling where as a major refactoring of the existing code base
> would be an up hill battle against the mentioned inertia of a large
> project.

I recently did the same for Emacs Ada mode; the new code is much
cleaner and easier to maintain.

I prefer to program in Ada; I only use Java for Android projects and
FIRST robotics.

> - Replace beanshell with clojure

I gather clojure is better maintained, and will stay current with any
new Java features? In particular, generics?

> - Replace semantic with some Java based parser (maybe compiler like
> ASM)--however all fly compilation and syntax correction etc happens in
> Java. 

I wrote a new parser for Emacs Ada mode in elisp, and am now attempting
to re-implement that in Ada as an emacs dynamic module, for speed
reasons (some people have Ada files with over 1000 lines ...)..

I did this because the Ada language is more complex than other languages
Emacs support, and/or I'm more picky about getting the indentation right
for _all_ constructs :).

What parser to use depends heavily on how much you care about handling
incorrect syntax gracefully (to get parser-dependent stuff right while
editing). For Ada, I make no attempt to handle this gracefully
currently, but I hope to improve that in the new parser.

The parser is used for several things: indentation, navigation,
completion, and possibly highlighting. They all add different
requirements, but they all push towards implementing a complete parser.

The Semantic parser is LALR. The Emacs Ada mode parser (called 'wisi';
http://stephe-leake.org/emacs/wisi/wisi.html) is generalized LALR; it
can handle conflicts. The language that wisi parses is described in a
bison-like grammar file, so it could be used for Java. Using a
generalized LALR parser means it is much easier to write the grammar in
a way that is clear and understandable.

Interfacing an external parser to Emacs is currently not easy. Operating
as a separate process communicating thru pipes is slow, partly because
the Emacs pipe operations are not designed for large amounts of data, so
they have built-in delays. There is now an experimental dynamic module
interface, allowing external code to link to Emacs as a dynamic library,
but it's on a branch, and probably won't be in Emacs 25.

> - Entire project becomes an Emacs plugin 

There are at least three styles of Emacs plugin:

- Gnu ELPA package

- random elisp files (current status)

- dynamic library with elisp files (very experimental)

So I'm not clear what you mean here.

It should be fairly straight-forward to clean up the current code for
emacs master and package it as a Gnu ELPA package.

> - Move to a plugin approach so each add on is a separately maintained
> Emacs plugin. 

If you can identify clear candidates for plugins in the current code,
then moving to a plugin architecture for a rewrite makes sense.

Emacs Ada mode makes an attempt to support different backends for
indentation, compiling, and navigating (cross-reference). It's fairly
clean. It would be cleaner with eieio classes.

> If someone wants to resurrect jde-debug from JDEE into the new
> version, then that person creates a new Emacs plugin that fits in some
> next gen JDEE plugin architecture. 

If jde-debug is a Java/JVM backend for Emacs gud, then gud already has a
plugin architecture for its backends; it has very little to do with the
main jde mode. For example, there is no code related to gud in Emacs Ada
mode.

> This gets rid of some bloat ini the core next gen JDEE.

Perhaps it just needs to be split into separate Gnu ELPA projects.

> - Who has the time and initiative to help out (I can't do it all
> myself with current time constraints)

I'd like to work on getting the current code working with emacs master,
each depending on jde-core.

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

Keep jdee, just do a major version bump.

-- 
-- Stephe

------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/