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.
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. """" .