JavaOne technical session presentation PDFs are now available online. Click on the paper clip in the presentation column to download. The username is "Developer" and the password is "JavaOne07". These will only be available until tomorrow, Friday, May 11, so grab them now. They should be reposted in the clear in a couple of weeks.
I noticed I had actually signed up for one session twice so I tried to login to ScheduleBuilder. I managed to delete the duplicate, but I haven't been able to add a new session to replace it. The site is getting hammered, even at 7:30 in the morning, and whatever they're using on their backend (JEE perhaps?) isn't up to handling the load. A few minutes ago it went down completely. This is a classic example of why one should design web applications RESTfully and without session state. Session state doesn't scale.
Juergen Schmidt kicks off the morning talking about writing Openoffice.org Extensions with NetBeans. (Well actually the Motorola CTO did with another content free keynote, but I choose to ignore that.) This is the smallest session I've been in so far, only room for a couple of hundred people and the room's not nearly full. Frankly this is a relief after all the megasessions I've attended so far. He starts by demoing writing a function in Java for use in the spreadsheet app using a NetBeans wizard. (Side note: OpenOffice Calc opens three sheets in new documents by default just like Excel even though 99%+ of documents only use one. Does it really have to copy Excels' mistakes? Remind me to file a bug report on this.) OpenOffice has its own cross-language component model. The API is defined in UNOIDL. (Didn't DOPM teach us this was a bad idea?)
Questions:
It's not just about add-ons. You can write programs that use OpenOffice as a plugin or library. E.g for converting documents to PDF.
David Koelle and Geertjan Wielenga are talking about "JFugue: Making Music via Java Midi and Illustrating API usability". I know nothing about MIDI or music. It's the second half that got me here. JFugue sits on top of and renders to JavaMIDI, but the API is much, much simpler. It takes 17 lines of JavaMIDI code to play a middle C. It takes 2 lines of JFugue. (Why not 1? There is a reason...)
As I see it, there are three major things that make JFugue simpler and better than JavaMIDI:
The music demos are cool but I don't know much about that. I do know something about the API principles, and those are quite good. Among others, Davis espouses:
He also notes wisely that the success of an API depends on non-API things like documentation and web pages as well as code.
Sun's Mark Reinhold is delivering an OpenJDK Progress report. I preferred the original title, "Hacking the JDK". "J2SE is desperately in need of renaming. We just haven't gotten around to it." Do you need Java 6 to build it? No, Java 5 will work. The binary plugs will be reduced in size. There's more in them right than needs to be there.
Crypto algorithms are encumbered by U.S. export law. SNMP is encumbered. Color management system has already been replaced.
JDK is traditionally stored in TeamWare. Moving to Mercurial. Sun internal cutover in June. Public release later in the summer.
Currently it only builds on Solaris and Linux. It does not build on the Mac or Windows.
Stanley M. Ho of Sun and Michal Cierniak of Google are talking about JSR 277: Java Module System. This is an enhanced JAR format along with a central repository for holding different versions of JARs. You can write metadata for programs specifying which versions of which libraries you want to use. JAR files can reference other JAR files.
Currently searching all JARs in classpath is a performance issue. Three kinds of hell:
Native libraries can also be added to modules, as can additional JAR files. I.e. jar files can nest inside JAM files.
Third party repositories will be supported.
This is connected to superpackages in a way I don't quite follow. Maybe a 1-1 mapping from superpackages to JAM files?
A JAM file is just a JAR file with some extra metadata. This goes in a MODULE-INF directory within the .jam file.
Multiple repositories are allowed:
Class file verification and even JIT can be done earlier, before runtime.
There's a lot more but I'm finding it hard to pay attention. It's important but very dry material. I don't have enough interest in the details to care a lot one way or the other about any of this.
Aleksandr Kuzmin discusses Static Analysis Tools. I love these things. They don't find or fix every problem (or even most) but they find and fix so many problems at such low cost.
According to Kuzmin, static analysis can test all blocks, execution paths, and data ranges with no instrumentation of the code. This makes it able to test things that dynamic tests can't find and functional tests won't find till much later.
Static analysis is based on Control Flow Graphs (CFG). Nodes represent program points. Edges represent possible flow of control.
75% of bugs are local; i.e. intraprocedural.
At least 30% of unreachable code reveals real bugs. Programmmers meant to don something and didn't.
First 20% off review time classifies 60% of false positives.
80% of warnings can be easily evaluated.
Now he's going into dynamic analysis. I have less experience with this. Can anyone recommend tools (preferably open source) for dynamic analysis of Java code? Dynamic analysis has a low rate of false positives, less than 10%.