JDT 3.7 M1 - New and Noteworthy

Filter preferences on Java > Compiler > Errors/Warnings page

We have just too many options on this preference page (as does PDE and API tooling on some of their preference pages) and finding the option you are looking for can be quite difficult (and frustrating) with all the twisties and so much of scrolling involved.

You can now filter preferences on the Java > Compiler > Errors/Warnings page by preference label text or by preference value. A word in the filter string preceded by '~' is used to filter on preference values. Examples:

• param
• ~off
• ~ignore
• param ~enabled
• ~ignore param

Bug 321818 is the next item to do - allow to filter a section for a value e.g. 'code style ~error.

New 'Open Hyperlink' command

The new Open Hyperlink command opens one or more hyperlinks at the current caret location. The command has been added to the Navigate menu for the Java and properties file editors and can also be used in other text editors by assigning a key binding on the General > Keys preference page.

The command opens the hyperlink directly if there's only one link available. Otherwise, it shows a chooser with all the available hyperlinks at that location. The links are the same as when you move the mouse with Ctrl pressed.

So now you can assign a key to this command (say F6) and then use this command in Properties files to navigate to NLS key references, in Java editor to navigate to declaration or implementation for a method,and declaration for other Java elements, or for any other hyperlinks.

In short you can possibly stop using Open Declaration (F3) and start using this new command - depending on whether or not you would like to always make a choice between navigating to declaration or navigating to implementation for method invocations :)

Other New and Noteworthy items.

CVS vs Git: Local disk usage

I was a bit skeptical about the local disk usage with Git, as every Git clone is a full-fledged repository with complete history, and apparently Git stores entire snapshots and not the deltas.

Everyone seemed to be claiming that Git is quite efficient in terms of storage space required, and I also found the following statistic on the web
"The Mozilla CVS repository was 2.7GB, imported to Subversion it grew to 8.2GB. Under Git, it shrunk to 450MB. Given that a Mozilla checkout is around 350MB, its fairly nice to have the whole project history (from 1998) in only slightly more space."
Source: http://keithp.com/blog/Repository_Formats_Matter/

But I was still a bit skeptical... :)

So I downloaded some of the JDT source from Eclipse Git repositories and compared the disk usage under Git with CVS. Here are the numbers. For these selected projects, Git on an average takes less than three times the space required by CVS. In my opinion this cost is nothing as compared to the benefits of having the entire history locally.

Eclipse Helios

Going through the Helios Reviews I see that a number of bloggers have said good things about the new features in JDT :)

If you have not yet seen the new features of JDT then check out the 10 minute demo I recorded last month. This video shows what's new in JDT for Eclipse 3.6, the Helios release.What's shown in the video is just a part of all the new stuff within JDT. For more information see the 'What's New' document in the Java development user guide.

My favorite features being

• Java breakpoint detail - No more opening a new dialog for editing breakpoint properties, I just love this one.

• Package name abbreviations - This is a simple but very useful improvement, makes the Package Explorer a lot less cluttered.

• Remove nodes from Call Hierarchy - While this is useful now, it should become better once Bug 304135 (Allow to pin Call Hierarchy) gets fixed.
  

• Fix multiple problems via problem hover - This saves a lot of effort.

Work on Eclipse Indigo is already in full swing with M1 coming up next week. Some nice features have been implemented in M1, bugs - 78522 , 277862 , 315772 , 320876 , 310470.

Too many options in Eclipse?

At times I wonder if we have too many actions, key bindings, preferences etc in Eclipse. I mean a beginner would probably find  number of key bindings in the Ctrl+Shift+L pop-up overwhelming. This pop-up lists a number of 'Show View' key bindings, but I think listing only Quick Access (Ctrl+3) should suffice - at least for beginners.

This raises another question - how many users of Eclipse are beginners, how many some what comfortable, how many expert. I would assume a significant number in each category. Maybe we should have beginner, intermediate, expert modes/perspectives. For example in the beginner mode we can hide (not disable) the actions and preferences which are typically used by power users.

Mac : Windows :: iOS : Android ?

In the late 70s and the early 80s Apple computers were the coolest devices around and everyone wanted to have one, and then Windows came along firstly with IBM PCs and then with IBM PC clones, i.e. Windows worked on hardware sold by most manufactures.

Now in 2010, iPhone is the coolest device out there and everyone wants to have one, but Android has come along which works on hardware sold by a number of manufactures.

Is history repeating itself?

The Executive Dashboard 2010

This is the Executive Dashboard as presented at IBM Rational Innovate 2010. This looks to be quite a bit more sophisticated than last year.

Printpoints : Debugging by writing to console

There are two ways of debugging

• Breakpoints - I typically use breakpoints when
• I do not have much idea of the code and need to inspect variables and expressions at a number of places to gain an understanding of what is happening.
• I am making some changes and want to see how these changes affect a particular variable/expression, also I am confident that one or two iterations of this change-test process will suffice

• Printpoints - There are scenarios when the breakpoints fail or are inefficient, in these cases I just use System.out.println(). This is typically when
• the breakpoint hits too often, for example keypress, focus, mouse events
• I want to see the order of thread execution
• I am making some changes and want to see how these changes affect a 'few' variables/expressions, also I am confident that it will take 'a number' of iterations of this change-test process to fix the bug. Printing everything to console in this case proves to be much more efficient than stepping through the code.
  

Most developers (including me till recently) insert the print statements in their code and the problem with that is that you have to take them out later. I know you can sometimes leave them in the source as tracing statements, but most of the time they have to be taken out. But there is a solution...

The conditional breakpoint editor in Eclipse can be 'tricked' to create what I like to call as Printpoint - and define as a 'point' in code where the debugger does not 'break' but only 'prints' to console. Essentially a Printpoint is a conditional breakpoint that never suspends execution but only prints to console. To set a printpoint, set a conditional breakpoint with Suspend when 'true' option and a condition which is always false. e.g.

Code templates are available in the condition editor, so you can create a template under 'Java statements' context and use it here. Bug 315404 has been filed to have this available in JDT by default.