image provider



This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.

This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.

Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.

Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.

You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.

Please do not email me about this project without reading the disclaimer above.


There used to be a plug-in for IntelliJ, called The Rearranger, that sorted your Java declarations and methods in a user-defined order. IntelliJ replaced it with a much less capable, non-configurable built-in plug-in. Your mission in to create a configurable standalone Rearranger and after you have tackled that convert it to run as a plug-in for the popular IDEs (Integrated Development Environments) — namely IntelliJ, Eclipse and NetBeans.

This is not a Java beautifier. It does not change the indentation, wrap lines, change the white space. It just puts code in standard order.

Sorting Program Elements

The original version was configured with a complicated script. I suggest implementing the project by allowing the user to write five Comparators instead to define his order preference:

  1. Comparator<DeclarationItem> for declarations
  2. Comparator<MethodItem> for methods
  3. Comparator<ClassItem> for classes
  4. Comparator<EnumItem> for enums
  5. Comparator<CaseItem> for case statements

This gives him the full power of Java to explain his desired order.

A dummy Comparator just leaves things as is.

To reorder the declarations, the user writes a class that implements Comparator<DeclarationItem>, or modifies one of the sample Comparators you provide, or selects a pre-written one. It sorts objects that implement the DeclarationItem interface:

You have to use a parser such as ANTLR (Another Tool for Language Recognition) to parse the declarations and summarise the results with a DeclarationItem object for each declaration, then sort them using the user-supplied Comparator<DeclarationItem>. Then reconstruct the source code from the list of DeclarationItem objects which contain references to the original source code. The problem with using a parser, is the source code must have perfect syntax before it will touch it. The problem with using something cruder is it can do serious damage rearranging a program with unbalanced {}. If the net effect of your rearranging is to leave the program as is, make sure you do not write it back or redate it.

In a similar way, you define interfaces for methods, enums, cases, classes, etc. and sort them too.

Sorting enum constants works much like the interface for methods:

Here is the interface you would use to sort switch case clauses:

And finally here is the interface you could use to sort classes.

Some orderings are fixed, e.g. package, import, static init. import items are already well handled by the IDEs. There is no point in sorting them when the IDE (Integrated Development Environment) will immediately reorder them.

Inserting Comments

The original Rearranger also let you insert comments in front of groups of declarations or methods. You could use the same interfaces, feed the declarations to some user code, that would return a group comment for each entry. You would discard duplicate comments, so that only the first entry with a given comment would show the comment. You would run this process as a second pass after all were rearranged.

I have written a very primitive version of this project. It does not use a parser. It works by you manually inserting comments to delimit the methods. See SortCode. In most cases, you can get the ComparatorCutter utility to write the various Comparators for you. Just specify the precedence of the various fields with ascending/descending.

The generated comments should be easy to tell apart from regular comments both by eye and by machine so you can automatically remove old comments before inserting new ones. I suggest they might look something like this:

//!! p u b l i c s t a t i c m e t h o d s

The exact wording and the categories would be up to the user. They might specify:

return "public static methods";

as the groupComment when passed a MethodItem.


This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products
Please the feedback from other visitors, or your own feedback about the site.
Contact Roedy. Please feel free to link to this page without explicit permission.

Your face IP:[]
You are visitor number