Re: [JPP-Devel] Some thoughts for future work on the user interface

[<edg...@we...>]

On 18.03.2011 03:26, Martin Davis wrote:
> 
> * Without knowing more about the impacts on the development process, I'd say I'm not really in favour of introducing Groovy into the core JUMP codebase.  It seems like it might complicate coding (especially for people who don't grok Groovy).  It seems like it might complicate upgrading to new versions of Java (how well does Groovy track Java?).  And does Groovy have limitations in support by the various popular IDEs?  It would be nice to have OJ easily used by any Java coding environment.


I second that.
but
I'd say, if Benjamin really does not want to do a new GUI in java, than it is his decision to do it with groovy. After all he's doing it in his spare time. It will be in a separate jar and an addition for quite while. No harm, just possibilities. 
though
If anything happens to the groovy project, an essential part of OJ, the GUI, might be unmaintainable. (When e.g. oracle breaks backward compatibility in a way that affects an unmaintained groovy. The surface for such an event is bigger, because not only runtime libs, but also the compiler is in java.) This should be considered.


> * I agree with keeping dependencies as small as possible.  This especially applies to "the core".  The core could actually be thought of as a few concentric rings of things: the Feature API, the I/O framework (and drivers, including DB drivers) the Workbench and plugin framework, the GUI, and finally all the various extra plugins.  With reference to inode, I'd worry about introducing a dependency for such an important part of JUMP (the GUI). What happens if inode is no longer maintained?  Once that road is followed for any distance it's pretty hard to go back.

But what's the alternative. Writing it from the scratch leads to the same road of maintenance and using another library does not guarantee it is maintained forever.


regards ede