The Java 1.5 installation is actually a symbolic link to the Java 1.6 installation. There is a fix available, which essentially entails copying the Java 1.5 installation from a Leopard install, and fixing up the symlinks. It’s available here.

I found this because we have a product which must be linked against Java 1.5, or rather, the JDBC version 3 specification. We don’t yet support all the extended functionality of JDBC 4.

In Eclipse, I had selected Java 5 (= JDBC 3) as the JRE, but was still getting lots of “method unimplemented” errors for JDBC 4 (= Java 6) signatures. These aren’t present in Java 5, so they should not have appeared.

After unfolding the JRE Library node in the Eclipse Package Explorer, it was clear that, although the JRE was reporting itself as Java 5, the jars within were clearly coming from Java 6.

I applied the fix and the compiler errors disappeared – Java 5/JDBC 3 was in use again.

For (my) future reference, here are the JDK / JDBC versions:

• JDK 1.1 → JDBC 1.2
• JDK 1.2 → JDBC 2.1
• JDK 1.4 → JDBC 3
• JDK 1.5 → JDBC 3
• JDK 1.6 → JDBC 4

• Eclipse Visual Studio Presentation – changes the presentation of Eclipse to require rather less height and width and a lot more besides
• Eclipse FullScreen Plugin – adds a context menu and keyboard shortcut (CTRL-ALT-Z) to full-screen Eclipse (covering any menu/taskbars).

Also to consider:

• Is your editor font too big? Can you make it smaller and still be comfortable working with it?
• Look at your window layout – do you have a view docked to the right of the editor – probably Outline? Do you really ever use outline?  Get rid of it if not, or make it a tab in the dock on the left.

Type mismatch: cannot convert from Object to ILocationService.

when it should really have read something like:

Type mismatch: return type of TypeLoader is generic – this project is not.

Here’s what happened to trigger this error.

The type TypeLoader contains a generic method with the following signature:

    public static <T> T loadType( String name, Class<T> forType ) throws TypeLoaderException

My call – which was not in a generic project – looks like this:

        ILocationService ls = TypeLoader.loadType( locationServiceClass, ILocationService.class );

Eclipse’s exception – Cannot convert from Object to ILocationService – is a bit misleading, since there is no cast there: the generic type parameter is defined by ILocationService.class which is of type Class<ILocationService>, and in fact the TypeLoader passes all its JUnit tests.

The solution was that I’d upated the master POM for the project containing the call, but not updated the project in Eclipse (using m2eclipse’s menu Maven > Update Project Configuration. Once I’d done this, m2eclipse updated the source version from 1.4 to 1.6 – and the exception went away.

The general workaround of using OS X defaulting to change that didn’t work with previous versions of Eclipse because the SWT (IBM’s excellent widget set) was built on Carbon, OS X’s “UI Compatibility Library”, which ignored the default.  Eclipse is now available for Mac in a native Cocoa version, which does take the defaulting into account.

Here’s how to change the global OS X tooltip delay (in Terminal):

defaults write -g NSInitialToolTipDelay -int 100

I personally want to keep the 2-second delay for everything except Eclipse, so I applied the default just to Eclipse using the Eclipse bundle name:

defaults write org.eclipse.eclipse NSInitialToolTipDelay -int 100

The delay time is in milliseconds. You might have to log out and back in again to make the default take, but usually restarting Eclipse does the trick.

Nice work IBM!

Eclipse is one of those pieces of software which is rather difficult to explain accurately:  it’s a platform for building GUI applications, it’s written in Java.  It provides lots of services to make writing applications easier.  It’s a pretty good choice for building cross-platform GUI apps.  If you are a Java programmer, chances are that you either work inside Eclipse’s Java Development Tools (JDT) plugins or you’ve at least evaluated the platform.

One of our products runs as a plugin within Eclipse, and overall we’re very happy with the platform.  Lately, though, we’ve been through a refactoring process to split out the core of our product and some of the dependencies.  Coupled with some other fixes, we’ve managed to obtain quite a significant speed increase in how our backend works.

When we came to stress-test the application in order to check it performed under load, we found that instead of an overall increase in speed, we were seeing quite a significant decrease.

To explain this we had to look at the Eclipse job system.  Internally, the Eclipse platform schedules events from the UI (button presses, pending window updates etc.) as jobs.  Corresponding updates to UI elements are also scheduled in the same way.  When a worker thread becomes free, the job manager selects a suitable job (based on priority) and allows it to run.  Ordinarily there are a handfull of jobs in the job queue and they are cleared quickly, and the UI remains responsive.

Our refactoring had produced such a large increase in speed, that the resulting update jobs were flooding the job manager.  After a two-minute stress test, it would take the platform somewhere in the region of 20 seconds (depending on the CPU cycles available) to clear the job queue and return to a responsive state.

We added debugging to show us the size of the job queue, and figures upwards of 3,000 pending jobs were not uncommon.  A single (non-stress) command event telling our backend to do something would generate around 9 internal Eclipse update jobs to update various parts of the UI.  With a suitably high injection speed (which the new code was handling fine), the number of corresponding UI update jobs quickly went through the roof.

The solution, in the end, was uncomplicated:  we throttled the incoming command events (by abandoning some) if the job queue started to get too large. With a suitable throttle value, the backend could be kept busy (but not too busy) without overloading the job manager.

Kudos to my teammate Peter Bailey for doing excellent work on this problem.

I’m guessing this is because:

• behind the scenes, the new P2 provisioner system (introduced with Ganymede) has located the update and appropriate mirror, but that mirror has not yet received the build products, or
• one or more plugins has added its own ‘associate’ update/discovery sites to the list, which is no longer an update site, or is corrupt, or has gone away completely

This is incredibly frustrating for those of us trying to keep their tools up to date.

Solved

Download, unpack and start the same Eclipse distribution you originally had (J2EE in my case).  Don’t start it on your live engineering workspace.

In Software Updates -> Available Software -> Manage Sites, export the sites which are pre-installed there.

In your non-updating Eclipse, in Manage Sites, select all and Remove. Then import the sites from the other installation.  That should get it updating again.

Caveat

You’re going to have to find the update sites for your extra plugins and add them in to Manage Sites yourself.  This is, in my opinion, a small price to pay to get the updater back.

Doing Updates

Here’s a small trick.  When doing updates in Eclipse, make sure the Progress view is visible (Window -> Show View -> Progress) somewhere not covered by the Software Updates and Add-ons window and the inevitable modal Progress Information window.  If you do that, you can see a progress bar and not the tiny notification in the bottom right of the Eclipse window.

A programmer realised he had a problem which could be solved using threads.
Now he has two problems.

This isn’t going to be an anti-thread post, but I do want to sound a few words of caution about threads, and, specifically, synchronizers and monitors, and the order in which you acquire them.

Threads are a solution to a number of problems.    Java threads are easy to use and (since we got rid of ‘green’ threads and got real ones instead) become real O/S threads, mapping onto available processor cores as required.  This means that any tasks which can be parallelised, where speed of completion is important, or jobs which exhibit properties allowing the job space to be split and processed/merged separately, are prime targets for threading and the inherent speedup of being farmed out to parallel cores.

This will become ever more important as processors stop becoming faster (in fact I think this point has already been reached – Intel’s Core i7′s clock speed is still only 3.20 GHz, clever pipelining notwithstanding), and start gaining massively more cores.  The more parallelization you can find in tasks, the faster your total execution.

The problem with threads is synchronizers. As engineers we try to avoid synchronizers if possible because of the inherent cost of the JVM processing them (especially inflated ‘slow’ synchronizers), but there’s no denying the mechanism is useful.

The old tenets of monitor locking still apply:

• If you can get away with not doing it and still produce correct code  – don’t do it
• Reduce the scope of the monitor acquisition as far as possible
• Obtain monitors in the same order all over the code

The last point is the one which is mostly likely to cause problems.  It’s easy to find problems if you have code which looks like this:

synchronized(a){
    synchronized(b){

.. in some other class:

synchronized(b) {
    synchronized(a) {

There we see an explicit pair of synchronizers and the out-of-order acquisition of locks in this case is a prime case for classic deadlock.

But what about this:

synchronized(a){
    synchronized(b){

.. in some other class:

synchronized(b){
    someMethodCall();
}

void someMethodCall() {
   synchronized(a) {

This case is slightly more tricky:  the locks are indeed obtained out of order, but not immediately.  In fact the acquisition of the second lock on ‘a’ might not occur in the next method; it might occur several stack frames later.  You might not find out about it unless you use a thread-analyser package (very pricey), or a ticket hits your mailbox (and deadlocks generally count as Critical/Escalated priority).

The acquisition of the second lock isn’t obvious.   The signature of the method doesn’t make it obvious;  the only way you’ll know is by looking at the code, and if there are many execution branches away from this point in the code, that is going to take an unfeasibly long time.

The javadoc for the method might make it clear in the contract for the method, but again:  if there are still many possible method calls after this one, that’s a lot of javadoc to review.

So how do we solve this problem?

Don’t obtain the locks at all.  If you don’t need them, don’t grab them.  No locking means no chance of deadlock.  The corollary of this rule is that the fewer locks you grab, the lower the chance of deadlock.

Keep the scope of locks as small as possible.  The shorter time you hold a lock for, the lower the chance of deadlock

Obtain the locks in the same order, everywhere.  In extreme cases, this might mean obtaining a lock twice.  To go back to our second example above:

synchronized(a){
    synchronized(b){

.. in some other class:

synchronized(a) {
    synchronized(b){
        someMethodCall();
}

void someMethodCall() {
   synchronized(a) {

Of course, if you could eliminate one or both synchronizers, that would be the best solution, but this one also works because Java’s locks are re-entrant:  the second acquisition in someMethodCall effectively does nothing, since the thread already holds the monitor thanks to the explicit acquisition prior to the call.  However, it does make the locking order a -> b, instead of b -> a, eliminating the deadlock.

It’s not possible in some cases to eliminate synchronizers.  Time pressures may mean the test set for adding a synchronizer is much smaller than that for removing one and therefore preferable;  you may not be able to influence the code in someMethodCall for whatever reason, etc. etc.

Being aware of the effects and dangers of synchronization when you write code should help you avoid the pitfalls.  Synchronizers are useful and sometimes necessary, but with great power comes great responsibility.

I think I heard that in a movie somewhere.