It's been a little while since I gave an update on where the PsychoPath XPath 2.0 processor stands from a W3C Test Suite compliance point. Mukul Gandhi (note: nudge him to get his blog on Planet Eclipse since he is an Eclipse committer now) and I have been working our way steadily through the entire test suite. Here are the current results:

Tests: 8137
Failures: 988
Errors: 42

Code Coverage according to ECLEmma:

The test suite now covers about 76% of the PsychoPath. I suspect that we will be close to 80% to 85% code coverage by the time we complete the test suite. When we started we had about 30 or 40 tests that covered about 20% of the code. Unless you run the coverage analysis with a tool like ECLEmma you really do not know how much of your code is actually being executed by your tests. Trying to get to 100% coverage is not worth doing, getting to above 75% is worth doing and should be worked toward.

XPath 2.0 Castable, Durations, and Date/Times:

This has been the bane of my existance for the last several weeks. Reading the W3C specifications on when something can be cast and when something shouldn't be cast can give one a headache pretty quickly. Luckily the XPath 2.0 and XQuery 1.0 Functions Specification has this nice handy table:


The SeqCastableTest test suite covers about 648 test cases for the core specification. PschyoPath now passes all of these tests. With out the above table, trying to figure out the wording of the specification can be difficult at best, and just plain maddening at worst.

The Natives Will Byte You!

One thing that constantly was biting me was the imprecision that the Java primitive types have. PsychoPath in it's original implementation used the Integer, Double, and Float classes exclusively. The problem was that in many cases, especially during IntegerLiteral and DecimalLiteral parsing or creation, these were either too small to hold the numbers the tests wanted, or their precision was not accurate enough. A good explanation of the reason can be found in "Double Precision Numbers". Switching where need to BigInteger and BigDecimal solved many of these issues.

Dates are still another pain to deal with especially calculations. Again you start to run into a precision issue, where some numbers are stored too low. I did some experimentation and both the com.ibm.icu.util.GregorianCalendar and the built in Java GregorianCalendar have precision issues, some in the same place others not. I had thought about trying to leverage Joda Time but that was previously turned down by Eclipse IP team due to pedigree concerns.

I dread debugging these issues. Dates and Time calculations give me a headache.

What's left:

Lots. There are several core functions that are not working or are missing. Some logic expression errors to correct, and a few more lexer/parser issues to address. Overall though, PsychoPath passes about 88% of the W3C Test Suite, so is much more compliant than it started out. Credit still has to be given to Andrea Bittau, the original author, for a well designed implementation, and some very clean and easy to maintain code. Compared to some of the code I've worked on at Eclipse, this is just a pleasure to work with.

All current changes are in the WTP Source Editing CVS Repository.

My Windows/Linux world has gotten a whole lot more complicated in the last few days, but I'm really liking how it's set up now.

As I mentioned in my blog entry on multi-target Makefiles, I am using Fedora 11's mingw cross compiler along with gcc's multilib support and am building the little C++ project I'm working on at work for both 32 and 64-bit Linux as well as Windows all in the same Makefile and all on every build of my CDT project. That is extremely handy and I've already fixed a problem early where there is a mismatch between the linux and mingw environments, no strndup on mingw, and was able to do so without switching machines.

This is awesome and I'll be able to produce executables for all three of these platforms for testing all in one shot. Kudos to the Fedora folk for providing first class support for mingw cross compilation and not ignoring the fact that us developers still need to target Windows once in a while. That makes Fedora my favorite development environment by far.

But, alas, Linux drivers suck for laptops. I have a Dell and a port replicator at work and at home. I have a 24" monitor at work running at 1900 wide and a 22" monitor at home at 1680 wide. I swap between the two every day, and often work undocked at home with no external monitor. I could never get Linux to recognize when I dock and to figure out which monitor was hooked up. That drove me nuts.

A couple of things have also happened recently. I've been testing the Windows 7 RC on a separate partition and have started to really like it. As a lot of people have mentioned already, it's what Vista should have been. It doesn't quite have the flash of the Mac, but I find it's a great balance between flash and the stability of XP.

The other thing that happened was that VirtualBox 3.0 has been released and it now has OpenGL support for both Windows and Linux guests. That was one of the reasons I moved to Linux, to experiment with OpenGL there. Now I can do that in a guest OS.

So putting all that together, I've replaces OSes yet again (been doing that regularly for years it seems). I'm now running on 64-bit Windows 7 with two major VMs, one for my fabulous Fedora dev environment, and one for the corporate XP environment I used to have there for Outlook and Netmeeting. So far so good. I get the odd glitch once in a while but nothing I can't recover from and it is a release candidate. But now I have the best of all worlds. Except maybe MacOSX, and an iPhone dev environment. So close...

Java 5.0 introduced Generics. It also introduced covariant return types. Wikipedia does a fine job describing covariant return types.

Since they were released simultaneously, I consider them to be tightly coupled. For instance, here are simplified versions of an interface and implementation I recently wrote:

Note: I am having difficulty representing greater-than and less-than symbols in Blogger's editor, so you'll have to do with { and }.

Version 1: Java 5, Generics, Covariant return types

public interface Model{T extends Model{T}} {
  T read(InputStream in);
  T write(OutputStream out);
}

public class MyModel implements Model{MyModel} {
  public MyModel read(InputStream in) {
    ...
  }
  public MyModel write(OutputStream out) {
    ...
  }
  public MyModel setName(String name) {
    ...
    return this;
  }
  public String getName() { ... }
}

new MyModel()
   .read(in)
   .setName("foo")
   .setStopAtMain(false)
   ...
   .write(out);

public interface Model {
  Model read(InputStream in);
  Model write(OutputStream out);
}

class MyModel implements Model {
  public Model read(InputStream in) { ... }
  public Model write(OutputStream out) { ... }
  ...
}

public static void foo() {
  new MyModel()
      .read(in)
      .setName("foo")
      ^ The method setName(String) is undefined
        for the type Model.
      .write(out);
}

public static void foo() {
  ((MyModel) new MyModel()
      .read(in))
      .setName("foo")
      .write(out);
 }

public interface Model{T extends Model{T}} {
  T Model read(InputStream in);
  T Model write(OutputStream out);
}

public class MyModel implements Model{MyModel} {
  public MyModel read(InputStream in) {
    ...
  }
  public MyModel write(OutputStream out) {
    ...
  }
  public MyModel setName(String name) {
    ...
    return this;
  }
  public String getName() { ... }
}

A few months ago I ventured into the world of Mobile development and created an application (Hudson Helper) for both iPhone and Android. This article is about my experiences, comparing Android and iPhone development with a focus on tools, platform and the developer experience.

Before going much further I should note that my comparison is with considerable bias. I’ve spent the past 12+ years in Java development, having spent much of my career building developer tools. Since January of 2004 I’ve been building plug-ins for Eclipse, and before that plug-ins for NetBeans. This bias is somewhat tempered with several years of C and C++ development. With this background I find that I’m very critical of developer tools. Developer productivity is key — anything that takes away from the flow of a developer in the zone is a real problem.

Language, Programming Model and Platform

Language

The language of choice for iPhone development is Objective-C. Objective-C is a language based on C with extensions for object-oriented concepts, such as classes, inheritance, interfaces, messages, dynamic typing, etc. The Java language is used when developing for Android (though it doesn’t actually get compiled to bytecode).

Java is a no-brainer. I have to say that it’s nice not to have to learn a new language to target mobile. Existing skillsets don’t come easy — so reuse of expertise is worth a lot.

It took a little while to wrap my head around some of the language features available with Objective-C. I soon discovered that I really loved certain language features, such as message passing (instead of calling methods), categories and named arguments. I did find however that the syntax of Objective-C is cumbersome. I’m still not used to ‘+’ and ‘-’ for static and member methods, too many parentheses are required, and in general I just felt like I had to type way to much to express a simple concept. The IDE didn’t help much with this either (more on that later).

One thing that really became clear to me is that Objective-C, though it may have been visionary for its time, is really a language of the '80s. Certain issues such as split header and implementation files and violation of DRY are really time-wasters, and not small ones at that. I found myself constantly switching back and forth between files, which not only has a cost in navigation (which file to open?) but with every file opened your sense of context must be recreated (where’s the caret, what’s selected, where am I in the file, how is this file organized).

As far as DRY, must I really do 5 things to declare a property?? (declare in the class definition, again to declare getter/settter, initialize in the init method, @synthesize in the implementation, release in dealloc). Here’s what I mean:

Server.h

@interface Server : Updatable {
NSString *name;  <-- declare the property 
}

@property (nonatomic,retain) NSString *name; <--- declare the property again

Server.m

@synthesize name;  <-- implement getter/setter

-(void) dealloc {
[name release];  <-- release memory
}

If you ask me, everything in Server.m should go away. Another gotcha here is the positional relevance of @synthesize.

Java has a similar problem with properties, though not quite so bad — and the IDE helps you write your getter/setter.

Pointers in Objective-C, though powerful, are also another time-waster. This is where Java really shines with its garbage collection. I found that I was constantly considering whether allocated objects were freed appropriately. Code flow is poor since application logic is littered with memory management. I only have so many brain cycles available — why do I have to think about this other cruft that’s not really a core concern of the application domain? Of course this gets even worse when trying to figure out where things went wrong if you make a mistake. Zombies help, but still don’t make it obvious if you’ve accessed something that was deallocated. Other issues include deallocating something twice, autoreleasing something twice. I also found it non-intuitive when to retain return values from methods.

Another annoyance of Objective-C is the patterns that must be followed: implementing correct init and dealloc methods is non-trivial. @synthesized getters and setters for properties with retain should not be called in these methods. So many conventions and rules to remember!

Though I understand why there’s a separation of alloc and init, it’s still overly wordy to specify [[aloc Foo] initWithArg: arg]. Why not just [new Foo arg]? Or how about new Foo(arg) -- oh, wait, that’s just like Java!

Objective-C’s imports and forward-declarations (@class) are a pain. Though these issues exist with Java development, Eclipse’s JDT is so good that I’ve almost forgotten what it’s like to write an import. All you have to do is Ctrl+Space to auto-complete a class name or Ctrl+Shift+O to organize imports and voila!

Of course Java is not perfect either, however this fact is hidden from me due to the fact that I’ve been living in Java for a very long time. Sometimes I wish that Java were more Groovy-like, however I’m used to it and the tooling is so good.

Platform

On Android I found that I could readily use the Java runtime classes. Some, but not all, of the standard Java RT classes are available on Android. I didn’t find this a problem, since most of the standard Java IO, network and regex libraries are available. Android RT classes appear to be based on Harmony, which has been around long enough to be stable.

With iPhone on the other hand, finding the functionality that I needed was painful. Classes and methods are poorly organized. When to look for a static method versus a class with members was not clear to me. Also depending on the framework used, naming conventions and code organization would differ. I suppose this is the legacy of an older platform. Areas where functionality was lacking that I found painful were regular expressions, string handling and XML parsing. I ended up using the excellent Regex Kit Lite for regular expressions. For XML parsing I implemented a parser abstraction over libxml, only to discover later that I may have had an easier time with NSXMLParser which is a lot more like SAX.

On the iPhone when things didn’t work as expected I had to resort to Google and hope that others had encountered the same problem. This technique was hampered by Apple’s earlier NDA policy, which meant that iPhone content is pretty thin on the net. In some cases I would resort to guesswork and experimentation to find a solution.

Android has the benefit of being open source. Within minutes I had the full Android platform source code on my system, and had re-built the SDK from sources to ensure that the source I had matched the runtime classes in the emulator. So not only could I see how things were implemented in the Android platform and learn by example, I could step through the platform code in the emulator and discover why my code wasn’t producing the desired results.

In general I found the layout, organization, and naming conventions of Android platform classes was consistent and predictable. This made it much easier to learn.

Programming Model

The iPhone platform does a great job of encouraging an MVC design pattern. With this design pattern built in to the platform, building the UI was simple and I didn’t have to figure out how to organize the UI component design myself. It also means that when looking at sample code, it’s all organized in the same way.

Android also does a good job with design patterns, though their concepts varied significantly from the iPhone. With Android’s support for multiple processes and component reuse, the platform itself provides support for Intents and Activities (an Intent is just a variant of a command). The design results in a better user experience, however it does introduce some complexity for the developer: when starting one Activity from another, an Intent is used to communicate any parameters. These parameters cannot be passed by reference — only by value. Where on the iPhone it’s simple to have screens sharing the same data structures, on Android this requires some forethought. Apparently Android applications can manage the back button and have everything occur inside a single Activity, however this is not the norm.

Both Android and iPhone provide a way of declaring user preferences in XML. Both platforms provide a default UI for editing those preferences, which is great. Android’s XML format is extensible allowing custom UI components to be integrated, which makes user preferences a breeze. iPhone developers that wish to customize preferences will have to implement a UI from scratch, which is a lot more work.

Testing and Continuous Integration

I’m of the opinion that every development effort should include unit tests. Teams of size greater than one should also include Continuous Integration.

Android developers will be happy to know that they can write JUnit tests. I could even launch these from the Eclipse UI after some classpath fiddling. Though I didn’t try it, I assume that it’s trivial to run these from Ant and your favorite CI server such as Hudson.

I did see some iPhone unit test documentation with the iPhone SDK but didn’t take the time to explore it — so I can’t comment there.

Resources

Apple does an excellent job of providing lots of resources for developers. Important concepts are explained in videos, which makes grasping concepts easy — however I did find that videos progressed slowly and I was watching for what seemed like hours to find information that should have taken minutes. Luckily Apple also provides lots of sample applications and code to demonstrate API usage.

Android developers also have access to loads of resources. The guide and API reference are installed with the SDK, so everything is available when offline (which for me is important since I do a lot of my work in transit). I found the Android development resources better organized and spent less time looking and more time finding. In particular the ApiDemos sample app provides a great starting point. I also downloaded many open source Android projects for ideas on architecture and API usage. This is an area where Android has the advantage, with Apple’s previous NDA policy there isn’t much out there in terms of open source for iPhone.

Tooling

For me tooling was a real shocker. These are the categories of tooling that I’ll cover: IDE, UI builder, debugger, profiler. Almost everything else is related to provisioning, and in that area I didn’t notice much in the way of differences between Android and iPhone.

IDE

Android development leverages the excellent JDT tools, which are pretty much stock and standard with every Eclipse installation. I’ve used these tools now for many years and they’re excellent. Everything Java is indexed, the IDE has a rich model of the source code, and refactoring is so seamless that it has changed the way that I work.

Perhaps the best feature of JDT is its incremental compiler, which provides immediate feedback with errors and warnings as you type. This eliminates the code-compile-wait-for-feedback cycle that was so common in the '80s and '90s. Errors and warnings are updated in the Java editor as I type, giving me instant feedback. I didn’t realize just how valuable this feature is until I was coding Objective-C in XCode — when I became acutely aware at how waiting for compiler feedback can break the flow of programming.

Other key features that make Eclipse so amazing to work with are:

• content assist
• quick-fixes
• organize imports
• open type (CTRL+Shift+T)
• refactorings

Integrated javadoc and content assist is quite possibly the best way to learn an unfamiliar API. In Ecipse not only are all classes and methods immediately available in the context in which you’re writing code, their documentation is presented alongside.

Content Assist with Integrated Javadoc

XCode is so shockingly bad that I almost don’t know where to start. Here’s a minimum list of things that I think need fixing in order for XCode to become a viable IDE:

• Content assist that actually works. Content assist provided by XCode is often wrong, and almost always suggests a small subset of what’s actually available.
• A decent window/editor management system. XCode and it’s associated tools (debugger) like to open lots of windows. Want to open a file? How about a new window for you! Very quickly I found myself in open-window-hell. The operating system’s window management is designed for managing multiple applications, not multiple editors within an IDE. It’s simply not capable of providing management of editors in an environment as sophisticated as an IDE.
• A project tree view that sorts files alphabetically. Really!
• Integrated API documentation. I found that I was constantly switching out of the IDE and searching for API documentation using Appkido. This may seem trivial, but it really breaks the flow.

One area of Eclipse that simply can’t be matched is Mylyn. Integrated task management and a focused interface introduce huge efficiencies into any project, small or large. If you haven’t yet tried out Mylyn, it’s definitely worth your time to take a look. A good place to start is Mylyn’s Getting Started page.

UI Builder

iPhone app developers are given a pretty good UI builder. It does a great job of showing the UI as it will actually appear. It’s flexible and can model some pretty sophisticated UIs, so I was impressed. I found that using it was a little tricky — I had to read the documentation two or three times before I could really figure out how to use it properly.

The Android UI builder I found pretty useless: it can’t display UIs how they’ll actually appear, and it’s UI is way too inefficient. I found that I coded all of the UIs directly in the XML source view of the UI builder. There the content assist and validation were pretty good, making it the easiest way for me to build a UI.

Debugger

Having used to the Java debugger in Eclipse I was shocked at the state of the debugger in XCode. With Eclipse I can see and modify variable values. Not so in XCode. Maybe this is simply the state of affairs when debugging native code, but it sure affects the usefulness of the debugger. XCode often seemed confused as to the type of an object and presented me with a pointer value and no detail. This is a sharp contrast to Eclipse, where I can drill down through an object graph with ease.

I found the XCode debugger UI extremely difficult to use. Clicking on the stack to show code in an editor caused new windows to open, eventually resulting in dozens of windows open. In addition I found that watch expressions rarely worked for me.

Profiler and Heap Analysis

An area where Apple development tools excel is in profiling and heap analysis. These tools seemed mature and easy to use. With no prior experience with these specific tools I was able to gain a better understanding of my app within minutes, find and fix several memory leaks and improve performance.

XCode Memory Leak Detection

Android developers must use Android’s traceview application, which I found worked well but required significantly more effort to configure and operate. I was surprised to find that the source code must be changed in order to get the trace files required for analysis.

I’m not sure if Android can provide heap dumps in hprof format. If it can then the awesome MAT tool could be used to analyze heap usage. According to this article Android can produce hprof heap data, though I haven’t tried it.

App Store

It goes without saying that the iPhone app store is excellent in that you can sell into many countries worldwide with a single setup. I was able to provide my Canadian bank account number, sign a few legal agreements and I was up and running.

Getting an app into the store however is frustrating to say the least. Apple must approve every app before it is accepted into the store. Mine got rejected multiple times. Each time it was rejected I was given almost no information about why. When I emailed them to clarify the problem, I received what looked like a canned response indicating that I should refer to previous correspondence. If it weren’t so frustrating I would have found it funny. I highly recommend reading Brian Stormont’s Avoiding iPhone App Rejection from Apple and Dan Grigsby’s Part 2 follow-up.

Of course once I started selling Hudson Helper I realized that Apple won’t send me any money unless the payout is greater than $250. This is true not only of the first payout, but every payout. Google market on the other hand requires a minimum of $1 for each payout. Both the iPhone app store and Google market take about %30 of your app selling price. $0.99 applications have to have high volume, or they’re simply not worth your time.

The Google market by comparison to the Apple app store is terrible in that you can only sell into a handful of countries. You also can’t see or install apps that cost money on a developer phone. Actually you can, but not if the app has copy protection — which is almost every non-free app. On the other hand when you upload your app to the app store it’s available within minutes, so you don’t have to worry about an approval process.

To set up a merchant account with Google market, I had to provide a US address and bank account number, since Google doesn’t support Canada. For me this was a pain, but not too bad since I live within a few kilometers of the US border. I rode my bike down to the US and opened an account with Horizon bank. The bank required a passport and driver’s license, so no problem there. Why Google doesn’t support more countries I don’t know. At the very least Google market should accept alternate payment methods for countries that are not supported by Google checkout.

Summary

Android’s platform and developer tools are excellent. Leveraging Java and the Eclipse IDE are major winning factors for Android. Apple’s developer tools are shockingly bad by comparison. The Objective-C language and platform APIs are cumbersome and poorly organized. Overall when developing for the iPhone I felt like I was back in 1993. These factors combined in my estimation make application development about three times more expensive when developing for iPhone. The only area where Apple’s developer tools excelled was in profiling and heap analysis.

Apple’s app store from a user’s standpoint and from a worldwide coverage standpoint are excellent. In this area Google market for Android is weak.

Development for iPhone may improve as tools such as iphonical (MDD for iPhone) and objectiveclipse (Eclipse plug-in for Objective-C) emerge.

We may see a shake-up in the mobile market, with at least 18 new Android handsets being released this year. Until that happens, iPhone will remain a market leader and developers will have to put up with XCode and Objective-C.

For me, my love is with Android. Sure, the iPhone is great — but can you install a new Linux kernel?

As Galileo is out in the wild and we are all already working on Helios… I thought it would be handy to give a quick overview of the New and Noteworthy features the RAP team worked on for Galileo. Besides many, many bug fixes… we still found time to provide several new features. On top of the new features, we focused on making single sourcing even easier to do.

New Look and Feel

This is one of the biggest features of RAP released as part of the train. As Ian already pointed out correctly:

One of the common complaints about RAP was that it doesn’t look like a web application.

While this was true in the past, we worked really hard to provide the community a clean and easy way how to customize the whole workbench styling.

Cell Editors

It’s finally done – RAP supports cell editors in the Table. As this was a really long-standing issue we’re more than happy to have it in 1.2.

Ed, now it’s time to give the whole “generated EMF editor on RAP” idea a new spin! For anybody interested in this story, please CC yourself on this bug.

Performance & Memory

The RAP team really had a great time for this release – we just sat there and waited for the browsers to become even faster…as this was a really silly task we decided to do something:

Improvement of Session Startup Performance

First the creating of the startup page is less CPU intensive. Second the javascript library content is not embedded in the startup page anymore and will be delivered separately. As the library content doesn’t change after server start it can be zipped once and buffered. This reduces CPU usage significantly. The library is stored in the browser’s cache and need not to be reloaded on subsequent application visits.

Client-side memory improvements

Included is also a new version of the Javascript library qooxdoo. Thanks to the great support by the RAP community, most notably from Stefan Hansel who tracked down a number of significant memory leaks in qooxdoo and provided patches to the qooxdoo developers, this version now brings a major improvement in client memory consumption. With this qooxdoo version, the long-standing memory leakage problems of RAP especially in Internet Explorer are resolved. Thanks to everyone who helped making this possible!

New API & Widgets

With the idea of single sourcing in mind we concentrated on adding new API to allow even more reuse of existing SWT/RCP code. Besides many small things like Display#timerExec() we also tried to complete the set of widgets. With 8 (yes, eight) new widgets in this release, these two are my personal favorites and often requested by the community.

DateTime

FormText (Forms)

Cursor Support

Summary

In case you’re not yet sure how “single sourcing” works – Ralf and Rüdiger would be happy to explain it to you step-by-step in their upcoming webinar.

In summary, we’re quite happy with the current 1.2 release but are already looking forward to the Helios release train.

If you have anything you want to see in 1.3, don’t hesitate and drop us a note.

This blog updates the roadmap for jetty-6, jetty-7 and jetty-8 with the latest plans resulting from the move to the Eclipse Foundation and the delay in the servlet-3.0 specification. Previously it was intended that jetty-7 was going to be servlet-3.0, but with the move to eclipse and with the delay of JSR-315, it was decided to delay servlet 3.0 to Jetty-8 later in this year.  Thus the current active branches of jetty are:

Jetty-6 @ codehaus & mortbay

The current stable branch is jetty-6 for servlet-2.5 and java-1.4 (some modules are 1.5).  It is in the org.mortbay.* package space and is licensed under the apache 2.0 license.   However, it is now mostly in maintenance mode and new features will not be added to jetty-6 unless there is compelling reasons to do so.  It includes support for both HTTP server and client and comes bundled with a cometd server.

Jetty-6 is the release for established, production-ready projects.

Jetty-7 @ eclipse

The current development branch is jetty-7 for servlet-2.5 and java-1.5.  It is in the org.eclipse.jetty.* package space and is licensed under both the apache 2.0 and eclipse 1.0 licenses and may be distributed under the terms of either license.  Jetty-7 represents a moderate refactor of the jetty code base:

The intent of jetty-7 is to allow users to transition to the updated architecture and to access some servlet-3.0 features, within a servlet 2.5 container and without the need to update java 1.6 or to wait for the final specification later this year.  There are milestone builds of jetty-7 available already and we hope to have an official eclipse release in the next month or two. 

The cometd client and server are now in the cometd.org project and are built against jetty-7. Some jetty integrations (eg jetty-maven-plugin, terracotta, wadi, etc) and distributions (eg. deb, rpm, hightide) will remain at codehaus and are now built from codehaus trunk.

Jetty-7 is the release for projects starting development now.

Jetty-8 @ eclipse

The current experimental branch is jetty-8 for servlet-3.0 and java-1.6. It is in the org.eclipse.jetty.* package space and is licensed under both the apache 2.0 and eclipse 1.0 licenses and may be distributed under the terms of either license. Jetty-8 is being kept in lock-step with jetty-7 as much as possible, so that it represents essentially the same server, but rebuilt with java-1.6 and using the standard servlet-3.0 to access the features already available in jetty-7.

Jetty-8 is the branch for people who wish to experiment with the emerging APIs now.

Webtide @ JavaOne

If you want more information about what exactly are these jetty and servlet-3.0 features, why not come to JavaOne 2009?! Webtide will be have a small booth in the expo (where you will mostly find me) and Sun have invited me to participate in their technical session on Servlet 3.0 at JavaOne, together with Rajiv Mordani and Jan Leuhe.  I'll be presenting a section on the Asynchronous Servlets API and giving a demonstration that uses some ease-of-deployment features to deploy a webapp on glassfish using the Jetty asynchronous HTTP client  in a 3.0 asynchronous servlet. The session is TS-3790 "Java™ Servlet 3.0: Empowering Your Web Applications With Async, Extensibility and More" and is scheduled for Tuesday June 02 12:10 PM - 1:10 PM in E134

The announcement of Google Wave is a bold declaration of where Google sees the future of the web. Google, unsurprisingly enough, sees the future of the web as a server side paradigm, with dynamic updates being used to drive the thin client model to capture even more of tasks that where once done client side.  Google are extending the server side model of webmail to apply to applications that have been fundamentally client side, such as document authoring, IM and chat.

Some have said that Wave's use of XMPP represents the death of HTTP, but I think they've got the wrong end of the banana! Wave is using XMPP to federate servers together, not clients.  When it comes to client/server communications, Wave is using GWT over good old HTTP, with some push extensions so that a client can get a dynamic view onto a Wave document, which is a fundamentally server side entity.  If anything, Wave has declared that HTTP is king and a near immortal one at that.

Google's use of XMPP is roughly equivalent to the existing use of SMTP between mail servers. Instead of passing mail documents between servers using a store and forward model, Wave has the servers dynamically collaborating to maintain a live Wave document that contains content, style, history, permissions and private content. The protocols that Wave might put on the endangered species list are SMTP, POP and IMAP (but have any protocols gone extinct? Has a gopher been sighted in the wild recently or only in captivity?).

If Wave is successful (and it certainly looks pretty compelling), then more traditionally client side state is going to be captured on the server side.  This is a great model for google, as it lets them use their massive serverside databases to power their serverside robots like spelly and rosey, which access the vast databases of Google to do contextual spell checking and translation. You will never get such robots running client side and it is services like these that makes Google confident that they can offer better wave servers than anybody else - hence they do not fear opening up their Wave servers to competition.   So Googles' webmail competitors had better start thinking of compelling reasons that people will want to host their waves on non-Google servers.

Of course for Jetty, Google Wave is just a brilliant story.  To implement a Wave server, you will need a flexible, performant web server that can well support dynamic push content and will affordably scale into your wave clouds (should they be called oceans rather than clouds now?)  Jetty is the ideal Wave server!  In fact because Wave uses GWT, Google AppEngine and links to shindig, it is already based on and/or using the Google services that are based on or use Jetty. 

For our other key project, cometd.org, the picture is a little less clear.  Google Wave does it's own comet implementation based on long polling using GWT RPC. But Wave reinforces that comet is now a core web paradigm. Any alternative implementations of Wave that do not use the google GWT code base, would do well to look to cometd.org as a core technology.

I really like the idea behind the HTML5 Websocket API - namely that a datagram model should be used for web application communication rather than a request/response paradigm (this is also the idea behind cometd).  But unfortunately, the proposed protocol to carry websocket traffic is neither a good protocol nor is it well specified.

After failing in an attempt to get the WebSocket protocol improved, I decided to try to define a better solution.  I had intended to work privately on this for a while, but the twittersphere has pointed out an early draft, so I've put the work-in-progress on http://bwtp.wikidot.com and I invite review, feedback and collaborators.

So what's so bad about the Websocket protocol proposal? The main things I dislike are that the document is impenetrable, the protocol inflexible and it is entirely different from other IETF application protocols for no good reason. But rather than throw (more)mud, I'd rather sing the praises of the approach that I have taken:

If you are interested, I encourage you to join the IETF Hybi mailing list and to join the discussion ragarding the bidirectional web.

Peter Friese spent some time with me this afternoon to help work around some of the issues I had with the EBNF grammar and Xtext. The results are very encouraging.

The above is the editor, and outline view that is generated from the XText grammar. We even have some very basic content assistance that comes with it.


The hope is to p0lish this up over the next week or so, and contribute the source to the RelaxNG Editor and Validator enhacement in WTP. A code contribution has already been attached to the bug that provides Grammar aware content assistance and validation for XML files backed by a RelaxNG grammar. Hopefully we can get this project quickly into the WTP Incubator so that RelaxNG support can be added by Helios in some form.

Thanks again for the help Peter.

Today I gave a talk on building dynamic applications with OSGi at the Java-Forum-Stuttgart 2009. This was mostly the talk I gave (and prepared) together with Kai Tödter and Gerd Wütherich for previous conferences. Here are the slides:

• Patterns and Best Practices for Dynamic OSGi Applications (pdf)

So, I decided to try and create an XText Grammar for the RelaxNG Compact Syntax. Mixed results so far, mainly having to do with my lack of knowledge on the XText grammar and it's mapping to EBNF.

Here is what I have so far:

grammar org.oasisopen.relaxng with org.eclipse.xtext.common.Terminals

generate relaxng "http://www.oasis-open.org/relaxng"

terminal Letter:
   ID;

terminal CHAR:
   '#x9' | '#xA' | '#xD' | ('#x20'..'#xD7FF') | ('#xE000'..'#xFFFD') | ('#x10000'..'#x10FFFF');  

terminal NewLine:
   '#xA' | '#xD' | ('#xA' '#xD');
 
terminal NameStartChar:
   ":" |
   ('A'..'Z') |
   "_" | 
   ('a'..'z') |
   ('#xC0'..'#xD6') | 
   ('#xD8'..'#xF6') | 
   ('#xF8'..'#x2FF') | 
   ('#x370'..'#x37D') | 
   ('#x37F'..'#x1FFF') | 
   ('#x200C'..'#x200D') |
   ('#x2070'..'#x218F') | 
   ('#x2C00'..'#x2FEF') |
   ('#x3001'..'#xD7FF') |
   ('#xF900'..'#xFDCF') |
   ('[#xFDF0'..'-#xFFFD') |
   ('#x10000'..'#xEFFFF');

terminal NameChar:
   NameStartChar | "-" | "." | ('0'..'9') | '#xB7' | ('#x0300'..'#x036F') | ('#x203F'..'#x2040');

Model :
   (elements += TopLevel);

TopLevel:
   Decl* (Pattern | GrammarContent*);
    
Decl:
   'namespace' (IdentifierOrKeyWord '=' NamespaceURILiteral) |
   'default' 'namespace' (IdentifierOrKeyWord) '=' NamespaceURILiteral |
   'datatypes' IdentifierOrKeyWord '=' Literal;

Pattern:
   'element' NameClass '{' Pattern '}' |
   'attribute' NameClass '{' Pattern '}' |
   Pattern (',' Pattern)+ |
   Pattern ('&' Pattern)+ |
   Pattern ('|' Pattern)+ |
   Pattern '?' |
   Pattern '*' |
   Pattern '+' |
   'list' '{' Pattern '}' |
   'mixed' '{' Pattern '}' |
   Identifier |
   'parent' Identifier |
   'empty' |
   'text' |
   (DataTypeName) DataTypeValue |
   DataTypeName ('{' Param* '}') (ExceptPattern) |
   'notAllowed' |
   'external' AnyURILiteral (Inherit) |
   'grammar' '{' GrammarContent* '}' |
   '(' Pattern ')';
   
Param:
   IdentifierOrKeyWord '=' Literal;

ExceptPattern:
   '-' Pattern;

GrammarContent:
   Start | Define |
   'div' '{' GrammarContent* '}' |
   'include' AnyURILiteral (Inherit) ('{' IncludeContent* '}');

IncludeContent:
   Define | Start |
   'div' '{' GrammarContent* '}';

Start:
   'start' AssignedMethod Pattern;

Define:
   Identifier AssignedMethod Pattern;

AssignMethod:
   '=' |
   '|=' |
   '&=';

NameClass:
   Name |
   NsName (ExceptClassName) |
   AnyName (ExceptClassName) |
   NameClass '|' NameClass |
   '(' NameClass ')';

Name:
   IdentiferOrKeyWord | CName;

ExceptNameClass:
   '-' NameClass;

DataTypeName:
   CName |
   'string' |
   'token';

DataTypeValue:
   Literal;

AnyURILiteral:
   Literal;

NamespaceURILiteral:
   Literal | 'inherit';

Inherit:
   'inherit' '=' IdentifierOrKeyWord;

IdentifierOrKeyWord:
   Identifier | KeyWord;


Identifier:
   (NCName .. KeyWord) |
   QuotedIdentifier;


CName:
   NCName ':' NCName;

NsName:
   NCName ':*';

AnyName:
   '*';

Literal:
   LiteralSegment ('~' LiteralSegment)+;

LiteralSegment:
   '"' (CHAR .. ('"' | NewLine))* '"' |
   "'" (CHAR .. ("'" | Newline))* "'" |
   '"""' (('"') ('"') (CHAR .. '"'))* '"""';

KeyWord:
   "attribute"
   | "default"
   | "datatypes"
   | "div"
   | "element"
   | "empty"
   | "external"
   | "grammar"
   | "include"
   | "inherit"
   | "list"
   | "mixed"
   | "namespace"
   | "notAllowed"
   | "parent"
   | "start"
   | "string"
   | "text"
   | "token";

NCName:
   NCNameStartChar NCNameChar*; /* An XML Name, minus the ":" */
    
NCNameChar:
   NameChar - ':';
    
NCNameStartChar:
   Letter | '_';
    
Name:
   NameStartChar (NameChar)*;
    
Names:
   Name ('#x20' Name)*;
    
Nmtoken:
   (NameChar)+;
    
Nmtokens:
   Nmtoken ('#x20' Nmtoken)*;

QuotedIdentifier:
    '\' NCName;

This is a post about scoping and how to use the EMF index for that. It is in some sense a practical follow up on another blog post about the general idea behind indexing and scoping in Xtext. The topic is somewhat advanced and bleeding edge. This post describes the needed steps to get the current index based default scoping up and running. I've prepared a small screencast demonstrating the result in action. The example language can be downloaded from here.




Today, the common way to do cross resource references in Xtext is to do it via resource URIs. That is if you want to reference a model element (EObject) from another resource, you typically put the whole resource on the scope by adding a corresponding import. Example:

import "platform:/resource/my.project/src/othermodel.dsl"

//.. refer to elements from othermodel.dsl

<extension point="org.eclipse.emf.index.indexer">
<indexer class="org.eclipse.xtext.example.DomainmodelExecutableExtensionFactory
                  :org.eclipse.xtext.index.DefaultDeclarativeResourceIndexer"
            fileextensions="dmodel"/>
</extension>

String qualifiedName(MyType foo) {
  // compute different qualified name for MyTypes
  // ...
}

public IndexStore bindIndexStore() {
 return EmfIndexUIPlugin.getDefault().getIndexStore();
}

@Inject
private IndexStore store;

public IndexStore bindIndexStore() {
 return new PersistableIndexStore();
}
  
@Override
public Class bindIScopeProvider() {
 return DefaultIndexBasedScopeProvider.class;
}

import java.util.Set;

package foo {
  import bar.Foo
  entity Bar extends Foo {
  }
}

package bar {
  entity Foo {}
}

package bar {
  entity Bar extends Foo {}
  entity Foo {}
}

package bar {
  entity Bar extends bar.Foo {}
  entity Foo {}
}

I like portable software. I carry around a bunch of them in my flash drive. I just found out that both Java and Eclipse are available as portable versions at PortableApps.com. The Java version they have is Java 6 update 14 but Eclipse is stuck at 3.4.2.

Eclipse uses portable Java, so Java need not be installed in the PC to run it. Nice. The portable version has some trouble finding the workspace but once you correct the path it works fine.

I updated the Eclipse binaries in to the just released 3.5 and it work great too. Nice way to take Eclipse and your work with you.

Related posts:

1. Eclipse Tip: Keeping plugins and workspace separate
2. Eclipse Tip: Java Editor Breadcrumb Navigation Bar
3. Eclipse Tip: Sharing Java project settings
4. Eclipse Tip: Grouping Java Problems
5. Java rides on Google App Engine

My personal Berlin tour guide, Eike Stepper, and I did a Galileo Series Podcast about CDO with James Sugrue the other day.


Eike and his rapidly growing team are doing some extremely cool things with CDO, so you might be interested to find out more.

If the cave you've been living in does not have Internet service, then perhaps it will come as news to you that Galileo was successfully released last week. It's a truly impressive feat to release so reliably so many projects year after year - you'd think that corporate internal and consumer software projects would take note and figure out what it is that enables the yearly release train to succeed when so many projects deliver late, over budget, or not at all. But, I digress...

Being a recent immigrant to the Nation of Mac, I was among the glad to see the Cocoa port graduate from incubation. However, all is not 100% happy in Eclipse+Mac land. The Eclipse Packaging Project (EPP), the small group that produces those easily consumable downloads, the themed packages of plug-ins built on top of the core platform, has limited resources. And with limited people, they can not produce the packages for every hardware/OS platform on which Eclipse is known to run. Of particular interest to me is the conspicuous absence of EPP package builds for 64-bit OS X. After some discussion, it appears we the community can't make a 64-bit build happen until the first "service release" of Galileo, sometime in the Fall. I'm disappointed, but I (mostly) understand the position that EPP is in.

So, what do we do if we want to make full use of all the 64-bit goodness of our operating system and Java 6 JVM? Well, it turns out that re-constructing the EPP packages from the "base platform" SDK is not all that difficult. Ekke Gentz has already blogged some text+picture instructions; my screencast below brings the process to life.

Note: the URL of the EPP update site used in the screencast is

http://download.eclipse.org/technology/epp/packages/galileo/

As part of the Eclipse Galileo release, we updated all of our training courses to reflect the latest release:

• Eclipse RCP Development (4 Days)
• Eclipse RCP Advanced Topics (3 Days)
• OSGi and Equinox (3 Days)
• OSGi and Equinox Primer (1 Day)
• RAP for Java Developers (4 Days)
• RAP for RCP Developers (2 Days)

We have also added two new courses to cover two popular topics, Equinox p2 and migrating to Galileo RCP:

• Provisioning Eclipse and OSGi systems with p2 (2 days)
• Migrating to Galileo RCP (2 days)

We are also offering our courses online now. If you’re interested in any of these courses, please email us.

With Eclipse 3.5 comes the new version of Xtext, called TMF Xtext. Since I had to switch to Eclipse 3.5 in order to keep GEF3D running on the latest Eclipse version, I decided to migrate from the old openArchitecture Xtext (oAW Xtext) to the new TMF version.

Fortunately the Xtext documentation contains a section about migrating from oAW Xtext to TMF Xtext. Frankly, I was a little bit afraid (never change a running system). But at least I hadn't implemented any content assist or other editor extensions yet, so I hoped that it wouldn't be too hard.

Before you read on, please note that I'm only an Xtext user. I don't know any internal details about Xtext. Maybe some of my problems can be solved more efficiently, if that is the case, I would be more then happy if you leave me a comment. My first intention was to migrate my already running grammar as fast as possible, with as few modifications as possible.

The Setting

1. migrate the grammar
2. adapt the M2M-transformation
3. adapt client code which uses the model and the Xtext API

Migrating the Grammar

RuleXY: ... ( "with" with=Block)? ...

RuleXY: ... ( "with" _with=Block)? ...

Backtracking

ParameterReference: QualifiedParameterReference|SimpleParameterReference;
SimpleParameterReference: type=Type (name=ID)?;  
QualifiedParameterReference: type=Type name=ID;

ParameterReference: SimpleParameterReference|QualifiedParameterReference;
SimpleParameterReference: type=Type (name=ID)?;  
QualifiedParameterReference: type=Type name=ID;

<fragment class="org.eclipse.xtext.generator.AntlrDelegatingFragment" />

<fragment class="de.itemis.xtext.antlr.XtextAntlrGeneratorFragment">
   <options k="2" backtrack="true" memoize="true"/>
</fragment>

Lexer Rules

Native INT: ('-')?('0'..'9')+ 

terminal INT: ('0'..'9')+ 

terminal FLOAT returns ecore::EFloat: ('0'..'9')*'.'('0'..'9')+;

OrmPackage missing

- WrappedException: java.lang.ClassNotFoundException: com.sun.java.xml.ns.persistence.orm.OrmPackage"

Unassigned Actions

NullLiteral: "null";

Block: "{" (statements+=BlockStatement)* "}";

NullLiteral: {NullLiteral} "null";
Block: {Block} "{" (statements+=BlockStatement)* "}";

Model Changes

Enumeration NULL values

process(ecore::EPackage p):
 addNullValue(p, "VisibilityModifier") ->
 ... ;

Void addNullValue(ecore::EPackage p, String toEnum):
 doAddNullValue( (ecore::EEnum) p.getEClassifier(toEnum) );
 
Void doAddNullValue(ecore::EEnum e):
 JAVA de.feu.MitraPostProcessorHelper.addNullValue(org.eclipse.emf.ecore.EEnum);

public class MitraPostProcessorHelper {

 public static void addNullValue(org.eclipse.emf.ecore.EEnum e) {
  for (EEnumLiteral literal : e.getELiterals()) {
   literal.setValue(literal.getValue() + 1);
  }
  EEnumLiteral nullLiteral = EcoreFactory.eINSTANCE.createEEnumLiteral();
  nullLiteral.setName("NULL");
  nullLiteral.setLiteral("NULL");
  nullLiteral.setValue(0);
  e.getELiterals().add(0, nullLiteral);
 }
}

Java Body Annotation in the Ecore Model

Void addJavaBodies(ecore::EPackage p):
 let ecorePackage = p.getEcorePackage():
 p.getEClassifier("Bounds").addOperation("isMany",
     ecorePackage.getEClassifier("EBoolean"),
       'return upper==-1 || upper>1;') ->
   ...;
/*
This is a hack in order to retrieve the ecore package itself. This is usually
done with a Java extension, but I did not want to add a Java extension here.
The trick is to retrieve the package by navigating to the container of an ecore
type (here a String).
*/
cached ecore::EPackage getEcorePackage(ecore::EPackage p):
  (ecore::EPackage)
  ( ((ecore::EClass) (p.getEClassifier("MetamodelDeclaration")))
    .getEStructuralFeature("type").eType.eContainer
  );
 

create ecore::EOperation addOperation(ecore::EClassifier c, String strName, ecore::EClassifier type,  String strBody):
 setName(strName) ->
 setEType(type) ->
 eAnnotations.add(addBodyAnnotation(strBody)) ->
 ((ecore::EClass)c).eOperations.add(this);


create ecore::EOperation addOperation(ecore::EClassifier c, String strName, ecore::EClassifier type, 
 List parameters,
 String strBody):
 setName(strName) ->
 setEType(type) ->
 parameters.collect(e|((List)e).setParameter(this)) ->
 eAnnotations.add(addBodyAnnotation(strBody)) ->
 ((ecore::EClass)c).eOperations.add(this);

create ecore::EParameter setParameter(List parameter, ecore::EOperation op):
 setName((String)parameter.get(0)) ->
 setEType((ecore::EClassifier) parameter.get(1)) ->
 op.eParameters.add(this)
;

create ecore::EAnnotation addBodyAnnotation(ecore::EOperation op, String strBody):
 setSource("http://www.eclipse.org/emf/2002/GenModel") ->
 this.createBody(strBody) ->
 op.eAnnotations.add(this);

create ecore::EStringToStringMapEntry createBody(ecore::EAnnotation anno, String strBody):
 setKey("body") ->
 setValue(strBody) ->
 anno.details.add(this);

API Changes

NodeUtil.getNode(..)

Node node = NodeUtil.getNode(eobj);

NodeAdapter adapter = NodeUtil.getNodeAdapter(eobj);
AbstractNode node = null;
if (adapter != null) {
 node = adapter.getParserNode();
}

Resources and Setup

public static void setup() {
   System.setProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE",
   "org.eclipse.emf.ecore.impl.EPackageRegistryImpl");
   MitraStandaloneSetup.doSetup();

No DSL-specific Editor Class

<extension point="org.eclipse.ui.editors">
   <editor
       class="de.feu.MitraExecutableExtensionFactory:org.eclipse.xtext.ui.core.editor.XtextEditor"
       contributorClass="org.eclipse.ui.editors.text.TextEditorActionContributor"
       default="true"
       extensions="mitra"
       id="de.feu.Mitra"
       name="Mitra Editor">
   </editor>
</extension>

public class MitraBreakpointAdapterFactory implements IAdapterFactory {
 public Object getAdapter(Object adaptableObject, Class adapterType) {
  if (adaptableObject instanceof MitraEditor) {
    ...

public Object getAdapter(Object adaptableObject, Class adapterType) {
 if (adaptableObject instanceof XtextEditor) {
  XtextEditor xtextEditor = (XtextEditor) adaptableObject;
  if ("de.feu.Mitra".equals(xtextEditor.getLanguageName())) {
  ...

Summary

This Monday the Eclipse DemoCamp took place in London at Skills Matter. You will find a comprehensive review at InfoQ by Alex Blewitt where you can read about NatTable (Dan Pollitt) and JQantLib/OSGi (Richard Gomes) as well as Xtext. And thanks to Eren Aykin you will find a video podcast of the latter, too!

This time I tried to spread the idea of DSLs with chess and different ways of expressing moves within the game. In the first part of my presentation I processed cryptic notations like “Rd2-c2″ or more natural equivalents such as “rook at d2 moves to c2″ to work with them as true Java objects and eventually visualized chess fields. Second, I tried to emphasize the value of DSLs in today’s software projects where we implemented another DSL live at the DemoCamp in the end. You will find my slides at SlideShare again.

It was quite informative to chat with the Eclipse folks in London afterwards. Most of them have a pragmatic view at modeling and tools in general. I really appreciate this! Thank you, Neil, for organizing this event and inviting via twitter.

Links

• Slides at SlideShare
• Video Podcast at Skills Matter
• Review at InfoQ

Source Code

Loading chess DSL text files as Java objects:

package org.xtext.example.chess;

import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.xtext.resource.XtextResourceSet;
import org.xtext.example.ChessStandaloneSetup;

public class JavaTest {

	public static void main(String[] args) {
		String filename = "some/path/MyModel.chess";
		Game g = getGame(filename);
		System.out.println(g.getWhitePlayer() + " vs. " + g.getBlackPlayer());
		for (Move m : g.getMoves())
			System.out.println(m.getSource() + " to " + m.getDest());
	}

	private static Game getGame(String filename) {
		ChessStandaloneSetup.doSetup();
		ResourceSet rs = new XtextResourceSet();
		Resource res = rs.getResource(URI.createFileURI(filename), true);
		return (Game) res.getContents().get(0);
	}

}

You might already know Acceleo 2.6, the open source model-to-text generator, and wonder how version 2.6 could come down to 0.8. The reason is quite simple : after four years of development outside of Eclipse, Acceleo is now taking a turn (for the better we hope :)) since we began rewriting it within Eclipse as the implementation of the OMG MOF Model to text Transformation Language (MOFM2T) specification. This change and our becoming an Eclipse-hosted project calls for a mandatory incubation period, thus version numbers "0.x".

Acceleo 0.8 already offers basic solutions to migrate existing Acceleo 2.x templates to the new syntax. This migration is still a draft and we are working on improving it so that most "old" templates can be migrated to the new syntax automatically, or with the least amount of manual editing needed. Compatibility with Eclipse itself is detailed on Acceleo wiki page.

This first release of Acceleo as the implementation of the MOFM2T specification already provides most of the tooling that can be expected from an M2T generator. A succinct list can be found on the New and noteworthy wiki page.

Je suis très heureux d'annonçer la sortie imminente de la nouvelle édition de "Spring par la pratique". La parution en librairie est prévu pour le 9 Juillet 2009 et la version ebook est d'ores et déjà disponible.

Un grand bravo à Thierry Templier, Arnaud Cogoluègnes et Julien Dubois qui ont fait un travail de titan sur cette nouvelle version. Vous y trouverez toutes les nouveautés de Spring 2.5 et Spring 3.0 ainsi que des nouveaux chapitres sur Spring Batch ou encore Spring DM.

J'ai eu l'occasion de participer modestement à cette aventure et de contribuer une annexe traitant de l'industrialisation des développements Spring dans Eclipse. Vous devez vous doutez que cette industrialisation est basée sur une approche dirigée par les modèles et utilise le générateur Acceleo

Cette nouvelle version atteignant pas moins de 680 pages, les annexes ne seront pas inclus dans l'édition. Mais elles seront bientôt disponibles pour tous en téléchargement sur le site dédié créé pour l'occasion : http://www.springparlapratique.org. La listes des annexes :

• Annexe A : SpringIDE
• Annexe B : Développement OSGi dans Eclipse
• Annexe C : Industrialisation des développements Spring dans Eclipse

Aussi, je profite de ce billet pour relayer l'annonçe de Freddy sur un événement à ne pas manquer "Eclipse Acceleo Day". La communauté Acceleo se retrouvera le 10 Juillet 2009 à Nantes. Cette événement se déroulera pendant les 10ème RMLL. Vous trouverez toutes les informations ainsi que le programme complet ici.

Inscrivez-vous vite, il ne reste que peu de temps avant la clôture des inscriptions !

I refused to give in to my keyboard problems I posted about yesterday and it looks like a bit of perseverance has paid off.

My problem was to do the the Microsoft Keyboard Mac driver (no surprises there). Specifically the keyboard is a PC keyboard, and it also has a British layout. This is significant because the Mac British keyboard layout is fairly different, and although it worked with Gailieo the keys were all mapped incorrectly.

In the image below you can see the Microsoft British layout. With this selected, neither the USB Keyboard or my MBP keyboard worked in Galilieo. So I searched around and came across a helpful fellow who produces a home brew British PC Keyboard layout (also seen below). With this installed I have British keys, and 64 bit Galileo, yay!

Nokia Java Runtime 2.0 for S60 (JRT 2.0) has been released for beta testing and now available from Nokia beta labs site. This is a package that upgrades the Java runtime on the phone (tested with Nokia 5800 XpressMusic, and N97) with this new one. This is the first time we are testing the independent release/upgrades of Java Runtime from S60 releases. In the future this will allow us to deliver the latest and greatest JRT to older phones.

Some of the new features and improvements that will be noticeable (also listed on release notes) are one-click application installation, application launch user experience, and execution performance. I must tell about a feature that I am proud of and can be interesting to the readers of this blog. The Java installer in JRT 2.0 (the application that installs midlets) is itself a Java application. In fact, the UI(prompts etc. ) for the installer is developed using eSWT. I am very excited about the new installer because it proves that eSWT can be used to create native looking UIs, even ones that are integrated to the system.

Thanks to the generous sponsorship of the GNOME Foundation and GNOME Travel Committee, on Thursday I’m heading to the Gran Canaria Desktop Summit. This conference is a combination of GUADEC and Akademy and promises to be an excellent week of discussions, presentations, etc.

I’ll be giving a talk on Eclipse, focusing on our work at the Linux Tools project and of course showing the CDT and Mylyn and all the other awesome stuff I can fit into 30 minutes. I’ve been to GUADEC twice before and was really impressed with everyone’s enthusiasm. I’m sure this year will be just as good and I look forward to the inspiration that comes from conferences like this.

The first Eclipse Acceleo workshop will take place on July 10, 2009 in Nantes. More information available here: http://www.acceleo.org/wiki/index.php/EclipseAcceleoDay
The complete program is now available with a lot of interesting talks dealing with Eclipse, MDE, DSM and of course Acceleo ;-)

Hour	Title	Presenter	Affiliation	Language
09:00	Introduction	Etienne Juliot	OBEO	English
09:30	Presentation of a DSM-oriented design and generation environment	Erlé Le Gac	Capgemini	French
10:00	MDA & Acceleo deployment feedbacks	Vincent Fady	Atos Origin	French
10:30	Coffee break
11:00	Acceleo, contribution to the industrialization of developments: Feedback from Bull-Centre de Services Paris	Olivier Leal	Bull	French
11:45	An Open-source Model Driven software development toolset - Lesson learned from Orange Labs	Samuel Liard	Orange Labs	French
12:15	Lunch
14:00	MDSD Scaffolding and Acceleo	Cédric Vidal	Proxiad	English
14:30	Presentation of WISSS (Webapp Is Simple, Stupid and Secure)	François Gaudin	Makina Corpus	English
15:00	Acceleo MTL: a standard alternative for code generation	Cédric Brun	OBEO	English
15:45	Coffee break
16:15	EEF powered by Acceleo MTL - Acceleo MTL ... and punishment!	Goulwen Le Fur	OBEO	English
17:00	Panel

This workshop is free but with mandatory registration (for organisation purposes). Registration details are available here: http://www.acceleo.org/wiki/index.php/EclipseAcceleoDay

Hope to see you there :-)

This is another post in what is becoming a short (so far only two) series about moving a product from 3.4 to 3.5.

After I got my build working, the next step was making sure that I could update from one product version to the next. I was especially excited about the resolution of https://bugs.eclipse.org/bugs/show_bug.cgi?id=246060 which allows for .qualifier to be replaced in a product version. No longer would I have to manually increment the product version number for purposes of updating to and testing a nightly build.

So my plan was:

1. Run PDE product build to generate version 1.0.0.abc
   
2. Unzip 1.0.0.abc to some location.
   
3. Run PDE product build again to generate version 1.0.0.def
   
4. Launch 1.0.0.abc, point it at the repository for 1.0.0.def, and update.
   
5. ...
   
6. Profit.
   

So I've fully switched from Eclipse Ganymede to Galileo, at work and at home. At home I thought I'd try the the Mac Cocoa 64-bit version (available here) to give the new Apple JDK 1.6.0_13 for a spin.

Unfortunately when I fire up the 64-bit Eclipse, I get no input from the keyboard. All mouse driven input woks fine, but I get no joy with the keyboard. I did a bit of fiddling to get it to work, but gave up and reverted to JDK 1.5.x. If The Internet has any advice, I'd love to get it working, it felt really snappy from what I could see...

Since getting my Mac earlier this year, the (weak) Java support is my biggest gripe. Why is Java the poor cousin, my guess is that Apple doesn't want any competition from within, so it's easier to "cripple" Java in OS X. I won't bleat on any more about it, there are plenty more knowledgeable folk blogging about it.

UPDATE: Looks like this is a known issue with attaching PC keyboards to a mac and using Eclipse 64-bit Cocoa.

In this article I will explain how to create a custom widget that displays a popup notification dialog in the bottom right corner of your screen (usually above the toolbar on Windows). Here’s what it will look like when we’re done:

We could custom draw everything which would allow us more control over the widget, but for the sake of this article lets stick to using basic SWT components inside a normal Shell that we will make a bit prettier than your typical SWT Shell.

(Do note this has only been tested on Windows, it’s quite possible tweaks are necessary for other platforms).

The Shell

What we want is a Shell that stays on top of our application (but not on top of all applications) and doesn’t steal the active focus or else it would show up in your task manager or move focus away from where the user is now. We also don’t any normal Shell “trim” borders, we’ll draw our own. Creating it is easy as all of our requirements are available via SWT flags. Thus we can create the Shell as follows:

_shell = new Shell(Display.getDefault().getActiveShell(), SWT.NO_FOCUS | SWT.NO_TRIM);

As we have SWT widgets inside our shell and we intend to use a gradient background on the shell itself, all the widgets need to be transparent. This is done by setting the Background Mode on the shell to SWT.INHERIT_DEFAULT. This tells the widgets to inherit the background of their parents, and gives us what we want. So after we create the shell we simply call;

_shell.setBackgroundMode(SWT.INHERIT_DEFAULT);

So how do we get a gradient background on a shell? It certainly don’t support it by default. You can set a foreground and a background but that’s about it. The trick is to paint an image with the colors we want and use that as the shell’s background. To set it at the right time, we listen to the SWT.Resize event on the shell and do it then with the following code;

_shell.addListener(SWT.Resize, new Listener() {
    @Override
    public void handleEvent(Event e) {
	try {
	    // get the size of the drawing area
	    Rectangle rect = _shell.getClientArea();
	    // create a new image with that size
	    Image newImage = new Image(Display.getDefault(), Math.max(1, rect.width), rect.height);
	    // create a GC object we can use to draw with
	    GC gc = new GC(newImage);

	    // fill background
	    gc.setForeground(_bgFgGradient);
	    gc.setBackground(_bgBgGradient);
	    gc.fillGradientRectangle(rect.x, rect.y, rect.width, rect.height, true);

	    // draw shell edge
	    gc.setLineWidth(2);
	    gc.setForeground(_borderColor);
	    gc.drawRectangle(rect.x + 1, rect.y + 1, rect.width - 2, rect.height - 2);
	    // remember to dipose the GC object!
	    gc.dispose();

	    // now set the background image on the shell
	    _shell.setBackgroundImage(newImage);

	    // remember/dispose old used iamge
	    if (_oldImage != null) {
		_oldImage.dispose();
	    }
	    _oldImage = newImage;
	}
	catch (Exception err) {
	    err.printStackTrace();
	}
    }
});

The Contents

Our shell consists of 3 sections, an image at the top left (which is a normal CLabel). Then a label that contains the header text (also a CLabel), and finally a label which represents our message (a normal Label). We use a Label at the end instead of a CLabel as Labels support wrapping and multi-lines better than the CLabel does. You could of course use pretty much any widgets you want. Here’s an outline of what section each label covers:

We use a GridLayout with some 5px margins (except at the top) and the widgets are created normally without any special magic, so I won’t show that code here (it’s all at the bottom for you to download).

Some Eye Candy – Fading

Shells support alpha values as of SWT 3.4, so we’ll use this to make our “appearing” and “disappearing” a bit prettier. All we need to do to make a shell fade in and out is to have a thread that loops and increases/decreases the alpha channel value for the shell. As we need to be on the Display thread to do this it’s easiest to do it all via a runnable that we let the Display object run for us at a given interval.

We need to remember to continuously check to see if the shell is disposed as it can happen when we’re on a thread. When we’re finished fading in, we want the shell to stay visible for a certain amount of time, and then we want to fade out. So basically the chain is this:

• Create shell
• Fade in shell
• Stay visible for X seconds
• Fade out shell
• Dispose shell

All these timers are more or less similar in terms of how the code looks, so I’ll show one example here and for the rest you can look at the complete source downloadable below. We have some global variables here that should be explained.

• FADE_IN_STEP is how much we increase the alpha value for each iteration.
• FINAL_ALPHA is a value that declares what the final alpha value will be for the shell when it stays visible. I find that a slightly transparent shell gives a better effect, so by default this value is 225 (out of 255 which is a solid [opaque] shell).
• FADE_TIMER is how long we wait until increasing the Alpha value again. When the shell has reached it’s max-alpha value we call the startTimer() method, which is a thread that sleeps for a certain number of seconds before calling the fadeOut() method.

private static void fadeIn(final Shell _shell) {
    Runnable run = new Runnable() {

        @Override
        public void run() {
            try {
                if (_shell == null || _shell.isDisposed()) { return; }

                int cur = _shell.getAlpha();
                cur += FADE_IN_STEP;

                if (cur > FINAL_ALPHA) {
                    _shell.setAlpha(FINAL_ALPHA);
                    startTimer(_shell);
                    return;
                }

                _shell.setAlpha(cur);
                Display.getDefault().timerExec(FADE_TIMER, this);
            }
            catch (Exception err) {
                err.printStackTrace();
            }
        }

    };
    Display.getDefault().timerExec(FADE_TIMER, run);
}

Stacked Notifications

There’s one last thing we want to support, which is stacked notifications. Assume our notification shell’s entire life-span is about 5 seconds, what if we have another notify call before the first one has finished showing? We could dispose the first shell and replace it with the new one of course, but a much prettier approach is to simply move the previous shell up, and show the new notification below it. The effect of this is something like this (this screenshot was taken just as the old shells started to fade out, hence the higher alpha on them):

What we do to achieve this effect is rather simple. Every time a notification shell is opened, we keep a reference of it in a static array of shells. When it’s faded out (and disposed), it’s removed from the list. Thus, when a new shell is created we simply check to see what’s already in the array and then set the location for each old shell in the array to -heightOfNewNotificationShell (so to speak). Thus, the old shells move up to make room, but continue their fade-in/fade-out cycles just like before.

Further Improvements

Everything could be made prettier than it already is of course, perhaps you want an “X” close button, or different colored text, or rounded shell corners. None of that is in the current code, but the code should give you enough to go on to implement most of that without any major problems.

Also note that I currently use Display.getDefault().getActiveShell() for the parent shell of the popup. You may want to refactor it to use a more permanent shell as otherwise a disposal of whatever the parent shell was whenever the popup was displayed will cause the notification to dispose as well.

The code is not perfect, it’s an example to build on (if you so wish).

Download Code

I’ve created an Eclipse project with the code and also the ImageCache/FontCache/ColorCache classes I use in the code (all they do is keep already used images etc in memory so that they don’t need to be re-created). There’s also a jar with the images I’ve used in this example. If you like them and want more like it, there’s a massive image pack with exactly these icons and more here: Gnome Colors Icons.

Do note you may need to adjust your CLASSPATH settings for the project to reflect the location of your SWT jars.

To run the code, simply run the Tester.java class and push the big button to create a notification. Push it again before the first one fades away to see the stacking. A random image will be used every time you push it.

DOWNLOAD CODE

Conclusion

Hopefully this gives you an insight into how to create a “custom widget” (without much custom painting). Have fun!

Galileo is out ... and with it came the graduation of EMF Compare to 1.0 at last!

A great deal of improvement has been made in EMF Compare so as to improve user experience and effectiveness. This release sees the usual new differences EMF Compare detects (reference order changes, resource dependencies, ...), and an improved support for the various VCSs (CVS, SVN, ...).

The most outstanding improvement is the ability to compare whole ResourceSets instead of a single model; allowing users to compare fragmented models as well as linked models (UML models referring to profiles, Genmodels referring to ecore models, ...) and thus detecting changes made in the selected models along with changes that can have taken place in their dependencies.


Thanks to a contribution from Moritz Eysholdt, EMF Compare now provides a patch format for model merging. This EPatch format is associated with a textual syntax thanks to XText, allowing for easier editing and improved readability of these patches.


The full list is available on EMF Compare 1.0 new and noteworthy wiki page.

One of the courses I study in the Farmyard Podcast University is economics. I like making sense of the world, and sometimes economics help make sense of the world. Sometimes. Sometimes it seems flatly contradictory. Here is one of those cases.

The theory of production states that in a competitive market, prices will stabilize at the marginal cost of production. That is, if I am a farmer with a bunch of wheat, I will be willing to sell my next kilo at the cost to raise that additional kilo. If seed, fertilizer, and diesel cost me $10 for that kilo, I will rationally take anything more than $10 for it. Since lots of other farmers are also competing to sell wheat, the price will fall to $10. I would be a chump to insist on a higher price and risk not selling at all. I would be a chump to sell for less than my cost of production. Price = marginal cost of production.

The theory or production is used to “logically” justify a price of $0 for information. Since the marginal cost of production (the amount to distribute the next download) is essentially zero, so the story goes, the price for information will tend to zero.

Enter CAPEX

This theory takes a very narrow view of economics. Somebody has to pay for the tractor and the land. In this model, such costs get paid for out of an irrelevantly small slice of the price.

Businesses divide the money they spend in to capital expenditure, CAPEX, and operational expenditure, OPEX. CAPEX is money spent in anticipation of future gain, like buying a new tractor or writing a programming tool. OPEX is money spent in anticipation of immediate gain, like buying seed or paying this month’s bandwidth bill. The distinction between CAPEX and OPEX is important for tax reasons and because balancing the two in various ways can offer different business models.

OPEX is really our friend the marginal cost of production by a different name. Bringing CAPEX into the picture highlights the absurdity of the “price = marginal cost of production” theory as OPEX trends to zero. That little “capital tax” added to every price becomes increasingly significant. What happens when price = marginal cost = $0? Like quantum effects, once you reach a certain scale the rules change. The Newtonian economics of “price = marginal cost of production” are overwhelmed by the need to finance the upfront capital. The form of solution to this has yet to emerge.

Is This Really a Problem?

One of the factors that has kept this dilemma from being a problem to date is increasing capital efficiency. A programmer today can produce software for much, much less than he would have required for the same functionality even ten years ago. In fields like journalism or music, the cost of doing an okay job has likewise fallen dramatically.

The word “okay” is important in that last sentence. There is a difference between an article written by Malcolm Gladwell (on this very topic) and one written by, well, me. But if his costs money and mine is free and you don’t care enough about the difference, he can’t charge for his. I don’t care about charging for mine, because I make my money on, on, on… I’ll get back to you on that.

Cracks are appearing in the system. One of my pressing needs is an efficient environment for collaborating in real-time on code. Many projects have started to provide such functionality, but most (all in the Eclipse world) have stalled short of solving the problem. Increasing capital efficiency in this case can’t overcome the size of the task of solving a difficult programming problem. The capital just isn’t there to solve the whole problem. A group of smart, poor graduate students can’t muster the capital necessary to solve it and a VC would have to be crazy to invest in it, given that no one will pay for a solution. And so a socially, economically significant problem goes unsolved.

I don’t have a resolution of this dilemma. CAPEX is immovable but the pressure for “price = marginal cost of production” is unstoppable. One argument was that in a world of abundance, things that couldn’t be replicated easily, like one’s own physical presence, would increase in value. I am not finding that to be true, but I’m experimenting with selling a remote pair programming session. I’ll get back to you on how it works. In the meantime I have some good ideas waiting for capital, I just can’t promise any payoff. I know I’m not alone.

Xtext has been released as a part of the Eclipse Galileo release train on June 24th, 2009. Xtext is a framework for building DLSs (domain specific languages). In fact, it can be seen as a DSL for defining DSLs.

In this article, we will develop a small DSL for defining entities.

Download and Install

Hop over to http://xtext.itemis.com and download an Xtext distribution matching your platform. We've got all major platforms: Windows, Mac OSX Carbon, Mac OSX Cocoa 64, Mac OSX Cocoa 32, Linux Gtk 64, Linux Gtk 32.

To install, unzip the distribution file to a directory of your liking.

Windows users, please make sure you unzip to a directory near to your filesystem root! Eclipse contains files and folders with long names that might be hard to handle for Windows.

Create a new project

After launching Eclipse and creating a new workspace (or using an existing one), create a new Xtext project by selecting File -> New... Project... -> Xtext Project. In this article, we're creating a DSL for describing entities, so let's go with the following settings:

• Main project name: org.xtext.example.entity
• Language name: org.xtext.example.Entity
• DSL-File extension: entity
• Create generator project: yes

Click Finish to let Xtext create the three projects that make up your DSL:

• org.xtext.example.entity - this project contains the DSL itself, including all back end infrastructure like the parser and the meta model.
• org.xtext.example.entity.ui - as the name implies, this project contains all UI centric code of the DSL: the editor, the outline, content assist and so forth
• org.xtext.example.entity.generator - this project contains a code generator which will transform the DSL scripts (aka models) you write in your DSL into something useful. In our example, we will create some POJOs and DAOs from our models.

Upon finishing creating these three projects, Xtext opens a file Entity.xtext, which contains a sample grammar, which we will change in a second.

Define the grammar for your DSL

Next up, we need to define the grammar for our DSL. To make things easier for us, let's first write down a sample model. Please open org.xtext.example.entity.generator/src/model/MyModel.entity and key in the following text:

typedef String
typedef Integer
typedef Date mapsto java.util.Date

entity Person {
  String name
  String surName
  Date birthDay
  Address home
  Address work
}

entity Boss extends Person {
  Person* employees
}

entity Address {
  String street
  String number
  String city
  String ZIP
}

Most of this model should be pretty obvious, but there are two things worth noting:

• We define our own list of data types to gain a certain degree of flexibilty, i.e. to map them to different types in the host language, as can be seen for the Date data type, which gets mapped to java.util.Date (we might also decide to map it to java.sql.Date
• The star (*) denotes multiplicity. We might also have chosen square brackets (Person[] employees) or something completely different - it's largely a matter of taste.

Let's derive the grammar for this model. Open org.xtext.example.entity/src/org/xtext/example/Entity.xtext, erase its entire contents and enter the following:

grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals
generate entity "http://www.xtext.org/example/Entity"

The first line indicates we want the new grammar to be derived from the (built-in) grammar Terminals, which defines some basic terminal rules (like STRING, ID and so forth). If you're interested, CTRL+Click on the language name to navigate to its definition.

The second line defines the name and namespace URI for our own grammar.

Let's now define that our DSL supports types. Add the following lines:

Model:
  (types+=Type)*;

Type:
  TypeDef | Entity;

This tells Xtext that our Model contains any number (i.e. 0..N, as declared by the *) of Types. What exactly a Type is needs to be specified. Apparently, a Type can be either a TypeDef or an Entity:

TypeDef:
  "typedef" name=ID ("mapsto" mappedType=JAVAID)?;

A TypeDef starts with the keyword typedef, followed by an ID making up its name. Following the name, we can optionally (hence the question mark at the end) add a mapsto clause. The fragment mappedType=JAVAID specifies that the TypeDef will later have an attribute named mappedType of type JAVAID. As JAVAID is not yet defined, we need to do so:

JAVAID:
  name=ID("." ID)*;

So, a JAVAID is a sequence of IDs and dots, making up a qualified Java type name, such as java.util.Date.

Next, let's define how to model entities:

Entity:
  "entity" name=ID ("extends" superEntity=[Entity])?
  "{"
    (attributes+=Attribute)*
  "}";

As you might have guessed, Entitys start with the keyword entity, followed by an ID as their name. They may optionally extends another entity. Surrounding a rule call with square brackets means "this is a cross reference", i.e. a reference to an already existing element.

Entitys do have Attributes (any number, to be precise), thus we have to define how Attributes look like:

Attribute:
  type=[Type] (many?="*")? name=ID;

By now, you should be able to read this rule: an Attribute has a type which is a cross reference to a Type (which is either a TypeDef or an Entity), it has an optional multiplicity indicator (the star) and - of course - if has a name.

Your grammar should look like this by now:

grammar org.xtext.example.Entity with org.eclipse.xtext.common.Terminals

generate entity "http://www.xtext.org/example/Entity"

Model:
  (types+=Type)*;

Type:
  TypeDef | Entity;

TypeDef:
  "typedef" name=ID ("mapsto" mappedType=JAVAID)?;

JAVAID:
  name=ID("." ID)*;

Entity:
  "entity" name=ID ("extends" superEntity=[Entity])?
  "{"
    (attributes+=Attribute)*
  "}";

Attribute:
  type=[Type] (many?="*")? name=ID;

Compiling the DSL

Now it is time to see the fruits of our labor. But first, we need to compile our grammar. Xtext will create:

• a parser
• a serializer
• an Ecore meta model
• a full blown Eclipse editor

from this grammar. To make this happen, please select org.xtext.example.entity/src/org/xtext/example/GenerateEntity.mwe and select Run As -> MWE Workflow from the context menu. Xtext will now generate the entire infrastructure for your DSL and after a few seconds you should have a shiny new DSL including a great editor.

Taking it for a spin

Seeing is believing, so let's take the DSL editor for a test drive. Select the DSL project org.xtext.example.entity and, from the context menu, select Run As -> Eclipse Application. A second instance of Eclipse will be started.

In this new instance, create a new, empty project (File -> New -> Project... -> General -> Project. Create a new file Sample.entity in the new project.

You can now insert the model we designed above or enter a new model:

Leveraging the model

Now that we've got a fancy editor for our DSL, we want to transform the models we can create with this editor into something meaningful. This, however, will be the topic of the next installment.

More info

Feel free to discuss this article in the comments section of my blog. Should you have any technical questions regarding Xtext, we've got an excellent newsgroup where the committers answer your questions. We also offer professional (commercial) support, i.e. customized trainings to get your team up to speed. Just drop us a note, we're happy to discuss the details with you.

In his posting All contributions are Equal, some are more equal than others, Robert Konigsberg points out that contributing multiple ways of doing things can easily lead to more user complexity (e.g., by having multiple toString generators).

This is true and in my view, a risk for any system that has many strongly-opinioned contributors (pretty much any large open source project).

Toward the end of his post, he poses a process-level question about how to avoid the situation of some contributions being more equal than others…. I think the solution is the current de facto for Eclipse.org projects and that’s the (frequently unstated) reality that the early bird defines the worm.

When it comes down to it, those that initiate and then follow through on enhancements, fixes, documentation or other contributions get to choose when it comes to actual design decisions. Inevitably, there are design choices that some disagree with, even when all discussion is had completely in the open.

I think the truth of the early bird defines the worm statement is that we should provide incentive to organizations and individuals in the community to be more aggressive about contributing to existing Eclipse projects. This is because  waiting for someone else to initiate, design, implement, test and document something often doesn’t work very well.

To some, it may seem like Eclipse Project development is effectively subsidized by others, but this is not true.  Even for one’s own usage of Eclipse, contribution and community involvement with Eclipse.org projects pays dividends. There are many ways to contribute, from contributing discussion/ideas, to planning, to new example/app code, to helping to maintain existing code, to documentation, to build support, to testing and bug reporting, to providing bug fixes, to mentoring, and plenty of other kinds of support.

In my view, these are the ways to get your contributions into Eclipse, and influence the community around the software.

Here’s my understanding of where the toString() contribution originated.

We usually consider choice as being a good thing, whether it be around choice of restaurant, chocolate bar, clothing, or technology.  Choice makes us feel empowered, and variety adds richness to life.

Not surprisingly, embedded in the design philosophy of Eclipse is the notion that “choice is good”.  Clearly then, if some choice is good, more choice is better. And darn if Eclipse doesn’t give you a LOT of choice!  The preferences alone should make any humble programmer feel empowered to tweak the IDE into exactly the shape and behaviour you want.

However, it turns out that in practice, while we believe we want choice, there is good research suggesting that more choice makes us less happy.  For an excellent book on the subject, I highly recommend The Paradox of Choice by Barry Schwartz.

I’ve been pondering this a lot lately with respect to user interface design in general, and Eclipse specifically. What we often forget (and Schwartz does a great job of explaining) is that there is a cost to choice.  One must understand the choices themselves, one must be informed, otherwise we risk choosing wrong.  Not only does that comparison itself imply a cost (learning, weighing), but bad choices cost us more than good ones benefit us.  That is, we feel the negative impact of say losing $50 to a greater extent than we feel the positive emotional impact of winning the same amount.  Therefore, paradoxially, although we seek choice, we actually prefer not to choose.  There’s much more in the Scwartz book and I encourage you to read it.

Thus a common misbelief in UI design is that giving the user more choice will increase the usability of the product.   It’s almost always not true.  What choice does is increase the utility of the product, because you can use it for more things, or in more ways.  But it reduces the usability, because the choice brings with it a cost that the user must bear.  (Note that I’m ignoring accessibility related preferences since these obviously increase usability for those who need them).

A favorite example is the following dialog that you get post P2 update.

Now to be clear, I’m not picking on P2, this happens to be a good example, and there are many more throughout Eclipse.  Plus, I must confess that I had a hand in this dialog.

The dialog is there to support the set of users who know under which conditions the workspace does not need to be restarted.  Personally, I refer to it as the “Feeling lucky, punk?” dialog.  Susan and I have had many discussions about this dialog and in keeping with the theme of “just enough rope to hang yourself with” decided to leave it in Eclipse for the power users.  For many though, it leaves you scratching your head, or even a little afraid.  These “some add-ons”, how do I know which they are?  Is there a list?  If yes, why doesn’t Eclipse have this list so it doesn’t have to ask me?  If such a list can’t exist, then what chance do I have? What happens if I say “No” and don’t restart, will bad things occur?  If so, why do you let me do it?  If not, then why aren’t two choices sufficient?  What are the warning signs that I should’ve said yes, and then what should I do to fix it?  It’s asking me if I want to restart, but it’s giving a binary choice (yes/no), plus another choice, so will “Apply Changes” restart or not?  And if not, does it mean that “No” didn’t apply the changes?  I’m afraid!  Mommy!!

Thus we’ve increased utility (advanced users can work more efficiently), but we’ve decreased usability (all users are forced to make a decision with no guidance, where the consequence of picking the non-default is unknowable at that moment).

Next time you go to add a preference or provide a choice dialog, it’s worth considering the cost of the choice and it’s impact on usability.  Ask yourself, “Have I really benefitted the majority of my users in providing this?  Or have I benefitted a few at what cost to the many?”.

I posted a problem to the PDE newsgroup last week about unexpected requirements in my product feature. This was in the context of moving a 3.4-based product to 3.5.

The general issue was that the director wouldn't install my product because of an unsatisfied requirement. It wasn't clear to me where this requirement was even coming from. Somewhere, there was some metadata in my plugins/features that expressed a dependency that had worked fine in 3.4 but failed in 3.5. My theory was that if I could capture when the publisher was generating the requirement, I'd be able to see the source of that requirement and squash it.

Tracing

First attempt was to turn on tracing for the p2 components. I managed to find the org.eclipse.equinox.internal.p2.core.helpers.Tracing class which listed out the different options. I stuffed those into a .options file:

org.eclipse.equinox.p2.core/debug=true
#org.eclipse.equinox.p2.core/generator/parsing=true
#org.eclipse.equinox.p2.core/engine/installregistry=true
#org.eclipse.equinox.p2.core/metadata/parsing=true
#org.eclipse.equinox.p2.core/artifacts/mirrors=true
#org.eclipse.equinox.p2.core/core/parseproblems=true
#org.eclipse.equinox.p2.core/planner/operands=true
#org.eclipse.equinox.p2.core/planner/projector=true
#org.eclipse.equinox.p2.core/engine/profilepreferences=true
org.eclipse.equinox.p2.core/publisher=true
#org.eclipse.equinox.p2.core/reconciler=true
#org.eclipse.equinox.p2.core/core/removeRepo=true
#org.eclipse.equinox.p2.core/updatechecker=true

1. Passing -debug to the Platform also passes -debug onto Ant, thanks to AntRunner. So my Ant ran in debug mode which really clouded the issue with about 8mb of debug output.
   
2. The publisher only outputs two trace statements: start and finish. Nothing about what it is publishing. This may be a candidate for enhancement.
   

• Do not pass the debug flag to AntRunner for purposes of debugging platform code unless you are prepared to wade through volumes of output. (I guess this is a feature of AntRunner - https://bugs.eclipse.org/bugs/show_bug.cgi?id=5672)
  
• It was not at all apparent to me to debug p2 actions by setting up a "remote" debug session with PDE build running inside of AntRunner. But it was sure as heck helpful once I figured it out.
  
• I am actually glad that I ran across this problem, and that p2 is enforcing these types of constraints, because it helped me clean up outdated dependencies in my feature.
  

This evening I read Cay Hortmann's article on upgrading to Galileo. (For those of you who do not know Cay, he writes the fantastic Core Java books. I learned Java from the 1.1 version, as well as both the 1.4 and 1.5 versions. He writes great stuff.)

In the article he makes this comment:

There is now an option to generate toString automatically. This is something I've wanted for a long time. Unfortunately, it is not very good. Core Java gives these simple rules for toString:

• Use getClass().getName() to print the class name. Then your toString can be inherited.
• When you redefine toString in a subclass, first call super.toString(), then add the subclass data.

The Eclipse formatter follows neither of these eminently sensible rules. Maybe in 3.6.

As the Contribution Rule reminds us, “Everything is a contribution.” And with many contributions, the possibilities are endless.

Recently I launched Hudson Helper for iPhone and iPod Touch, enabling Continuous Integration fans to stay in touch with their projects. Android users can get in on the game now too, with Hudson Helper for Android.

Hudson Helper for Android provides all of the same features as the iPhone version including support for multiple servers and authentication. New for this version are build controls: start and stop builds right from your phone. CI can be even more fun with shake-to-build and sound effects.

To get Hudson Helper for Android, search for 'Hudson Helper' in the Google Market on your Android device.

The SCA Tools project has seen an enormous amount of new development since the 2008 Ganymede release. We’ve added an XML editor to make editing and updating SCA-standard assembly files really easy.

For Java developers, it’s now possibly to create an SCA assembly definition and then generate Java code from it. And, if you want to start with some Java you already have, we’ve added a special introspector that will investigate your code and automatically produce an SCA assembly.

Once you’ve created your Java SCA project, you can then run and debug it using the great facilities that Eclipse provides.

We also have made sure that the SCA artifacts you might create are properly validated, helping you spot mistakes early in the process.

We even took the time to update the graphics, giving us a prettier SCA Composite Designer.

For me, the most exciting feature is how we’ve developed the core SCA model to be extensible by people who want to write in extra capabilities into the tools. The heart of the model contains the SCA standard specifications, and different extensions have been created to support the key Open Source SCA runtimes - Apache Tuscany 1.4 and Frascati 0.5. Using the extension mechanisms, it is much more straightforward to add new concepts to SCA and extend the tools to include them.

SCA Tools has been improved a lot. Download SCA Tools 2.0.0 now!

Here are the slides to a short presentation I gave on persistence at OSGi DevCon Europe in Zurich. I had 30 minutes and wanted to do a demo to show that EclipseLink is running nicely in OSGi--it was tough cramming all this in but I did it without a moment to spare. Enjoy the slides and if they spark some questions you can post them here on the blog or on the EclipseLink newsgroup at http://www.eclipse.org/newsportal/thread.php?group=eclipse.rt.eclipselink or the eclipselink-users mailing list.
--Shaun

This is the third time when Eclipse DemoCamp was organized in Krakow. On Jun 27 (Saturday) Eclipse fans from Krakow met in Baraka club at Kazimierz in Krakow.



Kazimierz is an old Jewish department of Krakow. You can read more about it here. For us important is the atmosphere there which is in favor for such events.



Since we wanted to celebrate the Galileo release, we didn't fill the whole time with talks and demos.



More than a half of the time was just chatting with beer and pizza in hands. This way we managed to answer more questions and meet more people personally than we could do otherwise.



People came despite the rain. I understand that this could be hard to wake up early on Saturday when it rains. However Eclipse people are tough guys and girls, so rooms at the club were full.

Moreover we found a new application for laptops. Yet another proof that ThinkPads rules :)



The agenda and the list of attendees can be found here.

Don't forget that the next DemoCamp is in November and you are all welcome. Cheers!

Today, Bioclipse 2.0 Release Candidate 4 (versioned 2.0.0.RC4) was released. The release requires a fresh download from Sourceforge, and we kindly ask beta-testers for bug reports on the bugs.bioclipse.net.

Hopefully this will be the candidate for the 2.0 release.

Galileo? Me too :-)

I've just released updates for two of my plugins: Bytecode Outline and Data Hierarchy.

Highlights:

• Bytecode Outline learned invokedynamic (JSR 292)
• and Data Hierarchy can show data for the base classes too.

Here is a screenshot which may explain Data Hierarchy better then words (check the "UnreadFields" class node). You see here the data hierarchy of the AnalysisContext class:

Clearly, with the success of iPhone and Blackberry and the buzz around Android and Pre, mobile already has its killer apps. But for someone new like me to this arena, I find it important that I try to understand what that app is and simplify the category so I can know where to focus what little time I have to play here. So this is what I've come up with, and I hope you have an opinion you can share in the comments to help guide me.

Here we go. I actually think there are two killer apps happening in the smartphone market today. (I'll leave out the *book platforms for another post as that's starting to gel in my mind as well). Start by looking at the iPhone, including the iPod Touch. It's really Entertainment apps that have made the iPhone one of the most popular mobile platforms of our time. My son has a Touch. He has his mp3's there, he watches YouTube videos there, he plays games on it. It's probably what the PSP should have been if it had downloadable content. The platform pretty much comes with good multimedia apps, so if you want to make a hit, writing a good game is the place to start. And looking at most of the other platforms, especially the ones with 3D hardware acceleration, this is true across the board. Actually, you look at the real big picture, good games are popular on all computing platforms, even Spacewar! on the PDP-1.

The other killer app is something a we talk lot about in the Eclipse community, especially my enterprise brethren. And that is thin web client apps. This is most obvious on the Blackberries that almost all business managers have today. Accessing e-mail from an exchange server on a small screen requires specialized software to ensure a good user experience. But I really think it goes beyond just e-mail. There are a lot of web services available in web browsers today. But web browsing on the small screen still sucks and likely will always suck. Writing a thin client that can present information from the web in a format suitable for the form factor is a real winner. The top Android apps I use are clients for gmail, twitter, and RSS. I'd love a good app that lets me write this blog, but I haven't found one yet. But I know the Google provides the API to do it and Twitter has a good API. Wrap those together and you got a customer. Or maybe I should be the developer ;).

Of course, now I'm torn. I've always dreamed of making games, but never had the opportunity to do it. I know it's a lot of work and probably something I couldn't do well in my spare time. I'm also pumped by the "mash-up" possibilities writing thin clients for internet apps. And that's probably something I can do more quickly. Lots of fun. And a reason why I think the industry is going through a reinvigoration. Where the killer app for the desktop has come and the shine has gone (that killer app was office apps, browsers, IDEs, and games by the way). There's an opportunity to get in on the ground floor of the new generation.

Update: Added 4th assumption, Saturday, June 27

As promised, 48 hours ago I downloaded several Eclipse products across all five published platforms using Bittorrent. Now that two days have passed, and my downloads have been made available for others to upload, I thought I'd consolidate upload bittorrent upload data for the sake of gauging popularity.

Some notes on my bittorrent process:

• I downloaded the torrent files at about 10:30pm, two nights ago. I collected the data at about 11:30pm tonight. I'm calling it 48 hours. Anyone who cares enough, call the data police.
  
• I did nothing to cap bandwidth for any of these Eclipse distributions.

• More popular products will be uploaded by more people.
• Upload ratios are a better measurement of popularity than megabytes uploaded. If product X is 50% larger than the size of product Y, equal bandwidth dedicated X and Y do not denote equal popularity. I just think people using bittorrent aren't really worried about the size of their Eclipse.
• Similarly, I consider negligible any difference in compression ratios between the win32 zip file format and other gzipped tar files.
  
• 48 hours of data collection is more than enough time to collect data, and taking more than the first 48-hours of data will not yield significantly different results.
• I presume that files that are not as well seeded as others will take more time to initially download, and as such, will not contribute much to the other uploads during the first part of this process, and so may exaggerate the results slightly. Given that, I suspect the correctness of the 48-hour window will be the most disputed assumption.
• Update: fourth assumption: People don't care about how long it takes, if they're using bittorrent. I assume it's a "set and forget" type of tool.

• RCP is more popular among the OSX and Linux communities than Win32.
• Without JEE, Win32 is not nearly as popular a platform.
  
• CDT and modeling are not particularly popular among the OSX community.
• CDT is loved by the Linux users.
  

Total Uploads: 145
Total MB uploaded: 18,781.1 MB
Upload average (assuming 48 hours): 111.295 kbps

When 40% of all the commercial projects are failing due to one or the other reasons, the technique and style of the eclipse developers have successfully delivered one more annual release of Eclipse Galileo. This is one of the modern wonders. Nothing more than a set of 'strong minds' are required for this kind of achievement.

Any great idea can be spoiled by a careless mind. The same way, any small idea can be turned to a master piece by a great mind. The story of two magicians which wouldn't bring much excitement, when it got into the hands of a director like Christopher Nolan; it turned out to be one of my favourite movie and greatest hits. If you haven't watched the movie 'The Prestige', I urge you to watch it as soon as possible.

The enthusiasm and vibrancy of the hundreds of minds in the Eclipse community, the electric current generated by their thoughts; these are still attracting lot of new people to the community. Framework projects, RnD projects, graphical projecs, modelling projects, bio projects ....

There were many arguments last year. The complexity of some of the frameworks, the simplicity of some of the tools; the anger towards some of the eclipse processes; the sadness when the expected features had to be dropped out of the final delivery, the happiness when the customer/end user said '"See this new feature, Wow'".

Lot of emotions and lot of memories. The emotions which starts in the brain of a single person, when backed by the support of a highly motivated community results in successes similar to what happens in our Eclipse community.

Open source is not a charity always. Hundreds of businesses are thriving upon the open source model. When one of the basic values of humans is followed, ie, 'give and then take'; it results in success and content feeling. When we are following our values, when we are backed by a community with the same set of values, we are at our best.

Many team members were flexing their brain muscles for a long time. Then one of them said on 24th of June, "Guys, we are done for the year"; Its time to relax and celebrate now. Some celebrate the success over a cup of coffee, some over the dance floor and some with a vacation trip.

Life goes on; Eclipse goes on; Next year e4 is one of the most anticipated outputs from the community.

I dedicate this blog to all those gurus who developed the basic eclipse framework and donated it to the open source community; to those who still develop new frameworks in the open source; You people dared to go to the wild, never knowing the dangers behind the hidden rocks and trees, you cleared the path for the rest of us.

I like to convey my gratitude to the hardwork of the hundreds of developers who has worked towards the success of galileo, "Dudes, you all have done a great job. You guys are making our jobs easier".

How can this kind of success be repeated in the high percentage of failing commericial projects?

You need to think out of the bondaries of your organizations, you need to come out of your conventional thoughts, you need to use your brain for what it is designed. "Share" and put some thought behind it, you will start to get the returns. As Robert C Martin says, don't sprint, run the marathon. When your muscles get tired and gets deprived of energy, its your mind which needs to give strength. If the mind losses focus, then the body will fail, our actions become meaningless and the projects fail.

Focus on what you need to achieve. Put your mind and body for it. The results will follow. Its all a mind game. You are a reflection of your mind!

madhu

Not to be left behind in the buzz surrounding Twitter, the Submissions System now tweets when a new talk is proposed. There are already three talks proposed on the Summit twitter page, new follower are always welcome.

Not planning on presenting a talk at Eclipse Summit but still want to try out the tweets? Then cruise on over to the demo conference and propose a new talk. The demo conference exists just to try out new features. The Demo conference twitter page already has one follower (not sure how that happend).

Nice article on how to pass a JDBC resultset to a report at

Techie.Ocean

I’m pleased to announce the come-back of VE in Eclipse stream after more than two years’ sleeping. Now the builds for eclipse 3.4 and 3.5 are available here:
http://www.eclipse.org/vep/downloads/

The VE home page gets updated as well.

I’d like to thank Nick Boldt who had done an excellent job to re-integrate VE into eclipse build system and update the Web page.

Now, it is time to consider new features and the development plan for the next release 1.5. Please use ve-dev@eclipse.org to send us your feedback and requests.

… as being the smoothest release I have ever participated in, despite the major constraint I had this year:  no extra bandwidth shall be purchased.

Here is how we pulled this off:

1. More bandwidth. Since we got sooo many new Friends of Eclipse, I bent the rules and added 12 megabits of bandwidth [1]. But — get this — for the pre-release only.  Marker (1) shows the increase, and marker (2) shows a significant drop three hours into the release.  Unheard of!

2. Early access. Friends of Eclipse, mirror sites and Member companies all had early access to the bits, relieving some of the stress on release day.

3. BitTorrent. In April, I didn’t have options (4) and (5) below, so with the no-extra-bandwidth rule, I had to set up something.  Actually, I suspect many Friends took advantage of their benefits by downloading and pre-seeding many of the files before release day.  More seeds == faster downloads.

4. Eclipse Member companies. They provided lots of bandwidth (and still are!) via the Get It Faster section of the download page.  Many thanks!

5. Amazon Web Services. This was a last-minute deal that was/is a true blessing, since I was able to redirect lots of the download.eclipse.org requests to AWS instead of our stressed mirror sites.

6. Server virtualization. Our own version of ‘the Cloud on demand’ — I enabled an extra virtual server node for www.eclipse.org on June 23 to handle the extra CPU power that would be required to handle the many requests.  I may just shut it off later next week, or I may just keep it around…

I think we’re getting good at these annual release trains..