Glenn Vanderburg: Blog

One Big Happy Family

I remember being at JavaOne in 1999 (I think) when I first heard the terms "J2SE", "J2EE", and "J2ME". I understood the reasoning for such a move, but at the same time I hoped they wouldn't go too far with the distinction.

It was both amusing and refreshing to hear Jonathan Schwartz acknowledge in this morning's keynote that Sun has been guilty of pushing multiple, separate platforms rather than emphasizing Java as a single platform. He promised that they would do better.

Of course, they aren't in a full retreat from the multiple editions, and such a retreat wouldn't make sense anyway. There are real distinctions between those environments, and the facilities available on them need to reflect that. But I do hope they spend more time focusing on what all the editions have in common.

Unfortunately, for those of us who like to stay informed about what's coming in future releases, it's necessary to pick an edition. This afternoon at 3:30, the "Overview and Roadmap" sessions for J2SE and J2EE are scheduled opposite one another.

Long overdue ...

Sun's finally ready to really support a free and open community of Java developers in a real way (or so it seems. Check out java.net.

Java 1.4.1 for OS X, and the first bug

While I was downloading 1.4.1 yesterday, Greg Vaughn was reading the release notes and IMing me about them:

Known issues: no incremental gc :-(
What about concurrent?
It doesn't say

That's OK, really ... incremental GC had serious problems in 1.3, and they weren't fixed for 1.4; instead, nearly all of the GC work went into the concurrent collector, which arrived with Sun's 1.4.1.

But I started wondering about the concurrent collector. It occurred to me that I could probably tell whether the concurrent collector was included by turning on verbose GC output and watching.

First, I ran the SwingSet2 demo with the default collector. I saw what I expected: lots of young generation collections, with full heap collections occurring just under 10% of the time. Then I tried -Xincgc, and saw the same behavior; the release notes were telling the truth about the incremental collector.

With the -Xconcgc option, I saw very different behavior. In some cases I've seen up to 500 young collections before any attempt is made at a full sweep. Looks like the concurrent collector is there.

But there's a race condition. On 3 out of 4 runs, roughly, when it did finally attempt a full GC, I saw this:

[GC 14014K->14001K(58108K), 0.0069902 secs] [GC 13975K->13975K(58944K), 0.0093674 secs] [Full GC[Unloading class sun.reflect.GeneratedMethodAccessor4] [Unloading class sun.reflect.GeneratedMethodAccessor3] # # HotSpot Virtual Machine Error, Internal Error # Please report this error at # http://bugreport.apple.com/ # # Java VM: Java HotSpot(TM) Client VM (1.4.1_01-14 mixed mode) # # ShouldNotReachHere() # # Error happened during: generation collection for allocation # # Error ID: /SourceCache/HotSpot14/HotSpot14-14/src/share/vm/memory/generation.hpp, 346 # # Problematic Thread: prio=3 tid=0x0fd9ecf0 nid=0xedc8c70 waiting on condition # Abort trap

A weird Java2D bug under OSX

Last week I was playing with my toy line drawing editor again, and I noticed a very strange bug in the Java 2D graphics support under MacOS X. I wrote a tool to draw ovals, and it worked great. Then I wrote a tool to draw circles; it was just a subclass of the oval tool that constrained the vertical and horizontal axes to be the same dimension. It worked great, too, but I noticed that all my ovals (and other shapes, for that matter) were nicely antialiased, and all of the circles were jaggy.

At first I thought I'd done something wrong, but the circle tool doesn't change any of the drawing code from the oval tool.

It turns out that if you draw a circle using Java2D under MacOS X (at least using Java 1.3.1 under Jaguar) it does not do antialiasing at all. If you choose the oval tool and start sweeping out the bounding box, you can see it suddenly switch to jaggy pixels as the dimensions become completely circular, and then back to antialiased mode as you keep going. In the picture, both shapes were drawn with the oval tool; the only difference is that the one on the left has a square bounding box.

It doesn't happen with Java on other platforms, or with Cocoa. My theory: there's an optimization path in the Carbon port of Java2D. When it notices that it's drawing a true circle, that optimization path kicks in, and there's a bug so that it loses the quality hints.