On 2/7/2015 3:17 AM, Tim Boudreau wrote:
Demanding that only one version of B can exist will pretty much keep me
and a lot of other people from caring about or contributing to what might
happen with this JSR.
I think the trick is to provide a non-hacky way that someone can plug
something that can create a hierarchy of classloaders using whatever hierachy
it chooses (and yes, that has some implications for that thing's load-order
and privilege), without forcing that down the throats of all applications,
since such things add overhead and complexity that not everything needs.
I think there's a spectrum from "prove it works" to "pray it works" with a lot
of stops in-between that different kinds of applications have tolerance for (I
once was hired to untangle a huge application used in some very scary places,
which was routinely built and deployed with an additional ancient version of
itself on the classpath because the sources to some classes had been lost and
nobody there understood what they did), and different trade-offs along the way.
Are you looking for the JSR to solve the problem, or just to make it
straightforward to layer a solution on top of it?
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...
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.
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.
I've put these version proxies into play in many cases as a way to solve
interactions across versions when needed. It's not pretty, but sometimes there
are really no other choices. In some cases, there are serialization
implementations in widely used classes which already do this, and thus you can
create marshalled object instances to pass around to other places and just
unmarshall them in the other versions class loader.
Gregg Wonderly
