> > The practicality of software is that specific versions are what you test > with. Subsequent versions may not be compatible and just because you need > to use another software package that needs a newer version should not > dictate that rework occur. Yes, it might be a good thing, but... >
I think it's interesting that, for example NodeJS's library delivery model is that you can and will have as many different versions of a library as you want (since NodeJS's namespacing is the filesystem itself, you can have A/node_modules/libbar depending on B which has a different node_modules/libbar). Since NodeJS is Javascript, if an object from A's libbar meets an object from B's libbar, they can interoperate if duck-typing allows them to (it also means you find out very late in the game if they don't). I bring that up to point out that the whole model of "use the libraries on the system" - i.e. linking against unknown versions of things at runtime - is less important today than it once was. In a world where deploying usually means spinning up a new OS instance which contains known and known-to-work versions of things, the problems of long-lived machines where libraries will be upgraded in-place many times are less worth solving than they once were. > What we need the most is a way to cleanly separate and isolate software. > Netbeans has a class loader hierarchy that tries its best to keep things > separated. I like that. The Java, conventional hierarchical class loader > structure helps prohibit lateral views, which for me, create the largest > exposure to hassle. > > What would be good, is to figure out a way to keep objects from one branch > of the tree from ending up in another branch of the tree when that branch > is not compatible. > FWIW, Maven has this via the maven-enforcer-plugin - turn on DependencyConvergence and it will fail the build when multiple versions of something are on the classpath. That means you have to do something when it happens, but it guarantees it won't happen without you knowing it. > I think about it as a set theory problem. The package names and classes > and versions represent a "set". Discarding the version is the problem in > considering where overlap can occur. There can never be a proper > intersection between two versions. > > If we had tools that could analyze these sets to determine that there was > in improper intersection in visibility, that would help make it clear to > developers that their code was interacting in a way that incompatibility > and class cast exceptions would occur. > > Then, having a way to unmarshal an old version and remarshal to the new > version as a "proxy" or "delegate" through lambdas would be awesome. > What you're asking for is duck-typing in Java :-) Or, really, something more like a classloader that can see both versions of a library, and if the serialVersionUID that would be generated for both is identical, to treat them as interchangeable. Which is theoretically implementable, but would either require a lot of runtime type information that doesn't exist now, or would impose a substantial performance penalty at runtime (loading any class would involve some search and compare operations). Anyway, I fear we're wandering off topic here. Do you believe that this JSR should *implement* these things, or just facilitate the possible implementation of them? -Tim
