State of Java EE sessions

Just sat through a couple of sessions on new features in Java EE and where the Java Enterprise process is going at the moment. Much of this was detail but two things impressed me :
- it was interesting to see the cross pollination taking place between java and C# as languages. C# in its latest incarnation took a leaf out of Java's booklets now supports generics while Java now has support for annotations ( called attributes in .NET). At last making a java based web service is as simple as putting a @WebService annotation on a class - something the C# language designers got right from the start. There are some sessions taking place on longer term features that people see in next generation languages - particularly around integrated query semantics becoming a first class language construct. A lot of innovation in this area has come out of the Microsoft Research labs and I hope to get a better sense of it in the next few sessions. Having played around with C-Omega ( the prebeta review of the concepts) and catching up some of the material on the LINQ project that was presented at the PDC by Andes Hjelsberg and Don Box recently, I hope the java community follows the lead here. While these features are more a programmer's tool and not likely to fundamentally change software architecture, they should at least reduce the impedance mismatch between data usage and storage and make code less buggy and smaller.
- I hadn't realised how much of a threat the java community perceives as coming from the scripting languages stack like Ruby and Python etc. The Java EE/EJB is too complex lobby is more vocal than I had expected and the adoption of simple frameworks like Ruby on rails to tackle things like the lower complexity web based projects seems to be increasing. There are Java versions of scripting and frameworks out there ( Groovy and Trails ). An interesting stat that amazed me was that in a test scenario, the configuration for a Spring based Java Ee application required more lines of code ( i assume this really means XML - deployment descriptors etc) than the total amount of code in an equivalent Ruby on Rails application. And it was also slower ! Whilst this is just anecdotal and a one off example, it does focus attention on where the java community sees it's priorities lie.
Bottom line, in order to make Java EE flourish , the focus of the community seems to be on ease of use. There is a clear drive towards removing the overhead of over specific configuration and promoting new language constructs like Annotations. There are also moves towards API simplification generally as well as trying to get a POJO persistence framework standardised. I'm not sure a particular persistence framework logically belongs in an Enterprise development stack as different situations require making different architectural decisions here but we shall watch with interest to see where this goes. As stated above - my personal preference is to move towards making data access a first class language construct such that operations on data become as simpe as manipulating variables and types without the developer needing to specify a mapping to a relational or XML store explicitly. Becoming part of the language with associated semantic richness would remove the endless ping pong of frameworks and committees that seems to bog down much progress in this space. otherwise ten years later we will still be talking about the next big O/R mapping technology.