Hello everybody!

A roadmap can be based on what is most commonly used in different Java
IDEs:
 1. Easy installation and configuration
    No one will use JDEE if it takes a weekend to make it up and
    running.
    For example available JDKs (jde-jdk-registry) usually can be setup
    automatically from: JAVA_HOME, default paths in OS (/usr/lib/jvm,
    "C:\Program Files\java", etc.).
 2. Integration with build tools (especially Maven)
    By that I mean loading project configuration (source/test
    classpaths) form build tool definition - pom.xml in case of Maven.
    This is a must for any non-HelloWorld project.
 3. Code completion
    IMHO from this point JDEE can be used at all.
 4. Jumping around the code - back and forth.
    To types/methods/fields at point, even if they are in external
    libraries (sources usually can be downloaded from Maven repo).
 5. Finding usages of fields, methods, types.
    I use it everyday for finding dead code. It's also for refactoring tools.
 6. Debugger with GUI.
    There was such project. Maybe it could be integrated with JDEE sometime. 
 7. Jump to compilation errors
    During editing and form build tool window.
 8. Execution of selected tests (especially currently edited one)
    It's just TDD routine.
 9. The most common refactorings
    Rename field/method/class. Extract method. Move class (for example
    static nested class to it's own file).
 10. Easy way to write extensions for JDEE.
 11. Configurable indentation.
 12. Facets/extensions for common technologies (Spring, JPA/Hibernate):
     - indicate which classes are Spring beans
     - jump to a bean definition
     - find beans implementing given interface

It's just a roadmap, my idea for what's important for any Java
development. You even don't have to agree with it and can pipe
to /dev/null. :-)

Of course Java IDEs have many more features, but from what I've seen for
past 9 years of work as Java developer most of work is concentrated
around writing tests, code, simple refactorings, and jumping around the
code. :-)

IMHO from the development perspective, it would be cool to write some
unit tests for features (especially in elisp). In Java world it's a
standard. If someone is not used to it I just can tell that it prevents
regression and enables refactoring. If it's not a standard practice in a
project, then it quickly becomes unmaintainable and sooner or later
dies.

BTW As a developer I can contribute Java, elisp, and some Clojure if needed.

Cheers,
Przemek

------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
jdee-devel mailing list
jdee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jdee-devel

Reply via email to