After the keynote, I put my nose to the grindstone and (finally) hit the sessions hard. First up, Effective Concurrency For the Java™ Platform (TS-2388). As Brian pointed out several times, none of the content was riveting and new, but it pointed out common fallacies and errors. Definitely worth checking out when the content goes online.

And that does it for the AM...

The excuses continue. Between lunch with co-workers, dinner with the Darkstar (et al) team, and various hallway conversations, I only made it to 1/4 of a session on Thursday. I'm kinda bummed about that, but I think this year the social side of JavaOne is more important for me. I'll do better on Friday.

I did catch the last hour of the After Dark event. Not bad. They trucked in a bunch of the champion Battlebots from the television show and let folks from the conference drive them. Gratuitous fun. They closed the night with a Rolling Stones cover band who was decent. Would have been better if the beer weren't so bad.

After the general session, I caught the NIO talk (TS-2992). What I learned is that I don't know jack about NIO. The 6 tips and tricks the speakers presented didn't mean a thing to me. Oh, well

After that I went to the Java performance BOF (BOF-2366), where people asked very specific questions about API's haven't had a reason to use. What's up with that? I used to be Java savvy. I guess I just haven't had a reason to use some of the newer, deeper APIs yet. That's the trouble with being on the engineering team for a C-based product.

I had to leave the BOF early to be at the Darkstar lab 20 minutes early. The lab went really well. All of the feedback I got was extremely positive. As far as I can tell, we hit it out of the park. Even though the lab was scheduled to end at 22:45, we ended up staying until 0:15. People just didn't want to leave!

General Session

• The JDK is now completely open. (There are actually a couple of small pieces that we couldn't open up yet, but you can get binaries plugs for those pieces until we can get them opened.)
• The governance model for the JDK community was announced. The board will be Doug Lea, Fabiane Nardon, Simon Phipps, Mark Reinhold, and Dalibor Topič
• The TCK will also be make available for use by the community.
• The next several releases of JDK 6 will be focused on execution and startup speed.
• Rich announced JavaFX, which is a new family of technologies and tools that make it easier to use Java in the consumer space. The first piece is JavaFX Script, formerly known as F3. Consider it a competitor to Flash. The second piece is JavaFX Mobile, which is our new name for the SavaJe technology we recently acquired. It's approximately Java SE for handsets. (Believe it or not, we actually had a female engineer demo JavaFX Mobile on stage!)
• McNeally talked about Curriki, his pet project for providing free K-12 educational materials online.

And the on-going saga of the Darkstar hands-on lab ate up a couple more hours of my day. Between that, being a proctor for the Realtime Java hands-on-lab, and hanging out in the pavilion, I didn't actually make it to a single session today. Shame on me.

After the session I had to go try to get the Darkstar lab (LAB-7210, Wednesday at 20:45) in ship shape. Still not done, but I think I've got it on the ropes.

Today I'm attending the CommunityOne JavaOne pre-conference (AKA NetBeans Day).

General Session

• According to an EU-funded study, Sun is the number one contributor of open source code in the world. More notably, we have contributed three times the number of lines of codes as the number two contributor, IBM.
• Tim O'Reilly pointed out that while the major Internet properties are based on open-source technologies, almost none of them are themselves open source.
• Tim O'Reilly's definition of "Web 3.0" is where it builds on the emerging data streams that aren't explicitly provided by the user, such as GPS data, gestural interfaces, etc.
• Sun is considering how to compensate developers for open source materials that we monetize.
• Tim O'Reilly reminds me of Dennis Hopper now that he wears a beard.

  

NetBeans General Session

• Rich Green reiterated that we need to look at how to compensate the authors of open source content that we're able to monetize. "I'm sure we're going to do that... Real soon now," he said.
• For Sun, going balls-to-the-wall open source is really just us returning to our roots and re-establishing two-way communications with our developers.
• Schwartz on Eclipse: "THey may have more market share, but our developers have more fun." He said that we're not concerned with Eclispe. They're our "brothers in arms" against "someone else." In general, the competition has been good for us, and we're really doing well. We hope to be dominant, but we don't want to kill them.
• There's an OpenOffice.org plugin for NetBeans for developing OOo extensions.

That's it for now. I'm off to lunch. Look for more this evening.

If you're not familiar with Jackpot, it's an exceedingly powerful way to transform source files. Think of it as XSL for programmers. Using Jackpot, one can write queries that examine source files, such as looking for unused variables or counting occurances of if statements without else blocks, or transformations that walk through source files and make changes, like adding Logger.entering() and Logger.exiting() calls to every method or changing Iterator.hasNext() loops into for-each loops. Jackpot queries and transformation can either be driven by rules files or programs written to the Jackpot API. Rules files are certainly simpler than writing to the API, but they are also more restricted in the kinds of queries and transforms they enable. The Jackpot API certainly has a learning curve, but it gives the developer the ability to examine every little detail of a source file and do transforms that are arbitrarily complex. If you haven't looked at Jackpot, grab a copy of NetBeans and give it a whirl!

On the bright side, though, it looks like JSF may find a niche as the preferred abstraction for doing AJAX development. See dynafaces and jMaki. I'll be very interested to see how that one plays out.

I really wish we had something like this in the US. I think it would go a long way towards getting folks interested in the Java language, especially if it were a recurring event and had some good prizes. I assume that anyone could participate in the current Electric Jungle, but while the official docs have been translated into English, all of the forum posts are in Russian, so unless you speak the language, I suspect you'd be at a distinct disadvantage.

The most impressive thing about the dev pack so far is how well it handles macros. Not only is it not confused by complicated ifdef's, it even does macro interpolation on the fly. In the Grid Engine source tree, we have one file that defines a macro that defines a function, and then uses that macro to create a series of functions. When I view that file in the new dev pack, the function pull-down menu shows me each of those dynamicly generated functions instead of an ugly pile of macros. Sweet!

Also, if you hadn't noticed, RC1 of NetBeans 5.5 is now available. So far, I've found it to be much stabler than beta 2.

First off, a little background reading. These articles were recommended to me by Sun engineering:

• How to Handle Java Finalization's Memory-Retention Issues -- Tony Printezis
• Java theory and practice: Garbage collection and performance -- Brian Goetz

In addition, I found the following articles helpful:

• Finalization, threads, and the Java technology-based memory model -- Hans-J. Boehm
• Gems from e-BIT: Why finalizers should (and can) be avoided -- Phil Vickers

From those articles and from direct feedback from various Sun engineers, these are the lessons about finalizers that I have gathered:

1. If there's a way around using a finalizer, and it's not ridiculously more complicated, do it. See Tony Printezis' article for some alternatives to finalizers. In many cases, an explicit dispose() method is the best choice.
2. Never trust a finalizer to free something that has no other way of being freed. There is no guarantee that a finalizer will ever run. For example, deleting lock files is something that definitely should not happen in a finalizer, unless it also happens somewhere else.
3. If you're designing an API that may have a JNI-based implementation, either design in explicit dispose() methods, or make sure there's a common clean-up point where held resources can be freed, such as exiting the session, so that implementers are not forced to use finalizers.
4. The Java language's specification of finalizers has some holes which allow you to do bad things (such as restoring a reference to the object being finalized). If forced to use a finalizer, do so carefully.

In my end, my findings were exactly what my initial searches suggested. It is, however, nice to have confirmation.

I began to wonder if I wasn't perhaps misusing the assertion facility. After a quick search, I found Programming With Assertions. In that document, the author validates my use of assert false, but suggests a safer alternative. Instead of assert false : "message";, the author recommends throw new AssertionError("message");. The effect is the same, except for two caveats. First, even when assertions are disabled, the later will still cause an error to be thrown. Second, in cases where a return statement is expected in the branch, the former is a syntax error while the later is valid.

Armed with this new bit of knowledge, I will be replacing the occurances of assert false in the project source base as I run across them.