public virtual MemoryStream

For me, the most interesting sessions of the conference were regarding the new MemoryModel and Concurrency Utilities. Having recently done quite a bit of threading code, it's clear that JDK 5.0 will vastly improve on the current primitives synchronized, wait and notify (which will, of course, still be supported in JDK 5.0, though they probably won't be used as much).

The new memory model will ensure that things will work much more intuitively than they currently do. The double-checked locking idiom for instance is broken right now due to allowed statement re-ordering and caching of variables in registers (this, by the way, is not just a Java-issue, it's also broken in languages like C++ and C#). Now statement reordering (either by the compiler or by the processor) and caching of values in registers are extremely important features for performance so they cannot simply be turned off to make stuff like this work. Using new definitions for volatile and synchronized, stating when they should read/write to memory (as opposed to using cached values), things will work much better and more intuitively in JDK 5.0.

The new concurrency utilities package (based on Doug Lea's threading libraries) contains a lot of new Classes and Interfaces to make writing multi-threaded code much easier. The idea behind this package is to do for threading what the collections framework did for collections. When they first mentioned this, I was rather skeptical to say the least. At the end of the session though, I believed they might just pull it off.

The concurrent utilities package will implement thread pooling through Executors. The Executor interface consists of a single "void execute(Runnable command)" method, so is effectively just "something that runs Runnables". This can be a single threaded worker, a regular thread pool, a scheduled thread pool or even a custom implementation. There's an Executors class which has factory methods to create many commonly used types of Executors. The actual type returned by these factory methods is typically an "ExecutorService": a sub-interface of Executor with added methods to, among other things, manage termination of the pool.

JDK 5 also introduces concurrent collections. These collections achieve thread safety while still allowing certain operations to occur concurrently. While using the synchronized keyword often requires placing a lock on the entire collection during iteration, concurrent collections will allow multiple operations to overlap each other. The new ConcurrentHashMap class for instance allows overlap of multiple reads, reads over writes and even up to 15 overlapping writes (it will be interesting to check out the code to see how they pulled off the concurrent writes). Also, iteration over a ConcurrentHashMap will never throw a ConcurrentModificationException.

Another example of a concurrent collection is the CopyOnWriteArrayList - this class is optimized for cases where iteration is much more frequent than insertion or removal. It is for instance ideal for EventListeners. As the name suggests, every write causes the current collection data to be copied, thus guaranteeing that no ConcurrentModificationExceptions will ever be thrown during iteration - if a collection gets changed while another thread is iterating, that other thread will continue seeing the original (non-changed) data.

There are also a number of lower level concurrency utils like Locks and Conditions that will be introduced in JDK 5.0. A Lock allows for functionality similar to that provided by the synchronized keyword, but without forcing you to lock and unlock within a single block of code. Locks also have added options like the ability to check a Lock without waiting infinitely, or timing out Locks.

The ReentrantLock class implements a reentrant mutual exclusion lock with the same semantics as built-in monitor locks (synchronized), but with extra features like the ability to interrupt a thread waiting to acquire a lock, specifying a timeout while waiting for a lock, polling for lock availability, and support for multiple wait-sets per lock via the "Condition" interface. ReentrantLock outperforms built-in monitor locks in most cases, but is slightly less convenient to use as it requires a finally block to release lock, like

Lock lock = new ReentrantLock();
...
lock.lock();
try {
    ...
} finally {
    lock.unlock();
}

A Condition is the abstraction of wait-notify. You can get a Condition object from an existing Lock object, and subsequently call await() and signal() on them. This allows you to for instance have multiple Condition objects against a single Lock, instead of having to use notifyAll to wake up all threads, only to put all but one of them back into a wait-state.

There are many other useful classes and interfaces like ReadWriteLock, ReentrantReadWriteLock, Semaphore, CountdownLatch, etc.

And last but not least, JDK 5.0 will introduce Atomic Variables: classes that support atomic operations like "compare-and-set" and "get,set-and-arithmetic". At runtime, the JVM will use the best available implementation of this functionality, depending on the platform it runs on. So this may internally be implemented using a lock, or may use a native contruct (if supported by the processor) to do these kinds of atomic operations. An example of an atomic variable class is "AtomicInteger". which will be useful for things like counters and sequence numbers.