What I really really want…

I’d love to see EAR files made more useful by allowing them to be run from the command line. ‘java -ear MyApplication.ear -cp library1.ear;library2.ear’. Even more useful would be to make the default classloader understand EAR files as complete units of deployment, and allow different versions of the same jars to exist within different ear files. Borrowing from J2EE, it should be possible to have a classloader to look inside the local EAR when trying to load a class, and then look in the rest of the classpath. So if MyApplication.ear contains version 1.0.4 of commons-logging.jar and library1.ear contains version 1.0.2, any classes within MyApplication.ear would see 1.0.4, and those in library1.ear would see 1.0.2.

This does mean that if MyApplication was interacting with a class in library1, and tried to reference an instance of a class that was defined in both ear files, a ClassCastException would result, but in my opinion that is not particularly a limitation. If I need to use an API from a library, I should not be concerned with the libraries (or versions thereof) that it chooses to use internally. The present jar based paradigm simply does not allow me that encapsulation.