bertrand’s brain grep

Via Pier: Apple have just made their J2SE 5.0 Release 3 Developer Preview 2 available on their Apple Developer Connection website.

I haven’t tried it yet, and I hope it installs on Panther which I’m still running due to the Checkpoint VPN client which still not running under Tiger (and Checkpoint have not replied to my request for information about what to expect when).

Eclipse’s Rich Client Platform aims to provide a way to reuse Eclipse components in standalone applications, not only in the IDE.

Interesting. With SWT being (in many people’s opinion) a better UI toolkit than Swing, this could become a much better client platform than plain Java.

I installed my first serious Swing-based application in 1999, at a time when Swing was evolving very quickly. Since then however, very little seems to have happened at Sun regarding the Java UI platform. Too bad.

Congratulations to Torsten and Stephan for their implementation of continuations for java!

Their work is available in the Cocoon CVS as the javaflow block, but my guess is that it could be of interest to other projects as well.

If you want to know what continuations are and what they’re used for, have a look a the Cocoon Flow documentation.

Update: although this might sound too good to be true it is not an April’s fools joke, you can actually check it out!

Congatulations to the Groovy team on their JSR 241 submission!

Having a standardized way to mix and match scripting and Java would be a Good Thing, and everything I see in Groovy looks great, so why not? I hope this gets approved.

Update (2004/03/30): James Strachan announces the approval of the JSR. A Groovy step for man…

Tom didn’t agree with what I wrote earlier. He might be right about forking, that’s a serious risk. And with java currently under (FUD) attack from the Dark Side, any move must be well planned.

To limit the risks, Open-Sourcing java would require very strong test suites – as usual, software cannot be better than its tests. But Sun certainly has such test suites, and opening them would only help improve them. So it’s not as risky as starting from scratch.

Today’s news go in this direction: Rod Smith of IBM has reportedly written to Sun to offer a collaboration on Open-Source java, sharing the load in an open way. He explicitely mentions Sun’s test suites as part of the idea.

I think this is great news. Backed by two companies that most people trust (at least at the technical level), and with strong and open testing, an Open-Source java will certainly succeed and improve Java’s acceptance. But time is running fast and other platforms are not standing still.

(by the way, I’m thankful to Tom for still respecting me after waiting soooo long for that Swiss wine. The post-it is still here right under my eyes, with lots of this on it ;-)

Update: there’s more details and lots of good ideas at linuxtoday.

Update #2: there’s more at Berin Loritsch’s Weblog and at BileBlog. But I’m not linking to this last one, its tone doesn’t deserve it (you’ll find the link at Berin’s anyway, let’s not push its Google ranking ;-)

Bill Venner’s artima web site is becoming a gold mine of interviews with influent technologists and language gurus.

After reading Failure and Exceptions, where James Gosling explains his vision (not too convincingly in my opinion, he sounds a bit defensive to me), and the related thoughts of Bruce Eckel, I realize that I’ve been more and more leaning towards not using checked exceptions the way they are meant to, rather just throwing Exception everywhere and figuring it out at the upper levels of the call stack, sometimes using marker interfaces to classify exception types.

The problem with java’s checked exceptions is that clueless programmers (no offense – it happened to me too) being forced to catch them tend to write code like

try {
.. something cool
} catch(NastyException nah) {
// gotta catch this, method throws FunnyException only
// helphelp - dunno what to do??
}

at which point the NastyException and its so precious stack trace is lost forever. Of course this can be caught by code reviews or tools, but I bet you can find some of this in most existing java projects. And maybe you’ve spent hours chasing bugs hidden by such code.

The hard part is when designing interfaces: what kind of exceptions should IMultimediaDatabaseConnector throw, when it’s supposed to work with either in-memory data, networked databases or removable media? Any guess is usually quickly proven wrong, so, in my opinion, moving to plain Exceptions makes it easier and can help avoid the above don’t know how to catch this syndrome.

Eckel also has an interesting ExceptionAdapter extends RuntimeException example, but this hides exceptions from method declarations and could confuse programmers, whereas throwing Exception makes it clear that something can happen. JDK 1.4′s built-in chained exceptions mechanism also helps in cases where you’re forced to throw a specific Exception, but it’s still not ideal.

Eckel makes interesting parallels with Python, where exceptions are unchecked yet can be caught at every level. The more I read about Python, the more I think it might be the next “big” language.

The Sun Java Desktop System looks really cool to me, but, according to them, consists of …a GNOME desktop environment, StarOffice Office Productivity Suite, Mozilla browser, Evolution mail and calendar, Java 2 Standard Edition and a Linux operating system…. Did you spot Java in this? Yes it is there. But Java Desktop System? Really?

At least SCO cannot sue them for using the Java name ;-)

Wow. If you haven’t tried LogFactor5 and you use some logging in your apps, your should have a look at it! It can be enabled real easy in Cocoon 2.1 by editing cocoon.xconf, see comments inside that file.

What? your apps don’t use logging? you can sign them up for the museum-of-lost-apps then, opening soon ;-)