As you may have heard, we launched RAP mobile two days ago. And, we did just that. With RAP mobile you can access exactly the same dataset with exactly the same code as in Ralf’s post. The dataset contains over 500,000 emails totaling over 2GB of space. Check out the screencast below and the source code on github.

What I find intriguing about this framework is that it is fast. There is no data on the phone. The information displayed in the UI is retrieved asynchronously from the server while the user is scrolling through this enormous set of data. The native iOS client takes care of the proper preloading, caching and memory management.

Some of the most common problems involved in mobile development include dealing with multi-platform, security and maturity of the available platforms. But does multi-platform really matter with iOS breaking adoption records? I am sure that Google and Microsoft believe that their platforms will become breakthrough successes as well. While no one can make a definitive statement about their future success, I don’t think that anyone would bet a fortune on their failure either. This leaves us with three options for addressing multi-platform: HTML5, development for each platform or making a bet on which will be the most successful.

HTML5 is great technology – not only for mobile – but there is a growing body of lessons learned the hard way. Our own experience revealed that it is easy to get started with HTML5 and that the state-of-the-art JavaScript libraries look really great. But when it comes to running and using the apps the excitement mostly turned into disillusion. The other two options did not seem like good solutions for us, so we decided to add another option: RAP mobile.

RAP mobile gives us some key advantages over the alternatives. First, it allows multi-platform development in Java. It uses the iOS and Android native widget toolkits for rendering the user interface with optimal performance and native look and feel. And, it provides a mature and Open Source platform for writing and deploying business applications on standard JEE servers. It also provides a solution for common data security concerns with mobile devices.

Today we launched the RAP mobile developer preview program and the RAP mobile project site. If you are curious about how RAP mobile works and what it has to offer visit http://rapmobile.eclipsesource.com.

As I hope everyone is aware, Juno (Coming Summer 2012) is an important release for Eclipse. It represents the transition from an Eclipse 3.x platform to 4.x.  If you plan on shipping products based on Eclipse Juno, make sure you start testing NOW!  This milestone has a number of noteworthy items including:

A great deal of static analysis checks
Null field checks

And more resource leak detection:

There are also some notable UI improvements such as editor navigation arrows:

Checkout the entire New and Noteworthy:
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M5-201201271145/eclipse-news-M5.html

Or better yet, download the milestone and TEST YOUR PLUGINS!
http://download.eclipse.org/eclipse/downloads/drops4/S-4.2M5-201201271145/index.php

While some teams are actively working on their components, other components are very mature and simply need some TLC from time-to-time.  There is certainly a number of things we could do with p2, but for the most part it works very well.  Pascal has been donating much of his personal time to p2 in order to give it the TLC and polish it needs. Pascal is pretty smart and 10 minutes of his time equates to an hour for most people .  However, it’s not fair that he spends all his free time tracking down problems in order for p2 to makes its contribution to the SDK.

I’m happy to say that I’ll be helping Pascal co-lead the p2 project.  There’s a few things I have planned including

1. Fixing a few recent problems on Java 7 Runtimes
2. Improving the performance of the UI
3. Looking at how we can reduce the size of our metadata (content.jar)

I’ll also be presenting some p2 related work at EclipseCon.  If you have questions, I try to hang around IRC and I’m also on twitter (@irbull).

A while ago, we’ve tried to use JSLint, a tool written by JavaScript guru Douglas Crockford. Unfortunately, this tools produces several thousand warnings on our code base, many of them were not really problems but debatable coding style issues and there was no way to turn them off. JSLint’s lack of customizability recently lead to a fork named JSHint that is going to provide more flexible configuration options.

Like JSLint, JSHint is written in JavaScript, but can be run on the command line using tools like Rhino or JavaScriptCore. I tried JSHint on our codebase with good results using a shell script that runs it on top of Rhino. Unfortunately, checking all our 250+ *.js files keeps my machine busy for 5 minutes and 40 seconds and effectively turns it into a fan heater. This is not because JSHint itself is so demanding, but because for every file, a JVM has to be started, Rhino has to be loaded, then Rhino has to parse and load the JSHint JavaScript library, and then finally, jshint can parse and validate the source file.

Encouraged by the good results I tried to find a solution that doesn’t have this overhead. And as an Eclipse hacker and user, I certainly wanted to integrate the tool into my daily working environment. The result is a simple, yet efficient JSHint Eclipse integration that validates the same bunch of *.js files in less than 15 seconds.

This speedup could be achieved by exploiting the way Eclipse builds projects: It uses the same builder instance to visit all files of the project recursively. That makes it possible to load and configure the JSHint library only once for the entire project and reuse it for all files being checked. Of course, validating all files of a project is only necessary for a full rebuild. During normal work, single files are being validated instantly when they have changed.

Although the configuration options are still somewhat basic, this integration proved to be very helpful already. I thought that it may be useful for others as well and decided to build and publish a first version. It’s available on the jshint-eclipse page. There’s an update site that let’s you install the plug-in right into your Eclipse IDE. If you find the plug-in useful, have ideas for improvements, find a problem or want to contribute, I’m happy to hear about it. To report problems, please use the github issue tracker.

Why Orion?

Before we can answer this, let’s look back 10 years.  A decade ago Eclipse had just shipped 1.0.  While many people saw Eclipse as a great Java IDE (which it is), Eclipse was also a universal tool platform.  Eventually Eclipse became a platform for Everything and Nothing In Particular, but in December 2001 it was a general purpose platform for development environments with Java Development as one such exemplary tool (C/C++ development was added shortly afterwards).  Many people attributed the success and quality of Eclipse to the fact that the developers used Eclipse for their day-to-day work, a concept known as eating your own dogfood. This model ensured that the quality of Eclipse remained high since any regressions would immediately be seen.

Fast-forward 10 years and we are starting to see many software tools moving to the web. Services such as GitHub, CloudBees, Cloudant, YouTrack, etc… reduce your IT overhead by moving many of your tools to 3rd party service providers, accessible via the web. Also, many of our applications are exposing web-based front ends and developers are relying on tools such as FireBug and other browser extensions.  Since most ‘coding’ still takes place on the desktop using tools like Eclipse or TextPad, developers are no longer using the tools they develop.

Eclipse Orion intends to change this.  Eclipse Orion is positioning itself as a Tooling Platform for the Web, on the Web.  If you’re currently building Web-Based software, then Orion will be of interest to you.

Is Orion Replacing Eclipse?

The aim of Orion is not to replace Eclipse.  Orion provides another tooling platform — this time for the web.  Not everyone is doing web development and not everyone wants their tools on the web.  However, if you are spending more of your time in a browser, Orion might be of interest.

Also, Orion is an entirely new code-base. This is not Eclipse running in a browser.

Getting Started

The easiest way to get started with Orion is to look at OrionHub.  OrionHub (http://orionhub.org) is a public beta server of Orion.  Anyone can request an account, but keep in mind that the workspaces are cleaned occasionally so there is no  guarantee that your data will be persisted.

1. Request an Account

Go to http://eclipse.org/orion to request an account.

2. Login to OrionHub

Go to http://orionhub.org and login. Once you’ve logged in, you can access you profile and associate other accounts if you wish.

3. Create your first project

There are a few helpful links across the top of the page. To create you first project, select the navigator and choose New Folder. You can also clone a project from a remote git repository if you choose.

4. Upload an existing project

Initializr allows you to create a bare-bones HTML 5 site, and download it as a zip file. This means you can get started on a new fancy web project without all the boilerplate setup.  I decided to download a bare-bone site from JavaScript InfoVis Toolkit for my example since I was interested in creating a graph based visualization. Using Orion, you can upload this zip file and start working immediately.

This this is on the web, you can review my code as I work:

http://orionhub.org/edit/edit.html#/file/ST/Jit/Examples/ForceDirected/example1.html

5. Launch a site

To test / debug your web application as you develop it, Orion allows you to launch a site containing the newly developed project. You can develop in one browser tab, and test (and debug) in another one. This paradigm means that all your tools are in one place.  To launch a site, choose the ‘Sites‘ link and Create Site.

You can map your project to this site.  In my case, I created a site called irbullvisualization. Feel free to access it at:
http://irbullvisualization.orionhub.org:8080/Jit/Examples/ForceDirected/example1.html

6. Share your project

By default, a Git repository is created for all projects on OrionHub.  Of course, this is just a local git repository (local to OrionHub), but you can easily add new remote references and push your projects around. You can commit changes using the Git Status Page:

And push your changes to remote hosts using the Repositories View:

Conclusion

The Eclipse Orion project is still in its infancy. Unlike the Eclipse project — which was opened sourced at the same time as its 1.0 release, the Orion project is still in its pre 1.0 stage. However, you can get involved with the project, tryout the beta at OrionHub.org or download your own Orion Server.

In my next article I’ll talk about Orion Plug-ins.

One of our goals for RAP 1.5 is to open the framework for alternative client implementations. After all, the messages from the server contain precise rendering commands that are not at all specific to JavaScript. Commands like “create a button with text ‘Ok‘, set its size to 190x25px, and place it at pos (23,42)” or “change the text color of the label with id ‘w47‘ to ‘#ff0000‘” can be rendered by any client that is able to create and manipulate widgets. It doesn’t have to be a JavaScript client, also clients written in other languages like Java or Objective C can implement it. Clients can render widgets with any UI technology, be it SVG or even a mobile device’s native widget set.

To allow for those cases, we exchanged the communication format with a simple predefined format based on JSON. With the M4 build published today, all responses from a RAP server are now plain JSON. This also makes the debugging much easier, since developer tools like Firebug display the structure of a message.

When designing the protocol, we took great care not to limit the exchange format to widgets. Instead, we created a generic synchronization protocol for any kind of objects. Objects are identified with a unique id, and every operation is related to a target object that is referenced by its unique id. There are different types of operations: one to create an object, one to destroy it, one to change some properties on an object, etc. Every message from the server contains a list of operations, besides some meta information.

You’ve guessed that we already have some prototypes for alternative RAP clients in progress. We’ll write about them soon…

As many of us start to get into the Holiday spirit, the Eclipse and Equinox teams have an early gift for you, Eclipse Juno Milestone 4.

Eclipse now supports Annotation based Null Analysis. (See Deepak and Ayushman’s posts for more information).

There are also enhancements to SWT (Tree Cursor)

And Equinox now supports Jetty 8 and Servlet 3.0

Checkout the  completely New and Noteworthy

or Download the Milestone and try it out yourself.

In many projects you see the result of System.out.println() statements on the console: statements such as “here I am” or “this should not happen”. These are often left-overs from debugging sessions and flood the log. Although, I personally think there are almost no use cases where you would use sysouts over breakpoints or conditional breakpoints, you cannot just forbid the use of them. In fact, there are good use cases I know for sysouts, e.g. debugging drag and drop where you do not want the debugger to suspend on a drag over. However, polluting the code with sysouts should be a no go. A better solution is to put the sysout statement into the break point’s condition like this:

In this way you do not pollute the code and, if you want to persist your sysouts, you can export the breakpoints.

The evening started with a keynote by Ed Merks. He summarized 10 very interesting years. Some of the events he mentioned were already known, some were surprising, e.g. when Ian Bull started to use EMF in 2003

The second speaker, Kai Toedter showed a real working demo of how to use Java web start to start an Eclipse RCP application. To make it even more interesting, he started his demo application using the internet connection from Sven`s phone. You can download his slides here.

Manuel Bork presented the new Mylyn-GMF integration that allows the use of task focus on diagrams. This feature is also integrated into UML Lab.

Frank Appel showed how to create dynamic Web-Applications with RAP and OSGi. It was quite impressive to see him turning parts of a web application on and off using an OSGi console. At the end, he also demonstrated the same application running on an iPhone using the native RAP client for iOS. You can find his slides here.

Maximilian Koegel and me did a short “KINECT with Eclipse” demonstration.  If you’re not familiar with this demo, you can see more here.

Then we had a short break with beer and of course a birthday cake. It must have been good -  I wasn’t even able to take a picture of the whole cake:-)

After the break, Andre presented the tool, Ceno. It can help to avoid conflicts in projects by showing who is working on which class in real-time. You can download his slides here.

Tom Schindl presented his project “e(fx)clipse” Eclipse Tooling and Runtime for JavaFX. The styling options and the DSL to declarativly create the UI were especially great. You can find his slides here.

Ekke presented his first experiences with Eclipse PlugIns for BBX Native SDK. This enables the development of applications for the next generation platform for Blackberry smartphones and tablets.

Maximilian presented what’s new in EMFStore. He showed an example of a tool based on EMFStore and also showed an integration of EMFStore with the e4 workbench model. With this integration, the e4 model can be versioned between developers using EMFStore. The changes can even be pushed to a deployed application. As an example, one can switch off a certain feature for maintenance. See here for more information.

Sven Efftinge gave an introduction to Xtend and why it can and should be used daily. Xtend is a very thin layer above Java offering some innovations such as closures, which are not available in Java. Later, Sven also showed how to develop a very simple DSL with Xtext in 10 minutes. You can find more information here.

Ed presented Xcore, a textual syntax for Ecore created with Xtext. Xcore allows the definition of EMF models with the same ease as writing Java code. It also makes it very easy to embed Operations written in Java.

Thomas Schütz presented “Developing Embedded Systems with eTrice.” To me, the most interesting feature was that events on the target can be logged to create Message Sequence Charts(MSC) of the running application. You can find his slides here.

Thanks to all the speakers, the attendees and the volunteers for making this a great event and see you at the next democamp!