[ANN] Rearranger plugin ver. 0.5

The rearranger plugin rearranges (reorders) class definitions within a Java file according to rules specified by the user.

Version 0.5 adds the ability to alphabetize items in a particular group as they are moved to the front.

It also fixes a bug with the Move Up/Move Down buttons (which had only temporary effect).

Protection level and method type configuration no longer requires at least one to be selected. If none are selected, then protection level or method type criteria are ignored when selecting items.

The plugin requires EAP build 944 or later.
See http://www.intellij.org/twiki/bin/view/Main/RearrangerPlugin.

-Dave

13 comments

Hi Dave,

On 2003/10/20 23:01, Dave Kriewall wrote:

Version 0.5 adds the ability to alphabetize items in a particular
group as they are moved to the front.


I love this new functionality! However it made me realize I always
position the "public static void main" method at the bottom of a class
definition. So I now have another feature request:

Please, allow to specify the identifier as an "Item Attribute". Then I
can specify the public and static methods with the identifier "main"
need to be at the bottom of the class definition.

Thanks,
Bas

0

And I have a small bug to report. The Rearranger settings page always
thinks that something has changed.
To reproduce:
1. Go to "IDE Settings"
2. Select the Rearranger tab
3. Select another tab (e.g. TODO)
Result: get a "Save Changes" dialog.

Thanks,
Bas

On 2003/10/20 23:01, Dave Kriewall wrote:

The rearranger plugin rearranges (reorders) class definitions within
a Java file according to rules specified by the user.

Version 0.5 adds the ability to alphabetize items in a particular
group as they are moved to the front.

It also fixes a bug with the Move Up/Move Down buttons (which had
only temporary effect).

Protection level and method type configuration no longer requires at
least one to be selected. If none are selected, then protection
level or method type criteria are ignored when selecting items.

The plugin requires EAP build 944 or later. See
http://www.intellij.org/twiki/bin/view/Main/RearrangerPlugin.

-Dave


0

Debugger in Project properties and Weblogic in IDE settings also have this odd problem.

Anyway, this plugin is on my must-have list now. I love it.

0

Noticed a slight problem
if you have
public/private/protected/package getter/setter/other methods (alphabetized) the alphabetizing doesnt work.

If you separate them, it does work.
public/private/protected/package getter/setter (alphabetized)
public/private/protected/package other methods (alphabetized)

0

I should also add ability to order a class's static initializer. (Note to myself..)
-Dave

0

Bas,

And I have a small bug to report. The Rearranger settings page always
thinks that something has changed.


it's fixed in 0.6.

-Dave

0

Andre,

Turns out selecting more than one method type (constructor, getter/setter, other) would always fail to select any method. I was ANDing instead of ORing the test, and no method is both a getter/setter and other type. :-Duh

Fixed in 0.6.
-Dave

0

Careful with that. The order of static fields and static initializers is semantically important, and should not be altered, as it could produce uncompilable code. One could argue that any code which depends on this language feature is bad, and I wouldn't disagree, but there's a lot of bad legacy code out there.

0

Interesting. I wasn't aware that that order was important. In a small test declaring a static field and static initializer that initialized the field, it seemed to compile whether the field preceded or followed the static initializer.

Regardless, would it be safe to assume that if all static fields preceded the static initializer, it would always compile?

0

Looking it up, I was incorrect about it being a breaking the compilation. It's worse: things will actually break at run-time, with potentially subtle bugs. See 2.5.3 of the JLS (3rd edition). Static initialization occurs in the order that the static fields and static initializers are present in the class. If you reorder them, things may break. If the static fields have no initializers, or if the initializers of the fields are not dependent on the static initializers (and vice versa), you can reorder safely.

I thought of this because it actually bit me once when I was doing some reordering. Not a common problem, but one you should be aware of.

0

Oh, lovely.

Not sure I could do anything to prevent it by implementing restrictions in the UI, e.g. by disabling the 'alphabetize' checkbox when static fields are being selected. That might prevent some reordering, but not necessarily all of it.

I suppose I could internally prevent rearrangement of any static fields with initializers with respect to themselves and the static class initializer, if present. Static fields without initializers should be able to be relocated freely.

I'm not really interested in figuring out the dependencies and permitting harmless rearrangements to occur, though. :)

Thanks for bringing it to my attention.
-Dave

0

Actually, now that I think of it, you could already be facing such issues, just by rearranging fields, if one field's initializer depends on another field. Given that, it's probably worth just saying "if you have such pathological dependencies, your rearrangement had better match them, or it's your problem when it breaks". I had intended an inspection for such ordering issues, but the dataflow equations are tough enough that I've been deferring it. I don't think anyone would mind if you ignored these issues.

--Dave

0

OK, then I'll leave it the way it is. (Phew!)

0

Please sign in to leave a comment.