Friday, December 12, 2014

Oomph 1.0.0 is Available

I'm very happy and a little proud to announce the very first release of Eclipse Oomph. The new installers are now available for your platform:

You can also install Oomph into an existing IDE via the update site or the site archive. Our help center is still work in progress but you may already find answers to your questions there. Our wiki may provide additional information.

This 1.0.0 release includes:

I'd like to thank our committers, especially my friend Ed Merks, our contributors and early users for their great contributions, valuable feedback, and concise bug reports. Working with you has been and will continue to be an absolutely pleasant and rewarding experience for me.

Tuesday, December 9, 2014

When You Change a Method Return Type...

... strange effects can result under certain circumstances! Recently some Oomph users reported mysterious NoSuchMethodErrors at runtime and I spent quite some time to hunt down the problem. What I found is kind of scary. Consider the following, simple program:

  public class Util
  {
    public static void run()
    {
      // Run it...
    }
  }

  public class Main
  {
    public static void main(String[] args)
    {
      Util.run();
    }
  }

The bytecode of the compiled main() method is as simple as:

  invokestatic Util/run()V
  return

Notice the uppercase "V" at the end of the run() method call. It indicates that the return type of the called run() method is "void" and is part of the bytecode of the caller! Now change the declaration of the called run() method to return a boolean value:

  public class Util
  {
    public static boolean run()
    {
      // Run it...
      return true;
    }
  }

  public class Main
  {
    public static void main(String[] args)
    {
      Util.run();
    }
  }

Recompile both classes and look at the bytecode of the main() method again:

  invokestatic Util/run()Z
  pop
  return

Notice that the bytecode has changed even though the source code of the Main class has not changed the least bit. The old run() method with no return type would not be considered a valid call target anymore!

Interesting, but when can this become a real problem?

Well, in our case the calling and the called method are in different OSGi plugins and we use Maven/Tycho to build them and our Oomph users use p2 to install or update them. The following steps turned out to be tragic:

  • I changed the return type of the called method from void to boolean.
  • Maven/Tycho has built both the calling and the called plugin.
    • The called plugin got a new version (build qualifier) because it was really changed.
    • The calling plugin did not get a different version because its source code wasn't changed.
  • A user updated his Oomph installation to the new build.
    • The called plugin was updated because a new version was found.
    • The calling plugin was not updated because there was no new version available. To be clear, there was a plugin with different content in the new build, but it had the same version as in the previous build.
As a result this user was faced with an evil exception at runtime:

  java.lang.NoSuchMethodError: Util.run()V

Now that I know why this happened I can easily fix the nasty problem by applying a fake change to the calling plugin's source code to cause Tycho to assign a new version number to it; one that is consistent with the bytecode of the called plugin.

The fact that this can happen so easily leaves me kind of scared. After all, I'll probably never ever try to change a method return type again.

Monday, November 3, 2014

Better Late Than Never

I wanted to remind you about the Call for Papers for the EclipseCon North America 2015 earlier, but the EclipseCon Europe, which just ended, has kept me too busy.


For San Francisco in March 2015 I hope that we can put together an interesting and funny program, too. And we need your help to make that possible. There are still two weeks left to submit your proposal.

If you submit now your proposal has the chance to be among the early bird picks!

Wednesday, June 26, 2013

CDO 4.2 is Available

The CDO Model Repository 4.2 release is now available, aligning with the Eclipse Kepler Simultaneous Release. CDO is featured in the Eclipse Modeling package.

CDO 4.2 was officially released on June 26th, 2013. Thanks to everyone who helped to make this release the best CDO ever!

Wednesday, May 15, 2013

Thank You Google!


Yesterday I asked you to vote for the JRE that you're using in production to get an impression whether we need to keep support for Java 1.5. The participation was very good, there were 45 votes in the first two hours. The majority of the voters is using Java 1.7, a second majority is using Java 1.6, almost noone is using Java 1.5, noone is using Java 1.4 or 1.8.

Then, all of a sudden, I realized a decrease in total votes. First they dropped down to 19, now they're at 10. The problem of disappearing votes is known for almost a year. Thank you Google, a warning note on the poll gadget would have been nice!

Here's a replacement that hopefully works better:

What JRE Are You Using?
  

Tuesday, May 14, 2013

Still Using Java 1.5?

Traditionally most Eclipse plugins declare a Java 1.5 compatibility in their bundle manifests:

Bundle-RequiredExecutionEnvironment: J2SE-1.5

And so does CDO. Now it seems that newer versions of some JDBC drivers (e.g. HSQLDB) start to depend on Java 1.6 and, unfortunately, the JDBC API of Java 1.6 is not compatible with its 1.5 pendant.

We're currently discussing how to deal with this problem and we're very interested in your opinion. Please participate in this small poll to give us an impression on whether Java 1.5 support is still needed:

What JRE Are You Using?
  

Saturday, May 4, 2013

Copyright Headers from the Git History

The other day Vincent Zurczak has blogged about Updating Copyright Mentions with Eclipse and his way of maintaining legal headers in software artifacts is very similar to what we've always done in CDO. We had the exact same header in all artifacts and we used search and replace once per year to update them all. For us that has several disadvantages:
  1. Most importantly that means to modify files that have no other (real) changes in that year.
  2. It was hard to find the files with missing legal headers.
  3. It was hard (well, mostly because I wasn't smart enough) to have different copyright owners.
What I always envisioned was a tool that identifies files that could or should have legal headers, consults the Git history for these files and assembles a copyright line as follows:

Copyright (c) 2008, 2009, 2011-2013 Owner and others.

Yesterday I've finally finished this tool:



A simple Check Copyrights for missing copyrights ends with:

Copyrights missing: 0
Copyrights rewritten: 0
Files visited: 22722
Time needed: 5.73 seconds

If there are copyrights missing the tool produces a list of the paths and can optionally open them in editors. The Update Copyrights action takes approx. 35 minutes on the same working tree and results in files with beautiful legal headers that are totally in line with the Git history.

If you are interested in the code have a look at UpdateCopyrightsAction.java. There are just a few places that are CDO-specific and I would be happy to review your patches to make the tool more flexible.