Oh No Vector!

The superest hidden feature of NetBeans IDE 7.1 is about to be revealed. Check it out:

Above, you see a piece of code in the JFugue Music NotePad. It's an old piece of code from several years ago, hence you see a Vector being used. In NetBeans IDE, Vectors are recognized by the hint infrastructure and you are given a tip that you have an "Obsolete Collection".

However, that's not the only thing I see when I click on the lightbulb next to the Vector declaration above (i.e., the 2nd lightbulb above, the first is there because an @Override could be added):

Wow... NetBeans IDE offers to rewrite my Vector to a List. So, I press Enter and the conversion is done for me. Then I click the next lightbulb, i.e., because "addElement" applies to a Vector, but not to a List, and I see this:

OK. Thanks for the suggestion NetBeans IDE and so I press Enter again. And now the changes are as follows:

Nice, right? And how is this done? Because I created the folder/file structure that you see below, i.e., look at META-INF.upgrade, with its content, i.e., a plain file ending in ".hint":

In that file, I have provided a piece of NetBeans Inspection Syntax. It tells the IDE what kind of code structures to look for and how to transform them.

The above syntax is definitely suboptimal, I don't understand it all yet, but it works. I learnt the basics this afternoon from NetBeans engineer Jan Lahoda at the NetBeans booth at JavaOne. The above is similar to or based on Jackpot Rules. It is not intended to be used in the way shown above, since there is a special GUI for the above in the "Inspect & Transform" dialog, hence you're able to apply the above rule to a scope of your choosing, i.e., I'm able to find all the above Vector structures throughout the music application and transform them, which is something that the related NetBeans standard hint doesn't let me do. But, though it's not the way you will optimally provide these rules, it's interesting to see this underlying functionality and how effective it can be.

Comments:

Would it be possible to create such a refactoring rule to automatically add "@Override" on all methods in a Java file when the hint says so? I hate doing that myself when I open an older Java file not adapted yet that has tons of missing overrides. This also happens with some code generators that don't care about Java > 1.5.

Posted by jmborer on October 04, 2011 at 07:50 PM PDT #

Is it possible to see all the hints together for a project?

Posted by Gábor Tóth on October 04, 2011 at 08:04 PM PDT #

Thanks Geertjan for this tips

Is it possible to apply this rules on a whole project?
For example to automatically transform Vector in List not only each time is appear in each class but for example to be able to right click on the project/src and choose an hint to apply everywhere.

thank's in advance.

Posted by guest on October 04, 2011 at 08:04 PM PDT #

Actually, the rebirth of Jackpot, whichever is the new name of this stuff, is very much appreciated! :-) I instaled 7.1-beta yesterday and started playing with it...

Posted by Fabrizio Giudici on October 04, 2011 at 08:05 PM PDT #

Thanks Geertjan for this tips

Is it possible to apply this rules on a whole project?
For example to automatically transform Vector in List not only each time is appear in each class but for example to be able to right click on the project/src and choose an hint to apply everywhere.

thank's in advance.

Posted by thfaure3 on October 04, 2011 at 08:05 PM PDT #

I can change Vector to List and use Ctrl+Del to remove the Element part, just as fast. Faster actually, since I don't have to write a text file beforehand. Plus, what if Vector was used because synchronization was actually needed?
Useless feature, I'd like the UML plugin back instead.

Posted by alex on October 04, 2011 at 08:56 PM PDT #

Cool. Code refactoring and other meta stuff like this is brilliant! Keep up the good work... Jan Lahoda and others who figure out how to make it possible.

Posted by guest on October 05, 2011 at 06:29 AM PDT #

Alex, you can do this easily in a manual way only when you have a single portion to change. Not so easy if you have to upgrade hundreds of instances in a large codebase. Furthermore, much more complex stuff can be done, that wouldn't be as easy with a textual search & replace, and Geertjan is going to show us.

Posted by Fabrizio Giudici on October 05, 2011 at 06:51 AM PDT #

Why do they obsolete the Vector when there is no suitable substitute? Last I checked the docs for JDK7 one still could not instantiate any of the default models (i.e. DefaultTableModel, DefaultListModel, DefaultComboBoxModel) with an ArrayList. I don't know if the Object[][], Object[] constructor will work with ArrayList objects or not but if it does it's still a kludge. So until the default models have an ArrayList constructor they should knock off the deprecation of Vector!

Posted by guest on October 05, 2011 at 12:39 PM PDT #

Interesting factoring but dangerous : Vector is synchronized and ArrayList isn't. Does the original code need a synchronized or not collection ?
This kind of refactoring with only one choice can generate a lot of bugs. It should be better to offer synchronized or not correction.

Remark : I don't have the refactor tip on my 7.1beta NetBeans ???

Posted by guest on October 10, 2011 at 08:56 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
12
13
14
23
24
25
26
27
28
29
30
   
       
Today