Active JDT Committers

In my talks on JDT I generally include a slide with the above image. I thought I should also write a post and include the following bits of (interesting) information about the committers.

• JDT committers are spread over 3 continents, 4 countries and 5 cities.
• More than half (6 out of 11) of active committers are based out of Bangalore, India.
• Dani and Olivier have been there since the very beginning of Eclipse, and Markus has been a JDT committer since 2003.
• Srikanth has been working on compilers and related technology forever.
• In all eight to nine languages can be spoken in the team. Even the commiters in Bangalore speak many different languages, for instance I can communicate in my mother tongue, Hindi, only with Ayush. Hence, we pretty much communicate in English :-)
• Unfortunately the team is dominated by men with Raksha being the only member of the fairer sex.
• Ayush at 24 is the youngest committer in the team and I come a close second at 25. 

Annotation based null analysis with JDT

Eclipse Juno M4 includes support for annotation based null analysis. To take advantage of the feature enable the preference shown below and start using the default annotations mentioned in the text fields.

You will also notice that all the null analysis related options have moved to a new group on the preference page.

As usual feedback is extremely welcome especially in form of bug reports :-)

UPDATE: JDT provides default annotations which are shipped in org.eclipse.jdt.annotation bundle with the Eclipse SDK. However you are free to use your own annotation types, just specify the custom annotations in the preferences.

CodingSpectator: Research study on Eclipse

These guys have been contributing to JDT by reporting a bunch of bugs based on their findings, so I thought I should talk about them :)

The aim of CodingSpectator project is to study how developers interact with the Eclipse IDE, by collecting and analyzing usage data. CodingSpectator has been developed at Ralph Johnson’s research group by the following graduate students: Mohsen Vakilian, Nicholas Chen, Stas Negara, Roshanak Zilouchian and Balaji Ambresh. Ralph is a co-author of the seminal book on design patterns (GoF) and his research group has a history of important contributions to IDEs. CodingSpectator monitors programming interactions non-intrusively in the background and periodically uploads it to a secure server at UIUC.

They have presented some of their findings in this technical report - Use, Disuse, and Misuse of Automated Refactorings. Based on the same report they have reported a number of insightful bugs against JDT and also provided suggestions on how some of the refactorings can be improved. A few bugs have already been fixed. In addition their technical report also improved my understanding of an average JDT user's behavior. Thanks guys! 

Probably the biggest challenge with a usage study is finding a good number of participants. They are looking for more participants in order to continue their research study. If you’re interested in helping the researchers out, you could install CodingSpectator. 

Detecting resource leaks with Eclipse JDT

You can now detect resource leaks with Eclipse JDT. The following 3 warnings have been added, and the defaults are as shown (this feature is available in I-Builds starting Oct 4 )

For the purpose of this analysis, a resource is a local variable of type java.io.Closeable in pre-Java 7 world and in Java 7 world a resource is a local variable of type java.lang.AutoCloseable. (Note that in Java 7 java.io.Closeable extends java.lang.AutoCloseable)

To take a few examples

• if close() is never called on the resource a 'Resource is never closed' warning is emitted

• if close() is called but not on all code paths, the warning indicates the locations where the resource is not closed

•  if a locally created resource is passed to another method, then it cannot be ascertained what that method does with the resource, i.e. the method may or may not close the resource, e.g. in the snippet below a helper method is used to close a resource, however one may also create helper methods to perform other tasks. Hence, in these cases the warning is a 'Potential resource leak' and this warning is not enabled by default.

•  if a resource is correctly closed, and the compiler compliance is 1.7 then Eclipse suggests to use the new try-with-resource statement

Several other cases are also handled, e.g. a resource is returned from a method, a resource variable is reassigned etc. However, we may have missed something, hence bugs, suggestions and comments are welcome!

Most of the credit for this feature goes to Stephan Herrmann, in fact I often wonder how he gets time to contribute so much to JDT given that he has a day job and is also the lead of the Eclipse Object Teams Project. Thanks Stephan!

Java 7 Support in Eclipse 3.7.1, 3.8, 4.2 builds

So far the Java 7 support work was done in the BETA_JAVA7 branch. This branch has now been merged to HEAD and R3_7_maintenance. As a result all upcoming 3.7.1, 3.8 and 4.2 builds will fully support Java 7 development.

Java 7 Support in Eclipse JDT (BETA) - Part III

I have already talked about adding Java 7 support to your Eclipse 3.7 or 4.1 install. Last week I also talked about the new features in JDT for Multi-catch, try-with-resources and Simplified Varargs Method Invocation. Now I will talk about Improved Type Inference for Generic Instance Creation (Diamond).

This language change allows explicit type arguments to constructors of parameterized classes to be omitted in many situations. The compiler infers the omitted type arguments based on the expected type.

The JDT compiler detects redundant specification of type arguments, which you can remove via Remove type arguments quick fix.

 

 This warning can be configured as shown below.

 
 You can also insert inferred type arguments via a quick assist.

Where possible, Content assist inserts diamond instead of explicit type arguments.

Future items: We plan to show the inferred type arguments right in the constructor hover, see bug 351048. In 3.8 we also plan to provide Remove redundant type arguments as a cleanup, see bug 351956.

Note that the type inference done by the compiler can at times be non-obvious. For example, at first glance the following two methods might appear equivalent, when in fact the one with conditional operator has an error.

An analogous example from the pre-Java 7 world.

Java 7 Support in Eclipse JDT (BETA) - Part II

I have already talked about the new features to support multi-catch in an earlier post. Now I will talk about Try-with-resources statement and Simplified Varargs Method Invocation.

The compiler detects unhandled exceptions thrown by automatic/implicit close() invocation on a resource.  

With Mark Occurrences enabled, the closing '}' of a try-with-resources statement is marked as a method exit point if the implicit close() invocation throws an exception. The corresponding resource variable is also highlighted.

Future items: In 3.8 we plan to add warnings to indicate that a resource is not closed, see bug 349326. In Java 7 a resource is a subtype of java.lang.AutoCloseable and in the pre-Java 7 world a resource is a subtype of  java.io.Closeable. Based on these warnings we will also provide quick fixes/assists and clean-ups to enclose a resource in a try-with-resources statement, see bug 349390.

A new quick fix Add @SafeVarargs is offered for potential heap pollution warnings on method declarations.

Add @SafeVarargs quick fix is also offered from call sites.

Remove @SafeVarargs quick fix is offered for incorrect usage of @SafeVarargs annotation.

Note: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP.

Java 7 Support in Eclipse JDT (BETA) - Part I

JDT team has been working overtime over the last few months on the Java 7 support. The compiler is rock solid now and the UI is looking good with a number of new features. You can add the Java 7 support to your existing 3.7 or 4.1 install by following the instructions on http://wiki.eclipse.org/JDT/Eclipse_Java_7_Support_(BETA).

This post is the first in a series in which I will talk about the new features in JDT for Java 7. In this post I will focus on Multi-catch.

The new action Source > Surround With > Try/multi-catch Block allows you to surround the selected statements with a try/multi-catch block. This is also available as Surround with try/multi-catch quick fix in case there are multiple uncaught exceptions.

The new Add exceptions to existing catch clause quick fix allows you to add uncaught exceptions to an existing catch clause.

You can replace a multi-catch clause with individual catch blocks via Use separate catch blocks quick assist. The quick assist will create separate catch clauses for all the exceptions.

You can also pick out one or more selected exceptions from a multi-catch clause via Move exceptions to separate catch block.

The new Combine catch blocks quick assist allows you to combine separate catch blocks into a single multi-catch block, pretty useful for migrating existing code to Java 7. The quick assist is offered only when bodies of all the catch blocks are same, we still need to make it a little more smarter, see bug 350308. In 3.8 we will also provide this as a clean-up (bug 351179).

The compiler gives an error if an exception in a multi-catch clause is already caught by an alternative exception. The new Remove exception quick fix allows you to remove this exception.

Mark Occurrences has been updated to understand the multi-catch syntax.

There are also new Line Wrapping options in the Formatter for the multi-catch syntax.

Note: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP.

JazzHub

JazzHub is a free, public, hosting hub for the open development of academic research and classroom projects. Currently it is in limited beta. To participate in the beta you can request a project creation code.

On JazzHub students and professors can plan projects, collaborate on source code, and track progress, all with the latest Jazz technology in Rational Team Concert.

• Source code management
• Work Item Tracking
• Project and personal dashboards
• Agile planning
• Reporting
• Web, Eclipse and Visual Studio interfaces 

Rational Team Concert (RTC) is also available FREE of charge for qualified open source projects, academic institutions, and research projects. Steps to help you get started are available here. You can also read about RSSOwl's adoption of RTC, this also includes a great video which illustrates how the developers can benefit from RTC.

You can learn more about JazzHub at Innovate 2011, Bangalore. If you're a student, you can also win free passes to Innovate by blogging or tweeting about rational products (use hashtag #innovateindia). 

Java 7 Support in Eclipse JDT (BETA)

Java 7 is not publicly released yet and hence the Eclipse Java 7 support could not be shipped with 3.7 or 4.1. However those who want to use it in 3.7 or 4.1 can do it using the install instructions mentioned on http://wiki.eclipse.org/JDT/Eclipse_Java_7_Support_(BETA).

If you find a bug or have ideas on new quick fixes / refactorings / templates / ... , please file a bug with the [1.7] tag !

I should add that this is a work in progress, and more details are available on the following two wiki pages

• http://wiki.eclipse.org/JDT_Core/Java7 
• http://wiki.eclipse.org/JDT_UI/Java7

Note: This is an implementation of an early-draft specification developed under the Java Community Process (JCP) and is made available for testing and evaluation purposes only. The code is not compatible with any specification of the JCP.

JDT Tip: See different hovers in Java editor by using modifier keys

•  When you move the mouse over an identifier that has no error or warning, by default a hover with the Javadoc is shown. 

• However if there is an error or a warning on the identifier then the corresponding message is shown.

  

• To see the Javadoc even in this case, you can enable the Javadoc hover on this preference page and define a key modifier e.g. Ctrl+Shift. 

  

• Now press Ctrl+Shift while hovering to see the javadoc.

JDT Tip: Mark Occurrences in Java editor

I think everyone knows that the Java editor highlights occurrences of variables and method calls.

But did you know that it also highlights

• Method exit points - select (or place caret in) the method return type

• Method calls or statements throwing an exception - select (or place caret in) an exception in a catch block

• Break/Continue targets - select (or place caret in) break or continue keywords

Mobile sessions at IBM Innovate

Attending Innovate 2011 ? Interested in mobile development ? If yes, then the following sessions might be of interest to you.

Mon, Jun 6, 2011
4:15 PM : ALM-1602A Bringing Collaborative Lifecycle Development to Mobile Software
8:00 PM : BOF-2303A How is the Need for Developing Mobile Applications Changing Development Efforts

Tue, Jun 7, 2011
1:45 PM : CS-1359B Agile Adoption for Android Mobile Project using IBM Rational Team Concert - Samsung SDS Agile Transition

Wed, Jun 8, 2011
11:15 AM : SE-2206A Mobile Application Development: Strategies for Accelerated Delivery and Deployment
1:45 PM : MAC-1756A Web 2.0 and Mobile Development Fast and Easy with IBM Rational Application Developer 8.0
3:00 PM : PPM-1300A Importance of Understanding User Needs in Mobile Development
3:00 PM : SIS-1609A Model-Driven Development for Mobile Applications

In addition there are also some demo pedestals in the Solution Center. 

Eclipse Day India 2011

Anshu Jain started of the day with an excellent talk Eclipse - A Framework of Frameworks. In his talk he went through the design of a very simple calculator framework to explain all the things that Eclipse does - extensions, dynamic loading, plugin discovery etc. There was also a .cff file (calculator framework format) equivalent to plugin.xml in Eclipse. The example code from his talk is available at his site - highly recommended for someone starting of with plug-in development.

Ankur followed up with another great talk Good Practices for Plug-in Developers.  Some of the images he used to drive his point home were really funny and awesome. I thought my session JDT Bootcamp (JDT Tips and Tricks, and Extending JDT) went well, of course the fact that Satyam did a fantastic job of explaining the Java Model and the Search APIs helped a great deal.

There was a lot of interest in What's new in Java 7 talk by Ayush (the guy with the funny pose in the above pic), which was nice to see. After this Praveen talked about his experience at Adobe with migrating a Eclipse 3.x application to Eclipse 4.x platform. It was nice to hear that Adobe wants to stay on the latest Eclipse platform and has made considerable progress in this regard.

The day ended with an interesting talk about Eclipse UOMo project. Werner Keil gave a few funny examples on what can go wrong if the proper care is not taken in consistently interpreting the units, for e.g. if one team uses inches and feet and the another team interprets the values as meters and centimeters. The image of an upside down NASA shuttle because someone messed up the measurement units will always stay in my mind :)

Lastly a big thank you to SAP Laps for hosting the event! You have been a great host for Eclipse Day India 2011 and the demo camp in Nov 2010. However I would like to see the next Eclipse event in Bangalore hosted at a different venue - just for variety :) Maybe other organizations can step forward. 

I almost forgot, the 'discussion' over drinks in the evening with fellow Eclipse committers and Eclipse users was 'entertaining' ;-) Those who could not join us for drinks, please do next time.

Eclipse JDT and Java 7

Will Eclipse 3.7 include support for Java 7?
Short answer: No
Slightly longer answer: "Due to late availability of JSR-292 (Invoke Dynamic) and JSR-334 (Project Coin) and due to the official release date (July 28, 2011) of Java 7 being after 3.7 ships we had to defer the Java 7 support to 3.7.1. It has not yet been decided whether this will be available as part of the 3.7.1 downloads or as separate feature update.

The work for the Java 7 features is currently in progress in the 'BETA_JAVA7' branch and we will deliver separate updates for the stable builds in order to provide early access to the Java 7 features for interested parties."
See bug 288548.

What is the current status of support for Java 7 in JDT ?
Take a look at the wiki page: http://wiki.eclipse.org/JDT_Core/Java7

I want to try some of the new features of Java 7 in Eclipse
At this point in time you will need to

• Create a new CVS repository location to:
• :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
• Check out the following projects from BETA_JAVA7 branch:
• org.eclipse.jdt.core
• org.eclipse.jdt.ui
• Launch another eclipse application from this workspace or export the two plugins into the host eclipse.
• Of course you will also need to install a JDK7 build as an installed JRE.

Debugging Eclipse builders

Do you think Eclipse builds too often ? Do you think Eclipse build too much ? At least I do, or maybe I just got tired of seeing 'Building workspace: (12%)' in the status bar. Anyway I decided to see for myself what the heck the builders were doing.

I use JDT and PDE which means there are two builders of interest

• Java Builder
• API Analysis Builder

There are also Plug-in Manifest Builder and Extension Point Schema Builder, but I think these two do not do much and hence do not take much time.

To know what these two builders are doing in your running Eclipse instance two things are required

• Start Eclipse with -debug option, to me more precise I used the following to redirect the debug output to a file as the debug output can grow large very soon and overflow the console buffer
•  eclipsec –debug > log.txt

• Enable debug options for three plug-ins (details below)
• org.eclipse.core.resources
• org.eclipse.jdt.core
• org.eclipse.pde.api.tools

All three plug-ins ship a .options file containing all the debug options provided by these plug-ins, just open the the corresponding jars in your eclipse installation to get the .options files. Create a single .options file from these and place it in the same directory as eclipsec.exe before starting eclipse.

I had the following options set to true in my .options file
###################################################################
# Turn on debug tracing for org.eclipse.jdt.core plugin
org.eclipse.jdt.core/debug=true

# Reports java  builder activity : nature of build, built state reading, indictment process
org.eclipse.jdt.core/debug/builder=true

# Reports java builder stats
org.eclipse.jdt.core/debug/builder/stats=true

###################################################################
# Debugging options for the org.eclipse.core.resources plugin.

# Turn on debugging for the org.eclipse.core.resources plugin.
org.eclipse.core.resources/debug=true

# Reports the start and end of all builder invocations
org.eclipse.core.resources/build/invoking=true

# Reports the start and end of build delta calculations
org.eclipse.core.resources/build/delta=true

# For incremental builds, displays which builder is being run
# and because of changes in which project.
org.eclipse.core.resources/build/needbuild=true

# Prints a stack trace every time an operation finishes that requires a build
org.eclipse.core.resources/build/needbuildstack=true

###################################################################
# Turn on debug tracing for org.eclipse.pde.api.tools plugin
org.eclipse.pde.api.tools/debug=true

# Reports incremental builder activity : nature of build, indictment process,...
org.eclipse.pde.api.tools/debug/builder=true

# Print notified compatibility deltas
org.eclipse.pde.api.tools/debug/delta=true

# for the tag scanner
org.eclipse.pde.api.tools/debug/tagscanner=true

# for API profile
org.eclipse.pde.api.tools/debug/apiprofile=true

#for api analyzer
org.eclipse.pde.api.tools/debug/apianalyzer=true

#for our workspace delta processor
org.eclipse.pde.api.tools/debug/workspacedeltaprocessor=true
###################################################################

So far I have found a few scenarios where the builders could do less work - Bug 344090, Bug 344110, Bug 344163, Bug 344137. I think there are more issues, but getting a reproducible test case is proving to be a little hard in some cases.

JDT at Eclipse Day India

Satyam and I will be speaking at Eclipse Day India 2011 in Bangalore next week. We have one session JDT Bootcamp. This session consists of two parts. 

JDT - Tips and Tricks (30 min) - In the first 30 mins we will show off useful tips and tricks when working with JDT and Eclipse in general such as tricks in content assist, Java Editor tips, code navigation and debugging aids. 

Extending JDT (60 min) - In the next one hour, we will take you through APIs and extension points that JDT exposes to enable you to extend and customize the Java tooling. Using these APIs, one could create their own cleaunps, refactorings, quick fixes and other utilities.

You may also be interested in Ayush's talk What's new in Java 7 (30 min). This talk intends to describe new features of Java 7 such as switch on strings, binary integral literals and underscores in numeric literals, multi-catch and precise rethrow, diamond, try with resources, etc. The talk will also be interesting to those who want to know the status of Java 7 work in Eclipse compiler.

The three of us will be around the whole day, and would love to answer any questions or get into interesting discussions around JDT :)

See you at Eclipse Day!

Evaluating expressions in JDT Debugger

You can use the Display View to type in an expression and evaluate it in the context of the current stack frame. (The name Display is not great - see bug 342144).

- Use content assist to type expressions

- Select the expression and use Ctrl+Shift+I (Inspect) to show the result in a pop-up. You can also invoke the Inspect command from the context menu.

- Press Ctrl+Shift+I again to persist the result in the Expressions view.

See also Eclipse help.

JDT at EclipseCon 2011

Raksha Vasisht and I will be speaking at EclipseCon 2011 in Santa Clara. We have the following 2 talks

What's new in JDT
Monday, March 21 14:00 - 14:20, Stevens Creek

JDT - Tips and Tricks
Tuesday, March 22 14:00 - 14:20, Stevens Creek

We are also organizing a Bof
Eclipse - Tips and Tricks
Wednesday, March 23 19:30, Sonoma

See you soon at EclipseCon !

JDT 3.7 M5 - New and Noteworthy

This time there are a bunch of interesting items in the debug area

There is now a history for recently used breakpoint conditions:

The global history shows the saved conditions across all conditional breakpoints, while the local history shows the history of one particular breakpoint.

In the Java editor, if you delete a breakpoint that has a condition set on it, you will now be prompted before the breakpoint gets deleted:

You can specify that you would not like to be notified again when trying to remove a conditional breakpoint. This can later be changed again via Prompt for confirmation when deleting a conditional breakpoint from editor on the Java > Debug preference page.


If you accidentally removed a breakpoint from the editor's vertical ruler or the Breakpoints view, you can now get it back using the standard undo functionality - Edit > Undo Delete Breakpoint (Ctrl+Z) - in the Breakpoints view or any other view that works against the global undo history.


The Add missing case statements quick assist is now available in the body of the switch statement:

The Quick Outline shows inherited members of top-level types when Ctrl+O is pressed twice. Now, it also shows inherited members of the type that contains the current editor selection:

The focus types that can show inherited members are marked with a triangle.


Two new compiler options have been added that mark methods which can be made static because they only refer to static members.

The first option marks private and final methods than can always be made static. The second option also marks other methods. Note that methods can be overridden in a subclass, so if you make a "potentially static" method static, this may break existing clients. These options are disabled by default.

Another interesting feature in the SDK is detached editors. This can be really useful in a dual monitor setup.

 Though while trying this out I 'lost' a couple of editors before filing Bug 336391