e4 - Eclipse 4.x - Second Impression

I have been using the latest builds of Eclipse 4.x SDK for my daily work for the last 6 weeks. The overall stability has improved gradually, and the NPEs are quite rare now. Some of the bugs I filed were also fixed  quite quickly during M3 - Bug 325834 , Bug 327154. But there are still a few things which must work but don't.

• Ability to customize a perspective (Bug 320478)
• Ability to set or change key bindings (Bug 317299)
• Plus I am a bit confused about the 'Editor Area' introduced in 4.1 M3. Does this mean I should not create multiple editor stacks? Should I create multiple editor stacks only in the editor area? Will this editor area continue to take extra space as it does in M3? In 3.x we had a editor only area, are we going back towards that? M4 is supposed to have a more polished implementation of the 'Editor area', I will wait for that.

I am also hoping that Editor tab rendering could be improved significantly in Eclipse 4.x (Bug 325422).

e4 - Eclipse 4.0 : First Impression

Looks a bit funny

Off is On and On is Off - I saw that Build Automatically was Off so I switched it On, and then my code changes had no effect... few minutes later I realized that if something is turned Off in the UI, it may mean that it is actually turned On! e.g.Mark Occurrences, Build Automatically.  Or in the case of 'Edit > Smart Insert Mode' I cannot even toggle it.

Layout and minimized Views - I like the overall layout and the fact that I can put views in the editor area. I also like the way when minimized views are selected they open in a pop-up sort of a way. Overall the UI/layout feels nice.

Custom Key Bindings - mmh...

Order of menu and toolbar items - The ordering of items in menus and toolbars can be a bit different from 3.x versions. e.g. navigate menu, run/debug toolbar

I can use it for my daily work, except for some minor glitches and some funny behavior I have been able to use it for last few days. And I do like the layout, mixing of editors and views, and the overall feel of the UI to not go back to 3.x (at least for now).

New Command in JDT : Open from Clipboard

This is what I used to end up doing very frequently
- copy something like String#getBytes from a bug comment
- press Ctrl+Shift+T in Eclipse
- paste the copied text Open Type dialog
- argh... no matches
- delete the method name
- open the type in an editor
- press Ctrl+O
- argh.. what was that method again?
- go back to bugzilla and read/copy the method name
- come back to Quick Outline and filter the method
- and finally reach the method

The new command opens a Java element or a Java stack trace from clipboard. If the clipboard content spans multiple lines then the it is pasted to the Java Stack Trace Console. If the clipboard content is a single line the command tries to open the matching Java element in an editor. Some examples

• java.lang.String
• String#getBytes
• java.lang.String.getBytes(String, int[], int)
• String.java:123
• at java.lang.String.matches(String.java:1550)
• java.lang.String.valueOf(char) line: 1456  

I use this command with a key binding of Ctrl+Shift+V. After doing a Ctrl+C the most natural thing to do is Ctrl+V so the key binding for this command should be similar. Plus Ctrl+Shift+V is also similar to Ctrl+Shift+T and Ctrl+Shift+R, making it a bit easier for me to remember it.

This command (Bug 48880) is already in nightly builds and will be in the today's I-build.

As a final note I should also mention 2 'nasty' Platform bugs that I faced while implementing this command

• Bug 324160: [Commands] Platform should support to use the action IDs from the action set contribution in menuContribution
• Bug 324161: menu contributions added using 'endof' should appear before contributions added using 'after'

I say nasty because in its current form the whole menu contribution, command, actionSet, action story can be very confusing...

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.