Paroli aux agi

How much can a thoughtfully elaborated language evolve? How much without implying a sufficient amount of thinking about the real purpose of such an evolution?

This sounds philosophical but is not the start of a discussion about philology (litteraly "the love of words" in ancient greek and J.R.R Tolkien's speciality), as what I'm going to talk about is the current evolution of the java language and the java platform as a whole.

There seems to be so much debate on language subjects such as closures and erasure/reification... All these debates are really interesting and I think these are indeed good moves.

But this seems like pulling a beautiful napkin on a dirty table : JEE...Well ok this is a bit exagerated, but I mean that the focus on ease of development for this release of the platform completely removed the focus from the ease of management of applications at runtime.

All this focus on ease of development and productivity improvements is a really good move anyway. But I think that if the brilliant minds discussing on these difficult language/JVM subject could allocate a bit of their time to JEE's architecture, we would finally have something a little bit more production-ready than now.

Do I need to remind that nowadays each and every peace of software is upgradeable and manages its version in one way or another (Firefox, Eclipse, Linux with packages, all MacOS software, even Microsoft software...etc).

Yet JEE 5.0 applications still don't/won't have any conventions on versions of deployed artifacts...
Is this because this kind of version management is complete fantasy?...no.

In fact, OSGI implementations already provide this scheme for java applications. A fair amount of java developers have already experienced this through the plugin and update site mechanism of Eclipse through the Equinox OSGI implementation.
The very famous Spring framework also provides an alpha OSGI support for Spring-enabled applications.
A JSR has even been started proposing the support by the JDK and/or J2EE of OSGI.

So why in the hell WHYYYY did some "clever" folks think they could flush this away (sewers once again) and try to push in the JDK a somehow neither tested nor sufficient JSR for a Java Module System (JMS acronym is already used BTW)...instead of contributing improvements to the already tested and proven useful OSGI initiative.
If you look at how this JSR (see 2.6) sweeps away OSGI in a paragraph as simplistic, you can see how much the "not invented here" motto can get in action...

It's a bit sad to see how the focus on the language and/or a narrow view of the use of java is done at the expense of the view on architecture and/or live management of applications in IT systems.

The same way Esperanto was a good idea and a cleverly elaborated language, is java becoming a very clever language with no soul?

This seems a bit desperate, and as much as I value the language improvements, I do value a lot more OSGI, Eclipse RCP and Spring framework, not because of a hype surge, but for their fair usefulness and clean design.

Wouldn't it be a lot cleaner to have a common jar pool/repository in a j2ee server (clearly specified in the repository) with a simple version handling (similar for example to the structure of a Maven or Ivy repository), and to add, say, a "dependencies.xml" file to the different deployable. This, along with a clear classloading scheme in the specification would allow people to deal with versions management.

(BTW the JSR 277 people didn't even think about J2EE when elaborating it...what a clever move........not!)

Wouldn't it be clean to have a "myapp-1.0.0.war" archive in a JEE server, and just have the ability to replace it at runtime by dropping a "myapp-1.0.1.war" and let the server handle the replacement and the dynamic linkage to the appropriate libraries?

This definitely wouldn't be easy to implement, but woudn't it be a better place for the focus of brilliant minds than a meaningless struggle with Rubyists?

I for myself prefer a lot design to language improvements.