Don't Use "Duplicate" button to add a new JRE/JDK in Eclipse

You may be tempted to use the "Duplicate..." button to add a new version of a JRE/JDK in Eclipse. Save yourself some potential hassle and use the "Add..." button instead. Manually copy and paste any Default VM Arguments you may have set afterwards.

The problem with using "Duplicate" is that all of the system library links remain at the old JRE/JDK after you update the "JRE Home". This can cause very strange errors, such as the following:

ZipFile.open(String, int, long) line: not available [native method]   
JarFile(ZipFile).(File, int) line: 114     
JarFile.(File, boolean, int) line: 135  
JarFile.(String) line: 72         
URLClassPath$JarLoader.getJarFile(URL) line: 646              
URLClassPath$JarLoader.access$600(URLClassPath$JarLoader, URL) line: 540        
URLClassPath$JarLoader$1.run() line: 607             
AccessController.doPrivileged(PrivilegedExceptionAction) line: not available [native method]    
URLClassPath$JarLoader.ensureOpen() line: 599  
URLClassPath$JarLoader.(URL, URLStreamHandler, HashMap) line: 583          
URLClassPath$3.run() line: 333   
AccessController.doPrivileged(PrivilegedExceptionAction) line: not available [native method]    
URLClassPath.getLoader(URL) line: 322   
URLClassPath.getLoader(int) line: 299     
URLClassPath.getResource(String, boolean) line: 168        
URLClassLoader$1.run() line: 194    

Some coworkers did this, and it caused a lot of headaches trying to figure out what was happening. Practically half the dev team has tried it at one point and learned the painful lesson, and it is an easy mistake to make.

If you insist on using "Duplicate...", then there is an easy fix. After you've updated the JRE location, if you use the "Restore Default" button it will update your JRE library entries. It's still very easy to forget this step, which is potentially a lot more work than just copy pasting your Default VM Arguments. If you forget to copy those, diagnosing out of heap errors is a lot simpler.

Eclipse and Mockito

Mockito is great. A big part of it is the syntactic sugar, which relies on using static imports. Eclipse, by default, removes static imports when you use 'Organize Imports' (Ctrl+Shift+O). This saddened me, so I found a way to fix it. Thanks go to this post on static import content assist and the post it links on organize imports. I will repeat both instructions in here in one place.

Part 1: Tell Eclipse Not To Remove My Precious Static Imports

1. Open Preferences (Window-> Preferences)
2. Browse to Java -> Code Style -> Organize Imports
3. Change 'Number of static imports needed for .* to '1' 
4. Click Ok 

Part 2: Get Eclipse to Create the Mockito Static Import for Me

1. Open Preferences (Window -> Preferences)
2. Browse to Java -> Editor -> Content Assist -> Favorites
3. Click 'New Type...'
4. Enter org.mockito.Mockito
5. Click Ok twice. 

Now you can write unit tests with Mockito in Eclipse without issues. You can now type mock and ctrl+space and Eclipse will add the static import for you. It will also leave it alone when you Organize Imports going forward. No more trying to remember not to Ctrl+Shift+O when editing a mockito test.

Eclipse Plugins Galore

I saw  link entitled 30 Best Eclipse Plugins on dzone today and thought it merited sharing. I've been a long time Eclipse user, but most of these plugins are new to me. There's all kinds of plugins for doing web development and things, but in particular I am interested in these:

• Mouse Gesture plugin
• Eclipse SQL Explorer
• Saros - distributed pair programming in eclipse

I am particularly curious about the distributed pair programming plugin. I've always wondered what other ways there are to pair program besides sharing 1 keyboard. It seems like it could be a good productivity tool even if you're in the same office. 

I'll also list my favorite Eclipse plugins, prior to reading the above. I'm somewhat surprised none of them are on the list.

• Findbugs plugin (less useful once you have Continuous Integration that reports this, but still cool)
• EclEmma (Code coverage  highlighting in Eclipse with an Emma junit test runner)
• SwingExplorer - very sweet way to delve through swing code and familiarize yourself with the GUI code in a project

For more plugin ideas, you may want to read this StackOverflow question.

What Eclipse plugins do you use?

Hidden Eclipse Search Feature

Eclipse has some really handy search options when you right click on member variables, but for some reason they are disabled by default.

You can enable the extra options by unchecking the checkbox for:

Preferences -> Java -> Use Reduced Search Options

Here's the before (with appropriate part of right click menu cropped in each version):

And here is after:

It's incredibly useful to be able to do easy searches for read and write access on your variables, so hopefully someone out there sees this for the first time. Hats off to my boss for sharing this knowledge with the rest of us today - he has used it for a long time.

Avoid JDK 1.6.0_14 for development (missed breakpoints while debugging)

I've occasionally had some debugging pains with Eclipse recently - I've been using JDK 1.6.0_14 for a while. As it turns out, there is a bug in the JDK that causes breakpoints to be missed when debugging.

If you are using JDK 1.6.0_14 to develop, upgrade to JDK 1.6.0_16 - it was released to fix this single bug. (you also as a benefit get 1.6.0_15's security updates)

This caused me some headaches, as it didn't always miss my breakpoints in the debugger, only occasionally... I didn't realize the core problem until a coworker informed me.

Here's a link to the bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6862295

Release notes for 1.6.0_16:

http://java.sun.com/javase/6/webnotes/6u16.html

Download links to the JDK are somewhat cryptic looking, but here goes:

JDK 1.6.0_16 download

If that fails for any reason, just go to java.sun.com, click on Java SE on the right, and there should be a JDK 1.6.0_16 (non EE) link on the page.