I'm continuing my review on the expected features from where I started them:
JSR 308: Annotations on Java types
An extension to the Java annotation syntax to permit annotations on any occurrence of a type
In my opinion, this will make Java code stranger... May be I have got used to the current Java code style, but too much @ will make it look like PHP or other languages using strange symbols.
About the feature - it could add new flexibility in checks - kinda like "throws", final ... Imagine how JUnit will change after this feature is introduced!
JSR TBD: Small language enhancements (Project Coin)
A set of small language changes intended to simplify common, day-to-day programming tasks
String in switch --- My comment is "FINALLY, GUYS!"
Automatic resource management --- Well, we all got tired of all the try-catch around code pieces using Streams. Just makes the code larger, but not doing anything special.
Generics initialization improvement - personally, I don't mind leaving it out, but sloppy developers will make less errors.
Collection literals and array-like access - this is similar to the one above. Just for easier initialization and access.
JSR 203: More new I/O APIs for the Java platform (NIO.2)
New APIs for filesystem access, scalable asynchronous I/O operations, socket-channel binding and configuration, and multicast datagrams
The best new feature about this is the new .resolve() method, which will find the files as they are meant to be found and not force the developer to think which class loader is used at the moment etc etc... Until man encounters this problem, he doesn't know how frustrating it can be.
Update the XML stack
Upgrade the JAXP, JAXB, and JAX-WS APIs to the most recent stable versions
Actually, I don't know the exact reason behind the decision to drop the upgrade of the above-mentioned technologies, but as I use them at work on daily basis, I find this surprising. It would be great if their specifications are revised and developers at Oracle (former Sun) upgrade them to the next level, because Java API for XML will always be "modern" and the need for updates/improvements won't decrease.
Of course, I could be terribly wrong. ;)
Swing JDatePicker component
Add the SwingLabs JXDatePicker component to the platform
I have not used Swing as much as to notice that DatePicker is missing ... When I read it was to be "ADDED" I thought, "shame on you for forgetting it"! I suppose that more than half of Swing applications need date of some sort...
I'll skip intentionally the other improvements regarding class loaders, collections concurrency and Swing , because I don't find them as attractive as the ones I commented above. Here's a link to the full list.
I hope you found my comments reasonable. I am optimistic about the new Java version. I just hope the developers don't have too many problems and they don't delay the launch...