In the RAP framework, the widgets in a website are remotely controlled by the web server. The server does this by sending messages to the client in response to Ajax requests. Until now, those messages used to contain proprietary JavaScript that has been evaluated by the browser. Apart from the drawbacks of using eval to process server responses, this tightly couples RAP to its default browser client. The messages were so specific that only this client could understand them.

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…

Tags: eclipse, juno, new and noteworthy, protocol, rap

There have been a discussion about build naming conventions lately.  SNAPSHOTS, nightly, milestone, GA, maintenance, integration, stable, etc…

In both Nick’s and Mickael’s posts, I noticed a theme: all builds are the same. Of course when they are built, or the process by which the built artifacts are vetted may change, but the build process is the same for all build types: namely, take what’s in HEAD/Master/Trunk/Tip/Top/Main Branch, tag it and build it.

This isn’t the case for the Eclipse project. The Nightly builds are actually done differently from the integration, milestone, stable, and maintenance builds.

The build processes that Nick and Michael mentioned, assume that once something is in Master/Head, it’s ready to be released and the only other variable is release date.  The Eclipse process doesn’t assume this.  In fact, I can release a wad of changes the night before Juno ships and likely none of them will be in build.  This is because Eclipse requires explicit tagging of what you want built.

Here is how it works:

1. Development teams continually release stuff to master.  Each night master is built to ensure that nobody has introduced compile errors (or broke unit tests). This is not bleeding edge! This is not intended for anyone.  This is not similar to maven SNAPSHOTS.
2. When teams are happy with their work, they tag the bundle.
3. Integration builds happen weekly, and only what’s tagged will be built. Integration builds are similar to SNAPSHOTS, and can be consumed (if you want the most bleeding edge stuff).
4. This has recently changed, so instead of tagging each week, we merge (from master into ‘integration’). This means, what’s in master won’t necessarily be in a build each week.

I’m pretty sure I can hear the GitClub screaming feature branch, feature branch, feature branch. Why don’t you just use feature branches?

Please keep in mind:

1. Eclipse is over 10 years old, and predates Git.  Would you really do feature branches with CVS? (maybe)
2. The Eclipse build takes a while to complete:

• Let’s assume it takes 6 hours to build and run the tests (1/4 of a day).
• Let’s assume there are 10 teams (SWT, Debug, Workbench, PDE, JDT, UA, etc…)
• Let’s assume each team has 2 features on the go at all times: 20 feature branches
• Right now (for better or worse) a full Eclipse build, plus platform tests must run on the Eclipse build infrastructure
• So, if we had 20 feature branches that we had to build in sequence, it would take 5 days to build todays nightly
• Tomorrow’s nightly would start once that’s done!

Yes I realize some of those assumptions might be rather simplifying — maybe we could run the builds in parallel and off-load the costs to the hardware, but having a central build of 20 feature branches is still not feasible.  Also, some teams would likely want to combined builds (now build the SWT + Workbench feature branch together).

I know some people will head down the path of build restructuring (completely refactor the Eclipse build so developers can run them locally, thus removing the necessity for a centralized builds). We’ve heard this before many times.  Instead of suggesting this, sponsoring the effort (with money + people power) would be more helpful.  Also remember that Eclipse has successfully shipped on-time for the pat 10 years.  So, if you really want the team to change their process to the development flavour of the week, be prepared to show some evidence that process XYZ is better.

This was not meant to start a development war, but rather explain a bit about how the Eclipse build process works.  For better or worse, it’s what we have.

BTW, what do others do? Does everyone use feature branches and assume what’s in Master is ready? What did you do before Git (did you use branches for development in CVS/SVN)?

Happy Holiday’s Everyone!

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.

Eclipse Indigo is out and Eclipse Juno development is in full swing. That means it’s time to start thinking about the Eclipse release in 2013 (Only 18 months away). While development plans are still a far ways off, we’ve already started to collect ideas for the name.

Historically Eclipse has chosen names in Alphabetical order (Helios, Indigo, Juno), which brings us to the letter ‘K’. Since some alphabets don’t have the letter ‘C’, we could explore names like Kanada or Kookie Monster.

Of course, we can also go with villains from Star Trek like Klingon or Khan

I’m sure you’ll be much more creative than me.  If you’re interested in following this discussion, feel free to CC yourself on this bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=365965

Does TDD actually improve software quality?  Are good software developers an order of magnitude better than poor ones?  Do multiple code reviews reduce the number of bugs in the software?  Does your choice of language improve productivity? Do distributed version control systems increase the number of contributions?

Many software developers (myself included) have strong beliefs about many of these questions.  In fact, order a round of beers at EclipseCon and bring up any one of these topics and see what happens. Unfortunately, many of us base our arguments on our own experiences or anecdotes.  Occasionally we will quote some self proclaimed expert in the field and assume our argument is ‘proven’.  Is this evidence?

As tool developers — building the Best Integrated Development Environment — we need to hold ourselves to higher standards. We cannot be designing future IDEs based solely on what works well for me. If you have a few minutes, please watch the following video by Greg Wilson on Software Carpentry: Software Engineering Empirical Results. http://software-carpentry.org/4_0/softeng/ebse. I had the good fortune of meeting Greg a few years ago through the Canadian Consortium for Software Engineering. A much longer version of the talk is available (embedded below): http://vimeo.com/9270320.

Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True from CUSEC on Vimeo.

I prefer the longer one as I think he makes a much stronger point about questioning beliefs.

This has been blogged about before by me and other guys, but as I still constantly experience this problem, a little repetition won’t hurt

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.

We had a great Democamp and birthday party in Munich. Thanks go to all the speakers, volunteers and attendees!

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!

Eclipse has two annual conferences, EclipseCon (North America) and EclipseCon Europe. These are great venues to learn about what’s happening in the Eclipse eco-system, explore up-and-coming technologies and get to know the wonderful people behind Eclipse.

If you’re wondering how a ‘simple IDE‘ can fill two annual conferences, please read on!

EclipseCon Europe had a number of tracks, including talks related to modelling, Java 7, and Machine-to-Machine compatibility (yes, Eclipse has technology in all those spaces).  EclipseCon Europe also hosted the Eclipse 10th Birthday party!

I attended the conference.  Unfortunately, there were too many interesting talks and I missed many of the ones I really wanted to see.  Luckily the talks are now on-line at http://www.fosslc.org/drupal/category/event/ece2011 (if you can’t find your talk, wait a few days… they seem to be uploading them as I type this).  By having the talks available, I was able to attend the conference, meet with all the interesting people and still find time to absorb the technical details. This is a great service, thanks!

I should also point out that the deadline for talk submissions to EclipseCon (North America) is Friday November 18th.

With this effective Mockito Post I want to share a really simple pattern with you. We call this pattern “check answers” and we use it whenever we work with Mockito Answers. The code resulting from creating Mockito Answers generally looks ugly. But, as good programmers we care about test quality, right?

Let’s see how we can make better looking answers using the “check answer” pattern. Mockito’s Answers are great when you need to verify that a method was called with specific parameters, or you need to execute an operation that also needs to be mocked. I’m sure you have seen situations where Answers were very useful. Let’s dive into a simple example. Our fancy program consists of three classes which are listed in the snippet below.

public class MyRuntimeState {
 
  private boolean state;
 
  public void setState( boolean state ) {
    this.state = state;
  }
 
  public boolean isTrue() {
    return state;
  }
 
}
 
 
public class MyDelegate {
 
  public void doSomething( MyRuntimeState state ) {
    // do some fancy operation
  }
 
}
 
 
public class MyObject {
 
  private final MyDelegate delegate;
 
  public MyObject( MyDelegate delegate ) {
    this.delegate = delegate;
  }
 
  public void operate() {
    MyRuntimeState state = new MyRuntimeState();
    state.setState( true ); // this is the important fact we want to test
    delegate.doSomething( state );
  }
 
}

As you can see we have the Types MyObject, MyDelegate and MyRuntimeState. MyObject needs a MyDelegate in its constructor. In the operate method, MyObject calls MyDelegate‘s doSomething method with a newly created MyRuntimeState object. Let’s assume that for some reason our fake system needs a MyRuntimeState with the state ‘true‘ to work (be creative – it’s just an example ).  So, MyObject needs to set the state of the MyRuntimeState object to true. This is exactly the case where Answers are useful to verify that the state is true within the doSomething invocation (we can probably also do this with verify in this example, but there are harder operations out there where verify can’t be used).  Let’s look at the test for this mechanism.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectTest {
 
  @Mock
  private MyDelegate delegate;
  private MyObject myObject;
 
  @Before
  public void setup() {
    myObject = new MyObject( delegate );
  }
 
  @Test
  public void testSendsRightState() {
    doAnswer( new Answer<Object>() {
 
      @Override
      public Object answer( InvocationOnMock invocation ) throws Throwable {
        MyRuntimeState state = ( MyRuntimeState )invocation.getArguments()[ 0 ];
        assertTrue( state.isTrue() );
 
        return null;
      }
    } ).when( delegate ).doSomething( any( MyRuntimeState.class ) );
 
 
    myObject.operate();
  }
 
}

You see that it’s a fully working test that tests exactly what we want, but it’s also a smell. I dislike several things in the testSendsRightState method. The first thing is the method chaining over several lines. The second thing is that we have an indentation level of three which leads to unreadable code. The third thing is that we can’t see at a glance what will be tested. The fourth thing I don’t like is that the assert statement comes before the actual operate call at least in the writing of the code. The last thing is that this method is way too long.

Let’s try to get rid of most of the smells by simply doing one refactoring. You may say that this is obvious, and yes it is;). We need to extract the creation of the Answer object into a separate method. I name these methods createCheck***Answer (*** stands for a named check) because the answers that will be created are invoking the actual asserts. The result can look like this:

@Test
public void testSendsRightState() {
  Answer<Object> checkStateAnswer = createCheckStateAnswer();
  doAnswer( checkStateAnswer ).when( delegate ).doSomething( any( MyRuntimeState.class ) );
 
  myObject.operate();
}
 
private Answer<Object> createCheckStateAnswer() {
  return new Answer<Object>() {
 
    @Override
    public Object answer( InvocationOnMock invocation ) throws Throwable {
      MyRuntimeState state = ( MyRuntimeState )invocation.getArguments()[ 0 ];
      assertTrue( state.isTrue() );
 
      return null;
    }
  };
}

This simple refactoring has a huge impact on our test method. The test method has only a length of three lines of code now. The indentation level is one. The call chain fits into one line. Even the createCheckStateAnswer is more readable because it’s not surrounded by chained calls. One drawback still resists this solution. That is, that the assert is now called within another method. To me, this is a very low price to pay compared to the problems in the first test. And, the best thing about this solution is that when you only read the test method you see at first glance that an answer called checkStateAnswer was created that obviously does something like check a state. Other programmers should be able to understand most of the test method without reading the createCheckStateAnswer method.

I know that this solution is very simple and for you, may be obvious. But when I started with Answers I didn’t do this for reasons only the Programming Gods know now. If you have any other things related to Answers in your repertoire please share them with us in a comment.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4

Tags: junit, Mocking, Mockito, Software craftsmanship, testing

Consider this:

I measured the time needed to create 200 Buttons in RAP 1.4 and RAP 1.5M3, and it shows a considerable performance boost (at least for the browsers i tested). One reason for this is that we changed from quirksmode to standard rendering in IE9, which among other things, finally allowes us to use its new HTML5-features (in this case SVG and CSS3). I expect another little boost with IE10, which has even more CSS3 support.

However, what i did not expect was a significant improvement in any other browser, in this case Google Chrome. This is likely due to the implementation of the JSON-based RAP-protocol. It remains to be seen how this develops, as work on the protocol is still going on. Currently eval() is used to parse the JSON. In the final release we will probably use other methods, such as the native JSON-parser present in many modern browser. Older browser may gain only little or no performance.

What is really awesome though is the improvment of the GC/SWT-Canvas performance in IE9 (and only IE9). Drawing in browser (without any plug-ins) used to be a real pain. While other browser adopted the HTML5-Canvas and SVG standard very early on, Microsoft stubbornly stuck to its horribly old VML implementation, making my work needlessly hard. One of the main problems with VML is that it gets exponentially slower the more elements you draw, from about 200 elements on it’s almost painful to watch. But this is 2011, HTML5 is all the buzz, and even MS could no longer ignore it. IE9 now has a decent HTML5-Canvas implementation that we use in RAP 1.5, and it shows:

The fine print:
These results were achieved on my Windows 7/64bit Intel i5 2,4 GHZ laptop. No other systems or browser were tested. Measurement was done using JavaScript. The 32bit version of IE9 was used. I did only 3 iterations each, but the deviance was relatively small. The results in the final RAP 1.5 release my be very different due to ongoing development. You can check out the code i used here.

Tags: canvas, CSS3, html5, IE9, Internet Explorer, rap