So what is in JavaSE 7?... well from the OpenJDK website
So lets go through these from the perspective of what most people do with Java, namely the delivery of enterprise quality applications which are primarily delivered on servers, more and more in a virtualised environment. So yes JEE is more for those folks than SE but lots of smart folks deliver Server side apps, or desktop agents, which aren't about delivering a Swing GUI. They might use the eclipse approach if they are doing desktop for instance. The point is that these folks, who are the vast majority of Java's developer base, are folks who choose their frameworks and libraries for their specific problem. So how does this new feature set help us?
- Non-dynamic languages - irrelevant for Java folks, but it makes sense in the VM, might even support some clever language changes in the future but its not for the Java folks so sets say - Negligible improvement
- Strict class file checking - Okay needed and part of the specs - Minor improvement
- Small language enhancements - as it says on the tin, minor but nice stuff - Minor improvement
- Class loader stuff - needed but again its minor - Minor improvement
- Concurrency and Collections stuff - okay I'm biased here but if Doug says we need it, we need it. Actually things like the Hashmap are great additions and with the rise of multi-core this is important stuff - Improvement but not a full "point" release
- Internationalization - Required but again - Minor improvement
- IO improvements - Good stuff and for certain applications great to have, impact wise its the same as Concurrency - Improvement but not a full "point" release
- Cryto - now for me we are into the world of "its a library" so yes its good that we can all use ECC crypto... ummm but how many people actually do? Would a dynamic class loader via URL or a build compliance piece not be better? - Developer decision, bloat risk
- Client - All of this is a waste of time for enterprise developers, great I've got a new 2D render pipeline, that really helps the performance of my server side app and just kicks ass with the extra weight this adds to provisioning a VM. - Desktop
- Web - how miss named is this one? Its actually XML and again this is the sort of thing that would be much better left to developers and deployments. We've seen before that having JAX-WS hard-coded in JavaSE was a dumb idea and this applies generally to the XML pieces. Lets be clear here, people choose their own XML encoders and approaches on a regular basis, having a standard Java library for these things and at the JavaEE level enforcing these as standards makes sense. It does NOT make sense for these to be part of the JavaSE platform as people who don't want to use JavaEE are liable to either not want to do WS or are using a framework that bundles a later version or uses different XML libraries. - Pointless upgrade to bloat
- Management upgrade - I like MBeans, I've written lots of fun stuff with MBeans that made Tivoli users smart but did I care whether it was in JavaSE or not? No I did not. If I'm deploying JMX to manage my Java App I'd like to bundle it in the deployment. It even says that if you were a JRockit user you already had this stuff - Library upgrade
- JSR 294: Language and VM support for modular programming
- JSR 308: Annotations on Java types
- JSR TBD: Project Lambda
- Modularization (Project Jigsaw)
Technorati Tags: SOA, Service Architecture