Sun has posted the early draft review of early draft review of Java Specification Request 203, More New I/O APIs for the Java Platform. Proposed features include:
I'm working through it now. There are lots of details I'd adjust, but overall the direction feels about right. Comments are due by May 27.
On reviewing this, I think I'm struck by a fundamental flaw in the JCP for the first time. Sun is still mired in a 20th century, waterfall, big bang approach to development. There are at least three, probably more, different things going on in this process that could certainly be separated and developed independently.
However that would require three separate efforts and three JSRs, and the whole JCP process is too heavyweight for something as simple as "add copy and move methods to the File class". If it isn't an all-singing, all-dancing, asynchronous, extravaganza with closures and annotations galore, it's just not worth filing the JSR for.
Rather than a slow evolution and accumulation of features, each one being rolled out when it's ready, there's a massive rush to push everything into each roughly biannual release of the JDK. Some simple features are held back long after they could have been released while others are pushed out well before they're ready. This is partially a result of the idea that everything has to be in the core library: data structures, database access, XML parsing, cryptography, sockets, and a dozen other things. JDK development is based on a fundamentally unagile, unmodular model.
Perhaps this is fundamental to platforms. Still I wonder if there's a better way (and perhaps the open sourcing of the JDK might enable it). What's the real core of Java? The pieces you can't do without? java.lang, a few pieces of java.io and java.util Could we cut the language and library down to this, then add pieces only as necessary for each application?
I think the key to making this work would be one more language feature. We'd need to get serious about package management and versioning. We'd need a standard way to identify the required versions of each library, or perhaps each class. Then classes would need to be able to specify the minimum version of the libraries they require. Some sort of centralized system or user repository would hold different versions of various libraries. Maven already comes very close to this, and JSR-277 may go further.