June 30, 2005
Eclipse 3.1 highlights
There are a lot of goodies in the brand new Eclipse 3.1, even for those of us who have been using milestone builds. The new features I find the most interesting are:
- Restricting access to packages or classes. Using regular
expressions, you can ask Eclipse to flag any import of classes that belong
to private or proprietary packages. For example,
TestNG exports its
public API in org.testng and the implementations are in org.testng.private.
Marking this latter package as restricted guarantees that you will never
import it accidentally. Similar use cases would be: not relying
on internal API's (com.sun.*) or avoiding J2ME proprietary API's (com.nokia.*).
- Visual overrides. You can now highlight methods that override
methods from superclasses. Very convenient.
- Externalized strings preview. Hover on a getString() parameter and
Eclipse will look up the corresponding string in the resource bundle.
- Single-stroke refactoring undo. Being able to undo a refactoring was already handy, but it now takes a single Ctrl-Z to undo even a complex refactoring.
The entire list of the new features can be found here.
June 27, 2005
NetBeans Day
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.
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.
June 23, 2005
The future of email?
I just read a very interesting interview of Bill Gates and Ray Ozzie about email management. There are three parts that I found particularly enlightening:
Basically every e-mail that I've ever sent has been looked at by something like 30 or 40 lawyers to see if there's any way it can be misconstrued.
There are three kinds of meetings at Microsoft: where it's a free-for-all and you can do whatever you want; where the people at the table have to pay attention but the others don't (if you sit in a chair in back, that's a signal that you're going to just sort of be paying half attention); and meetings where we want total attention. The default really is: If you're sitting at the table, you're supposed to focus on what's going on.
and in particular:
But e-mail right now gets used for things where it's not perfect. If you have attachments going back and forth with lots of different versions of a document, that's crazy.
It's interesting to see how full circle we've come with attachments. When email started getting reasonably popular in the early 90's, several standards competed to address the need to exchange binary files. The first attempts were quite awkward (uuencode) and became more sophisticated with time (better binary encoding and MIME types).
Attachments work very well with email now, regardless of your email client, but it's reaching a point where, as Bill Gates puts it, it's sometime being misused. Email is fine when you are exchanging read-only documents, but clearly not optimal when the various recipients are expected to make modifications to the document and resend it to the entire list. Time will tell if Microsoft's solution will find its way on our desks, but there is clearly a big market for this kind of functionality, that even a successful product such as Lotus Notes hasn't filled to far. At any rate, read the interview, it's well worth it.
June 21, 2005
New home for TestNG
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.
June 14, 2005
Numbered interfaces
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.
June 13, 2005
More on interfaces
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.
June 10, 2005
JUnit 4 overview
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!
June 08, 2005
Extensibility the interface way
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
IMarkerResolution2orIWorkbenchPart2in 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.
June 06, 2005
What Steve isn't telling us
So the rumors were true, Apple is really switching to Intel. There are a lot of interesting things in Steve Jobs' keynote, as usual, but the most interesting part is, as always, what he's not telling us.
First of all, it was quite interesting to hear the boo's coming from the crowd as the Intel banner was descending on the stage. I don't think this has ever happened in a WWDC keynote, where the audience is usually closer to the state of rapture than in the mood to throw eggs. The closest it might have come to that was when Apple unveiled its partnership (did I hear "sell-out"?) with Microsoft a few years ago, but the Intel announcement seems to have hit a nerve with the Mac crowd.
Too bad they are not seeing that this decision might be the best thing that has happened to Apple in years, and a way to finally go over this 1.7% market share that Apple computers have been stuck at. But I'm sure the Mac fans will come around, like they always do, because in the end, they always agree with what Steve Jobs does and says.
Of course, Jobs himself is a master at this deception game, and after constantly refuting the claims that Intel was faster than PowerPC, the sudden switch to Intel is a way to say "Okay, you were right, PowerPC's are really slower". Except he's not saying it, of course.
Does anybody remember the claims a few years ago that Apple had the fastest computer on the planet? I bet you do, except if you're a Mac fan, in which case I'm sure you have hundreds of ways to explain in hindsight what Jobs really meant.
But let's get back to this morning.
The porting technologies demonstrated by Jobs seem quite convincing. Admittedly, they are no rocket science (the emulation of a chipset at the binary level or with layered API's is a well-known technique) but they undoubtedly contributed to soothing the panicked audience, still traumatized by the Carbonization process. As a matter of fact, porting Mathematica to Intel apparently only involved modifying a few lines of code and some Office Power PC applications actually run out of the box (albeit probably not at maximal speed).
So after this impressive disclosure of porting technologies, why is it going to take between one and two years to see the fruits of these efforts? If Apple has been secretly and successfully porting all the successive versions of their operating systems for five years on Intel hardware, why the additional delay?
Could it be that what was shown and heard from the stage was, again, not quite the reality that Steve claims?
Make no mistakes: just like all the previous years, you heard lies and exaggerations this morning. The fun part now is trying to separate facts from fiction.
Any bets?
June 05, 2005
Putting an end to the SWT/Swing nonsense
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.
June 03, 2005
Cute new features in Eclipse
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:
