Hacking JRefactory

JRefactory is a large project, too much for one person to make rapid progress in fixing bugs, adding features and supporting plugins for all the Java IDEs. We need your help!

What needs to be done.

The JRefactory sourceforge project Feature Request page contains a list of enhancements that have been requested. See also the requested feature page here.

Plugins for

There are lots more refactorings to be added, I reckon about 30 (including those for generics and annotations).

Design patterns analyser/advisor

Objective - to be able to detect common design patterns (such as immutable objects, factories, JavaBeans) and classes that nearly obey those patterns (e.g. a class with only one mutator method).

Generate JavaDoc in the pretty-printer for the detected design patterns. Advise on how to transform classes into those that obey the patterns, including the possible refactoring required.

Common Code Detector

The cut and paste detector (inherited from PMD) does a good job of finding cut and pasted sections of code. But it only works if the tokens are exactly the same.

It would be nice to have a Common Code Detector that finds code segments that are similar (but not identical).

For instance:

Such common code segments are ripe for refactoring, especially within a class or between classes in a heirarchy.

An added feature would be to create the refactoring required to eliminate the common code.


JSR 163 - JavaTM Platform Profiling Architecture is defining a new profiling architecture to replace JVMPI.

For refactoring it is useful to know where the hotspots in a program are.

The task would be to create a JPPA client to fit into JRefactory and use it to mark classes and methods within the class diagram as regards to processor usage and object creation. Starting and stopping the target program profiling during a run would allow profiling during specific sections of a targets operation. It would be great to include animation of the class diagram (changing colours of the classe & method hotspots as the target runs).

JSR 198

support and implement "A Standard Extension API for Integrated Development Environments" when it becomes available.

Implementing a plugin

The main interface between the common code and the plugin is:

all plugins should implement this interface, but not all of it needs to be implemented for each of the components.

In general the jEdit plugin is the most advanced because that is the one for which features are implemented first. So you should look there for hints on how to implement a feature for other IDEs.

There are several concepts that should be implemented.

Note that at present there is an old singleton EditorOperations (and its subclasses) that duplicates some of the IDEInterface. This will be removed and its functionality merged with IDEInterface.

JavaStyle properties

The file src/ui/JavaStyle.props contains all the strings for the common part of JRefactory.

Each plugin should have its own properties, the format of these is plugin specific but see jEditFile/JavaStyle.props and other files in that directory for how jEdit specific properties are implemented.

Specific properties for other IDEs should go in their own directory or in the org.acm.seguin.ide.<IDE name> directory as appropriate for the IDE.

The manifest files for the IDE plugin should go in src/meta-inf.

The build file

The main build file is build.xml in the top level directory. It may be advisable to have an IDE specific build file that is useable from within the IDE, often it is easier to develop a plugin from within the IDE environment.

The build file should place built jar files int ant.build/lib/<IDE name> and zip files containing the distribution in ant.build/dist.

In general the build.xml ant build file should have three targets per IDE:

which compile the plugin, create the jar file(s) and create the distribution respectively.

Last Modified: 3 November 2003