Sorry for the big deal on this post. JavaOne is such a fire hose, it's really hard to keep up.
Something else I should mention. In my JavaOne posts, I've been just referring to interesting sessions without explaining what was in them. That's not just to tease and frustrate you. The session slides are available online, and the audio will soon be available on the Sun Developer Network site, for free.
So, Wednesday PM. Gilad Bracha's talk about the new super packages JSR was very, um, succinct. It lasted about 20 minutes and then went into a long Q&A session. The basic idea is that with Dolphin, we're considering adding support for packages of packages that can change member visibility. For all classes in packages contained in a super package, the public classes, methods, and fields are only visible to classes in packages also contained in the same super package. In addition, the super package can selectively export contained packages and classes, making their public members available outside of the super package. The important part is that all this happens without changing the packages and classes that are being contained. The JSR is only just getting started, but when it's done, it will represent a big step forward for Java™ platform usability.
I sat in on Mark Reinhold's talk about embedding XML literals into the Java language. Mark made a good case for why we need XML literals added along side of String literals. He also offered up a couple of possible syntaxes. I'm not yet convinced, though. XML is great, but is it so great that it merits making the language even more complex? Check out the slides and decide for yourself.
The Java Persistence API session was a good introduction to the API, where it came from, what it does, and why. The important thing to know is that the API was written as the successor to EJB CMP, but ended up being targeted for Java EE and Java SE.
Bill Pugh's and Jeremy Manson's synchronization talk was chock full of handy tidbits. Interesting points:
- Volatile can be a good alternative to synchronization
- Volatile longs and doubles are written atomically
- Volatile reads and writes cannot be reordered by the VM
- In many cases, it's required to write correct code
- Use immutable objects whenever possible
- Prevents a lot of need for synchronization
- Makes it possible to make fields final
- Compiler advantage
- Final fields also save on synchronization and allow compiler optimizations
- In Java SE 5.0, you can use Field.setAccessible(true) to make final fields modifiable.
- Use java.util.concurrent wherever possible
- Synchronization is not that expensive -- if you want to worry about it, go after useless synchronizations, like Vector and Hashtable and I/O ops
- All points of interaction among threads need attention, if not synchronization
- Documentation is the key, but even documenting this stuff ain't easy
- Worry about correctness before performance
- Try not to share mutable objects among threads
I would like to say that I spent all night at the BoF's, but I wimped out. Even worse, I actually drove back home Wednesday night. There's a reason for it, though, and I'll explain in my next post.