I attended NetBeans Day yesterday, which started with a presentation on Looking Glass. Of course, Looking Glass has nothing to do with NetBeans and it was merely a way for Sun to showcase their technology, even though Hideya did mention NetBeans for twenty seconds at the beginning of his presentation (“we use NetBeans for development”).

Looking Glass looks as good now as it did one year ago, and just as useless. I thought by now we had established that 3D desktops are very hard to use on a 2D screen, but it’s a lesson Sun just doesn’t seem to want to learn. What really worries me is that I didn’t even see anything new compared to last year, but the most troubling part was that even the demo person was sometimes confused during the show, picking the wrong titlebar or looking for his own windows.

Don’t get me wrong: Looking Glass is a good technology and I hope Sun keeps working on it, but please don’t try to sell it as the Next Big Thing in desktops and usability, because it’s neither of these.

Rick Ross was next, and after his usual diatribe on how big JavaLobby (the name, not just the Web site) is, he proceeded on giving his usual presentation on communities and how important IDE’s are.

Next came Jonathan Schwartz, unshaved and unprepared, but winging it with ease. I am a bit tired of his propaganda spiel but I have to give him credit: he always looks and sounds good on stage, so it’s always entertaining to listen to him as long as you can wade through the Sun party line hammering.

And finally, the NetBeans demo started.

The first twenty minutes were spent demonstrating the editor, with features such as “turning all words to uppercase and back to lower case with just three keys” and “extracting a method” or “splitting an editor”. The entire demo was just a painful rehash of every single feature that every IDE (or even text editors) on the planet already has.

If you are trying to win over an entire crowd devoted to Eclipse and IDEA (which was pretty much the case based on the various questions and conversations around me as the NetBeans demo was unfolding), you need to do better than “we do the same as the competition”. You need to show what you do different and what you do better. And of course, emphasize what you do that nobody else does (more on this below).

You also need to show how using the IDE on a daily basis feels: how do you navigate through your sources? Through your projects? How do you locate a class? How fast do you solve compilation errors? How the windows and the GUI fits together, etc…

The staging of the demo was also horrible: one person was manipulating and another one was talking. “So now we are going to talk about… [look at the big screen] … [look at coworker, exchange a few hushed words] ah right! Code completion!”. Do you really need to have two people on stage telling each other what to do? And I’ll gloss over the fact that the speaker started the demo by asking how many people read his blog… Seriously. You can’t find a better way to embarrass yourself in public (and a hint to the speaker: check your logs).

Throughout the demo, the presenter was asked quite a few questions by the audience, and most of the time, he would just dismiss them and say “I don’t know, I’m just the presenter, I didn’t develop this thing”. Well, if you can’t answer the questions, you shouldn’t be on stage in the first place and you are guaranteed that it’s a frustrated crowed that will walk out of your presentation, not a wowed one.

Next came a profiler demo (a lot of graphics but no real demonstration of solving a hard problem, and not much that I haven’t seen in OptimizeIt or JProfiler). Followed by… a JXTA demo. Yes, seriously. JXTA. Now there’s a differentiating factor, alright. You can be sure that nobody besides Sun will ever show this.

But the real reason why I was there was for Matisse.

I have worked with GUI builders since the early 90’s (yes, you read that right, circa 1990) and by now, I have a pretty good idea on what makes a good builder.

The demo was unfortunately very mundane: creation of a search dialog in a few clicks and drag and drops. The automatic line up and visual cues are nice, but the demo failed to address the real hard questions, which are:

• What does the generated code look like?. The audience asked several times for this and eventually, the demo person relented. The code looks pretty big but doesn’t seem too bad.
• How tweakable is it? Not surprisingly, the code has big warning comments saying “you shouldn’t modify this or that portion”. There is a very elegant way to generate code and still make it easy for users to add their own logic that won’t be erased by reverse engineering: ask user to instantiate subclasses of the code you generate.
• What is the layout manager? Can it be changed? It’s called NaturalLayoutManager. It’s not part of Swing, it’s a brand new one, and they are talking to the Swing team to have it part of the JDK, which should happen in late 2006.
• Can you reuse your GUI’s ? This is by far the most ignored feature in GUI builders of all times, and the reason why they are so little used in general. Here is the deal: creating a nice GUI is just the beginning. Very often, I create windows with abstract methods and even abstract widgets in them. Then I want to be able to subclass them and alter them slightly (“I want the exact same UI but with a checkbox instead of a text field here”). Sometimes, I also want to build part of my GUI dynamically, and I can’t do that in the builder because I don’t know yet what widgets will be in this area. No builder has ever understood this problem and as a result, I have always ended up writing all my UI’s by hand. You just can’t take OO practices away from developers, they will hate you for that.
• How does code binding and reverse engineering work? No idea on how Matisse works there, there was no demo on callbacks or code insertion.

There are also very important features that still don’t seem to be implemented yet: JUnit plug-in, Subvsersion support and, more importantly, global search. This is a feature I couldn’t do without, and I’m not just talking about text searches through a project, but also Java searches (“all places where this method is overridden”, etc…).

Now I have to say there is at least one thing that I liked in this entire presentation: the collaboration plug-in. With this, you can have one of your coworkers see what you are seeing and even take over your editing or compiling. This is very neat and I hope that Eclipse and IntelliJ will follow suit and implement it as well.

But for all the rest, the demo was a very poor illustration of all the hard work the NetBeans team has been putting into their product this past year. They deserve much better.

By popular demand, TestNG has a new home: 
http://testng.org.

The package will also be renamed to org.testng to reflect this
change and the next version (2.4, due out soon) will include the new naming.

This is beginning to look like the "thread that never ends"…

Robert posted a few additional thoughts that I’d like to comment on:

Cedric, you said you wanted to distinguish between needing to use ‘new’
vs a factory. Why bother? Simply use a factory _all the time_ for your own
objects.

I like factories a lot, but using them all the time is a bit extreme in my
opinion.  Constructors have a lot of shortcomings (name that changes all
the time, can’t use polymorphism, etc…) but they are a fairly convenient
construct and I think banning them from everywhere in your code base except for
a small set of factory methods might be a bit overkill.

BTW, I said that adding numbers to an interface was an admission you made
a mistake – namely, that you forgot something.

That’s a bit harsh.  No matter how much thought you have put into an
interface, you can’t really anticipate all the crazy ways future users will want
to use it for.  I would certainly not call this a mistake, maybe just a
lack of foresight, but it certainly doesn’t reflect badly on the author of the
interface in my eyes.

Another comment about numbered interfaces:

Anybody who first sits down with various COM API’s and encounters all the
different numbered interfaces and has no idea what the difference is between
them can attest to this.

Actually, the numbers serve a very useful purpose:  the higher the
number, the more sophisticated the interface is.  When you are wondering
which one to implement, the numbered interfaces give you a good way to figure
out how much functionalities you want to implement and if the one without a
number is good enough for you, it will also be the one with the least methods,
so the easiest to implement.  When you don’t use numbers, comparing the
richness of interfaces that extend each other is not as obvious.

In another comment, Alex Blewitt made another excellent point:

One advantage that a prefix has over a suffix is nothing to do with
JavaDoc; it allows you to get a list of all interfaces by typing
I+ctrl+space (or whatever your favourite IDE uses).

This made me realize that I use this a lot, along with other conventions that
use prefixes instead of suffixes:

• get/set for getters (obvious).  It makes it
  straightforward to see what properties you can query from an object (type
  get<ctrl-space>).
• A leading underscore (e.g. _name) for fields.

Overall, I feel that if you are using an IDE, conventions that use prefixes
instead of suffixes will make your life easier, but at this point, I’m ready to
concede that it’s really nitpicking.  At least, most of the people who
commented seem to agree on the fact that differentiating interfaces from
concrete classes with syntactic conventions is useful, and the rest is details.

So just pick a convention and stick with it.

My previous post on
interfaces has generated quite a few comments:

I prefer to rely on API versionning than to have I*2 for additional
methods in an interface.

This is the sure way to DLL hell…  Not sure I want to go there.

Anyway as a client to something (not an implementor) I don’t really care
if CoffeyMaker is a class or an interface…

I still find it important to know whether I can "new" a type or if I should
look up a factory to create it.

Some argued that using ‘I’ adds noise. Usage of ‘Impl’ suffix takes care
of this problem too.

I wonder if the author of this remark noticed the irony of this comment 🙂

Adding numbers to an existing interface is a sure sign of bad design.

It’s a bad design that sure seems to work fine for Microsoft and Eclipse, who
have a pretty good track record of producing excellent backward compatibility. 
Maybe there’s something to learn from that?

What happens when you get to I*4 or I*5? Who the hell even knows?

You answered your own question::  you name them 4, 5, etc…

More seriously, I have to say I have rarely seen any interface past the
number 3, which makes me think that the I*2 convention is a stopgap measure for
the first or second generation of your interface, but that after this, the
interface is usually stable enough to be left alone (or new functionalities are
added in interfaces that receive a brand new name).

That is, you don’t start programming to an interface unless you’re
totally sure that the interface is needed.

You know, this made me realize that it’s a pretty good example why the XP
principles are contradictory.  It seems to me that programming to
interfaces makes testing easier, and making testing easy is one of the main
goals of XP, therefore, you should use interfaces as much as possible.  But
then, you are no longer doing the "simplest thing that could possibly work".

Cedric, can you offer your opinion on this w/ regard to Generics?

I would love to but I don’t have one yet 🙂  I need to think about it
more.  But you make a good point: none of these techniques take Generics
into account and I am curious to see how much of what we know on this topic will
have to be revisited.

It appears that Kent Beck has been working in stealth mode on JUnit 4, and if
it wasn’t for a small slip in an interview a couple of months ago, nobody would
know.  It turns out that there already is some new code checked into their
CVS depot and Alexandru and I took a quick look there.

Here is what we found so far:

• Annotations.  As we observed with
  TestNG, annotations let you do away with inheritance of a base class and
  make more sense than trying to cram test information into method names.
   
• The @Test annotation has an expected attribute
  (probably similar to @ExpectedExceptions, but it’s hard to tell at
  this point)=.  I also note they only allow one class to be expected
  while TestNG lets you specify more than one).
   
• There is a new @Ignore annotations, which we decided to specify
  as an attribute of @Test in TestNG (e.g. @Test(enabled = false)).
   
• TestNG’s timeout and invocationCount also seem to be
  planned for JUnit.
   
• Finer grained configuration access.  JUnit only allowed to
  setUp/tearDown around test methods, you can now do this at the suite
  level (TestNG offers even greater flexibility: around classes and around
  groups).
   
• Suites are being deprecated and they are looking for a way to describe
  collections of tests (quite a surprising decision, but may I suggest a file
  called…  I don’t know, junit.xml?).
   
• There will be a converter (I invite the JUnit team to start off with
  com.beust.testng.JUnitConverter and tweak the imports it generates
  :-)).
   
• Run failures first (TestNG generates a testng-failures.xml for
  this).
   
• Quoted from the todo file:  "be able to specify the order of
  tests (ewwww….)".  Now that is very interesting…  They are
  just falling short of specifying test dependencies but as much as I find
  this feature crucial for non-unit testing, I question its use for unit
  testing.
   
• Groups!  Yes, that’s right.  A lot of people criticized the
  need for groups when they were introduced in TestNG a year ago, but we have
  definitely seen users like this feature and use it a lot.  It’s good to
  see JUnit follow the same path.

For more information, Alexandru posted a
more detailed
list of the various features offered by JUnit 4 with his own comments.

A few comments now…

• This is a pretty good start, and I am not surprised to see that
  dependent test methods are not planned for JUnit (this feature probably
  doesn’t belong to a unit-testing framework anyway).
   
• I didn’t notice any new tests, so they are not using Test-Driven
  Development…  makes you wonder, uh?
   
• There is still no separation of static and dynamic models.

  Having test groups is not very useful you can’t specify which groups to
  execute at runtime.  I hope JUnit will provide a less awkward way to
  invoke tests than putting them in a suite() method.  As you
  probably know by now if you are a regular reader of this blog, I still
  firmly believe that I shouldn’t have to recompile Java code if I want to run
  a different set of tests, which is the reason behind the existence of the
  testng.xml file in TestNG.

All in all, this is very exciting but I feel disappointed that no email was
sent to the JUnit mailing-list nor request for feedback posted on any blog: 
the JUnit team seems to have decided to work behind closed doors on this.

The JUnit mailing-list itself has 5800 subscribers (!) and would probably be
an invaluable way for them to get feedback.  I’m not quite sure what is the
driving vision behind JUnit 4 (besides TestNG :-)), but I certainly hope they
will be coming out of stealth mode and discuss it publicly soon.

At any rate, I am quite happy to see that things are finally moving in the
testing area!

Artima just published an excellent interview with Erich Gamma which I strongly recommend to anyone interested in writing software for the long run.  Erich makes a great job at explaining the power of interfaces while reminding that abstract classes can sometimes be useful as well.

There are a few points I’d like to emphasize in this interview:

Since changing interfaces breaks clients you should consider them as immutable once you’ve published them. As a consequence when adding a new method to an interface you have to do so in a separate interface. In Eclipse we take API stability seriously and for this reason you will find so called I*2 interfaces like IMarkerResolution2 or IWorkbenchPart2 in our APIs.

First of all, notice that they are prefixing interfaces with "I" which, if you are a regular reader of this blog, is a convention that I like a lot and use everywhere.  Once you start realizing the importance of interfaces, you want to find a way to read a piece of code and immediately spot whenever a concrete class is being used instead of an interface.  This convention goes a long way toward this goal and in my eyes, a piece of code is completely "pure" if all the type names it uses start with I.

More generally, this technique is a lesson that Java programmers have been very reluctant to learn.  I am not sure where this resistance comes from but it might have something to do with the fact that this conventionn was popularized by Microsoft in the Component Object Model way back in 1995.

With the incredible success of .dll and reusable VB and OCX components, Microsoft quickly learned the importance of making published interfaces immutable, so they enforced this by providing tools to generate unique ID’s (across the planet) for every new COM interface that you define.  Interestingly, Sun started introducing this convention recently, albeit sparingly:  org.xml.sax.ext.EntityResolver and EntityResolver2, java.awt.LayoutManager and LayoutManager2, etc…

What the article doesn’t say is how exactly you can leverage this pattern to actually write reusable code.

It’s actually pretty easy.

Imagine that you wrote a program to make coffee:

public void dispense(ICoffeeMaker coffeeMaker) {

  coffeeMaker.pourBeans();

  coffeeMaker.makeCoffee();

}

At some point, your coffee maker starts supporting pouring milk and since ICoffeeMaker is now immutable, you need to create another immutable interface.  We could call it ICoffeeMaker2 if there was no other suitable name, but IMilkCoffeeMaker is probably better in this case:

public interface IMilkCoffeeMaker extends ICoffeeMaker {

  public void pourMilk();

}

Note:  I initially used the example of decaf coffee for this but it occurred to me that this would be an implementation change, and not an interface modification.  Milk makes more sense because we are adding a functionality that hadn’t been anticipated by the first version of this interface.

Your code now becomes:

public void makeCoffee(ICoffeeMaker coffeeMaker) {

  if (coffeeMaker instanceof IMilkCoffeeMaker) {

    ((IMilkCoffeeMaker) coffeeMaker).pourMilk();

  }

  coffeeMaker.pourBeans();

  coffeeMaker.makeCoffee();

}

As you can see, this is quite straightforward.  And it probably makes you cringe a little…  After all, weren’t you warned over and over again to avoid instanceof as much as possible, and more generally, that your code should not rely on the existence or implementation of subclasses?

This advice still stands, but like all advice, it has exceptions.  And future evolution as illustrated in the snippet above is a high enough reward that you should consider this approach when writing Truly Reusable Code.

This technique is being used in many places in Eclipse, and it’s actually so common that the Eclipse team generalized this principle by creating the IAdaptable class.  It is extremely simple:

public interface IAdaptable {

  /**

  * Returns an object which is an instance of the given class

  * associated with this object. Returns <code>null</code> if

  * no such object can be found.

  *

  * @param adapter the adapter class to look up

  * @return a object castable to the given class, 

  * or <code>null</code> if this object does not

  * have an adapter for the given class

  */

  public Object getAdapter(Class adapter);

}

There is a lot more to say about this interview and I don’t want this post to become too lengthy, so I’ll just wrap up for now by observing that this philosophy is quite at odds with what XP is trying to achieve, which is a nutshell is "Do the simplest thing that can possibly work". 

The XP philosophy is way too extreme for me (hence its name, I suppose) and I have always stayed clear of it as an absolute rule.  The approach explained above gives you a good counterpoint to this philosophy, and armed with these two tools, you will be able to make the right decision on how extensible you want your code to be.

The

interview of the director of engineering for NetBeans has generated a pretty
lengthy discussion.  There is a particular argument used by Sun employees
to bash SWT that I am getting a bit tired of:

Swing, the NetBeans Platform and the NetBeans IDE are 100% pure Java –
you are not being locked in to someone else’s proprietary implementation.

This is nonsense.

Swing is based on AWT, which is not native, and as a matter of fact, there is
a different AWT for every operating system.

What you can say is that SWT relies on more native code than Swing, but
frankly, who cares?

Here are a couple of facts:

• The platforms supported are the same (both Swing and SWT run on Windows,
  various Linux window managers and MacOS, which covers probably close to 100%
  of the desktops out there).
   
• NetBeans still requires you to download a different executable depending
  on your operating system.

And in case you have any doubts, just go to the
NetBeans
Download page and you will see that you are asked which operating system you
use before you can start the download (which is an executable).

On a more personal basis, I think the SWT/JFace approach is not only more
powerful than AWT/Swing, it is also more user-friendly:

• It takes a long time for Swing to adjust to the latest user interface of
  its hosting operating system because every single new widget needs to be
  reimplemented from scratch in Java by Sun.
   
• The support for native integration in Swing is still very primitive. 
  For example, I configured my Windows desktop to support single-click
  operations (I never double click).  When I open a NetBeans file dialog,
  I still find myself having to double click, which is a horrible user
  experience and contributes greatly to making Swing applications feel so
  different from everything else.

And finally, a quick advice to the NetBeans team:  please stop blogging
about SWT or Eclipse.  Refocus on writing good Java code and only post
about what makes NetBeans different from Eclipse as opposed to "better".

But
most of all, stop publishing stories of users who switched from Eclipse to
NetBeans, it is embarrassing.

Just let your users and readers judge, they will respect you more for it.

I noticed two interesting features in the latest 3.1-RC1 Eclipse build:

• This is partial completion of types.  Notice that I typed "PT"
  (uppercase) and that ParameterTest came up as a potential match.  Very
  useful (and this functionality replaces a plug-in I mentioned in an earlier blog).
   

• I was quite puzzled at first about the overstrike on the parameters keyword
  until I ran my mouse cursor over it…  This is Eclipse’s new way of saying
  that you are using a deprecated API:

Cute.