F3 is a new scripting language with an emphasis on UI implementation. The interactive tutorial really showcases its power. The key innovation seems to be the binding feature which simplifies interactive graphical programming by reducing the boilerplate code needed to handle events, perform redraws, etc.
In a similar vein, there is a language called Processing. Processing seems to look more appealing for sandbox work or for my kids to play around with code and graphics.
The docs say this, but I didn't guess from the API that the CommandTimeout property on a Connection does not actually apply to commands. It only applies to opening the connection. To set the timeout for commands, use the CommandTimeout on the Command object itself (i.e. commands do not inherit connections' timeout settings).
ISO Recorder is a small add-on for Windows XP that allows ISO images to be burnt to CD or to rip CDs as ISO images. It is a smaller installation than Daemon Tools. It adds context menu items to Windows Explorer for .iso files and for CD devices.
EJB 3.0 has simplified the usage of session beans considerably (and presumably message beans as well). Gone are home interfaces and PortableRemoteObject.narrow(). The stubs and proxies are all but invisible. But, clients still need to bootstrap using vendor-specific means. The "Java EE application client" approach is still suggested (i.e. running your application in a client-side container). Running outside of a client container (as a "stand-alone" client) still requires vendor-specific JARs and JNDI configuration. You'd think they fix this. Someday, perhaps. Entity beans are gone completely, however -- hooray! You have to learn the new JPA API, though...
I had a Java class that has a static import for org.junit.Assert.assertEquals which imports a number of signatures including one with arguments String, double, double, double. I also defined in that class a static method named assertEquals with the argument signature String, double[], double[], double that invoked the JUnit assertEquals. Under Eclipse 3.2.0, the compiler accepted this code and it worked the intuitive way. Under Eclipse 3.2.1, the compiler misidentified my call to the double[] version of assertEquals as if I were trying to call the double version, and issued an error message complaining about the type mismatch.
I wondered which behaviour was correct, the 3.2.0 or 3.2.1 version. I checked the Java Language Specification and it is silent on the subject. Reading between the lines, however, it would seem that neither the 3.2.0 nor the 3.2.1 behaviour is correct (although 3.2.1 is almost right). The spec does say that if you statically import a type and also define a type with the same name in the class, a compiler error is issued. If I extrapolate that rule to include imported members, then the 3.2.1 behaviour is correct, although I would argue that the error message that it gives is misleading or even wrong. It should give an error message along the lines of "the statically imported method name 'x' conflicts with the definition of 'x' in the class".