On Sun, Apr 9, 2017 at 6:10 AM, Mark Evenson <evenson@panix.com> wrote:
On 4/7/17 17:50, Alan Ruttenberg wrote:
> I'm using :mvn ASDF components and ran into a problem with having multiple
> versions of the same library.

The clearest path forward for conflicting dependencies would be for
JAVA:ADD-TO-CLASSPATH to take an environment which would contain a new,
dynamically added classloader for all java artifacts loaded in scope.
This mechanism is used by Apache Tomcat to introduce a separate
classloader for each Java Servlet instance.

There is OSGI which is able to do this sort of thing, and there is already prototype code in JSS to use it. However OSGI, or multiple classloaders, needs a fair amount of thought to use correctly, because you can easily arrive at situations where compatible classes can't be used because they were loaded into different classloaders.

The first step is to enable managing dependencies when it *is* possible to run without conflicts, as with the :mvn-module I showed above. In this case it turns out that the dependencies only *seemed* to conflict. With the appropriate use of Maven there is no conflict in this case.

The thing that is different in our environment as compared to the standard maven situation is that we don't have a central pom for an application that gathers all dependencies and resolves them at once. Instead we have separate ASDF systems which are loaded independently and yet may have intertwined dependencies. 

I can't comment on the Java 9 issues as I've not studied them as yet.

Alan
 

Even though the Tomcat developers presumably thought such a method would
allow some degree of security, they failed.  Partly because of the need
for each servlet to use global resources in-process for efficiency gains
(think JDBC), and partly because the security guarantees of the
underlying JVM can be trivially broken (as can be seen by
[abcl-servlet][1] which boots a swank servlet binding a listening socket
on localhost).

Symbolic bindings in ennvironments via the [five currently missing
methods in ABCL for CtLv2][cltl2-env] could be presumably mimic the
scoping of all possible desired classloaders.

Some abstraction of this sort will be needed to run on Java 9, so we
might as take a stab at supporting both at a profit to ultimate
complexity.

[cltl2-env]: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node102.html

[1]: https://bitbucket.org/easye/abcl-servlet

[java:add-to-classpath]: :has
""""
4.1 JAVA
4.1.1 Modifying the JVM CLASSPATH
The JAVA:ADD-TO-CLASSPATH generic functions allows one to add the
specified pathname or list of
pathnames to the current classpath used by ABCL, allowing the dynamic
loading of JVM objects:
CL-USER > ( add-to-classpath " / path / to / some . jar " )
N.b ADD-TO-CLASSPATH only affects the classloader used by ABCL (the
value of the special
variable JAVA:*CLASSLOADER*. It has no effect on Java code outside ABCL.
""""  .

--
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."