Now blogging at diego's weblog. See you over there!

in their sights

Declan McCullagh has an article in News.com where he describes a piece of little known legislation called NET:

If you've ever used a peer-to-peer network and swapped copyrighted files, chances are pretty good you're guilty of a federal felony.

invalid dns queries

Dylan has commented on a Slashdot story about the amount of invalid DNS queries. Interesting, (both the article and his comments!)

more on swing v SWT

Chris Adams posted a comment to my previous entry that pointed to a comparison between Swing and SWT. He said (reproduced in full):

For the sake of argument, I'm willing to accept the assertion that Swing has improved significantly, but I wonder why there don't seem to be any Java applications which use a Java GUI toolkit which don't feel slow. Rendering is noticeably slower, control interaction is perceptibly slower, and even simple text entry can seem slow.

I've been interested in Spaces because I think the field is overdue for some innovation but each time I try it, I give up because its GUI is unusably slow. Fair enough, Spaces is still in beta but . . . every Java app I have used exhibits this to one degree or another. Very simple apps and ones where the developer has spend a great deal of time tuning the display code are usable but they're never snappy, even by OS X standards.

(Based on experiences using a the 1.4 OS X JVM on an 800Mhz iMac, or Sun's latest for W2k on a 1.2Ghz Athlon and 1.8Ghz P4, all with a boatload of memory and decent video cards)

The one exception to this is the native code: Apple's Cocoa-Java bridge is indistinguishable from native code except that small Java apps take slightly longer to load than small native apps (the difference is in the noise with larger apps). Having come from a server-side Java background, Cocoa-Java was the first thing that made me consider Java applications plausible for GUI applications, with the major caveat about portability (fortunately, portable logic + platform-specific GUI isn't a major loss and you do end up with an app which truly indistinguishable from a native program, unlike Swing's emulation).

The point of this rant is simply that I think the article demonstrates the sort of tunnel-vision which has held Java back. Sure, Swing may be faster than it's ever been but it's nowhere near native speed - forget SWT, Swing needs to be compared to native widgets using more realistic tests. The 10,000 row table is too artificial - most people work with hundreds of records, not thousands, and most programmers working with large datasets have learned to do paging so they only process data which is actually visible. I'd be more interested in real-world things like menu responsiveness, window resizing or scrolling speed in a paged list-box / table implementation - areas where a few extra milliseconds can give your application a lasting reputation for sluggishness.

My server-side work & experience with Cocoa-Java makes me want to defend Java but I simply cannot when it comes to anything GUI-related. Java's going to keep its second-class reputation until it's indistinguishable from native code and the widgets behave like native widgets in every aspect. I'm worried that Sun's developers are reacting defensively to SWT and losing sight of the real goal. With .Net around, I don't think they want to keep a system which requires a good deal of developer time to reach the "slow but usable" stage.

I can't really agree with Chris with the assertion that Java is not at the level of native application. Certainly this comes from my own experience. I run spaces every day on a P3-800 (IBM Thinkpad T21) with 384 MB of RAM under WinXP Professional. For me the performance of spaces is as good as any other native application, and its L&F is almost the same. It's as simple as this: if this wasn't the case, I simply couldn't use the app. And I certainly wouldn't have released it.

That said, I think that the main point here is that there is a certain disparity on speed. Obviously Chris says it's slow because he can see it. And I have had/heard of several reports of the JVM silently crashing when certain hardware (driver-level I mean) speed optimizations are activated in the graphics subsystem of a machine (all of these on Windows).

What I think is happening here is that the speed improvements that Java exhibits on some machines (take, for example, its performance on my system, undistinguishable from native apps) are heavily dependent on Java2D optimizations (and ties to underlying hardware optimizations) that were added in recent JDKs. So if those hardware optimizations are not present on the system, or they are less marked, then Java/Swing performs poorly.

So IMO the main thing that is missing is not more focus on speed, but rather focus on uniform support within platforms (particularly Windows) of the improvements that make Java work properly in some systems.

This is, truly, a big difference that still exists between Java and native apps (again, particularly on Windows): lack of uniform user experience. And I don't mean just in terms of performance, I mean also in terms of installation, conflicts that appear when using different JVMs, and so on. I think that when this problem is solved in its entirety we'll get to the stage that Chris is looking for.

plan b is back (again)

It's been almost two months since I posted the last episode of Plan B. The last few days I've been thinking more frequently that I should go back and finish it. So there we go.

Swing and SWT: a comparison

This entry by a Sun engineer is pretty good at comparing Swing and SWT, the pros and cons of each, and in particular in debunking the myths around Swing. Good reading.