abcl-asdf: introduce JDK-JAR object to describe JDK tags (Alan Ruttenberg)

We introduce an ASDF component JDK-JAR, a jar file where the pathname
and name are relative to the 'java.home' property of the executing
JVM.

Note that the use of JDK-JAR consistutes an experimental interface
with a lot of potential problems going forward.  We note some of those
issues for further consideration:

1) Java9 does away with the packaging of system tools in jar files,
using the Java module system to provide "optimized" access to system
resources.  Therefore, a better abstraction would be to somehow
describe the artifacts that need to be loaded to satisfy the
dependencies, and then provide mappings to strategies that locate and
load them within the JDK filesystem.  c.f. <http://abcl.org/trac/ticket/423>.

2) The structure of the 'java.home' directory varies in unknown ways
between JDK versions and across platforms, making the use of JDK-JAR
relative pathnames need special casing for various situations.

3) ABCL may be run on a JRE runtimes which have a different directory
structure than a JDK, most notably missing the 'tools.jar' artifact.

4) Given the problems arising from points 3 and 4, meaningful
conditions and appropiate restarts should be emitted by ABCL-ASDF when
it cannot satisfy JDK-JAR dependencies.  This machinery should also be
extended to the other major current deficiency in ABCL-ASDF lack of
intellible errors/meaningful restarts when Maven cannot be located.

Despite these problems, it is more useful to experiment with being
able to reference JDK artifacts in ABCL-ASDF definitions than not, so
we include JDK-JAR as an experimental feature.

We need some way to mark the JDK-JAR feature as experimental.  The
easiest way forward would be to split it off into a separate file
compilation unit with appropiate comments.

Merges <https://github.com/armedbear/abcl/pull/35/files>.
parent 2de2378a
......@@ -68,7 +68,7 @@
;;; The original JSS specified jar pathnames as having a NAME ending
;;; in ".jar" without a TYPE. If we encounter such a definition, we
;;; clean it up.
(defun normalize-jar-name (component)
(defmethod normalize-jar-name ((component jar-file))
(when (#"endsWith" (slot-value component 'name) ".jar")
(with-slots (name absolute-pathname) component
(let* ((new-name
......@@ -103,7 +103,16 @@
(defmethod perform ((operation load-op) (c class-file-directory))
(java:add-to-classpath (component-pathname c)))
;; a jar file where the pathname and name are relative to JAVA_HOME
(defclass jdk-jar (jar-file) ())
(defmethod normalize-jar-name :after ((c jdk-jar))
(setf (slot-value c 'absolute-pathname)
(merge-pathnames
(merge-pathnames
(slot-value c 'name)
(make-pathname :directory `(:relative ,(slot-value (component-parent c) 'relative-pathname))))
(java::jstatic "getProperty" "java.lang.System" "java.home"))))
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment