guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: store reference detection (was Re: JARs and reference scanning)


From: Chris Marusich
Subject: Re: store reference detection (was Re: JARs and reference scanning)
Date: Thu, 11 May 2017 01:41:34 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hi Ricardo,

Ricardo Wurmus <address@hidden> writes:

> Chris Marusich <address@hidden> writes:
>
>> There are probably many ways to accomplish that.  For example, in Java,
>> perhaps we could implement a custom classloader.  Or maybe we could
>> patch the built-in class loading mechanism [1].  Similarly, in Python
>> there are also ways to customize the import mechanism [2].  Perhaps Perl
>> also has a similar mechanism?
>
> Jar files can be told to import classes from another Jar by adding it to
> the “Class-Path” field of the Jar’s manifest.
>
> Here’s an example:
> https://docs.oracle.com/javase/tutorial/deployment/jar/downman.html

I didn't know this!  That's awesome; it might be just what we need.

> I don’t know if this mechanism permits the use of absolute paths, but
> it’s worth a try.  I should note that this doesn’t help with store
> reference detection, because the manifest will be part of the compressed
> Jar.  But if this works we could avoid propagation for Java packages.

Preliminary testing shows that this does in fact work.  See the attached
tarball; when you run "make" on its extracted contents, you can verify
for yourself that it works (don't forget to do 'guix -i icedtea:jdk'):

--8<---------------cut here---------------start------------->8---
[0] address@hidden:~
$ java -cp /tmp/embed-absolute-classpath-in-jar/Main.jar Main
Hello world!
[0] address@hidden:~
$ jar -tvf /tmp/embed-absolute-classpath-in-jar/Main.jar
     0 Thu May 11 01:35:26 PDT 2017 META-INF/
   131 Thu May 11 01:35:26 PDT 2017 META-INF/MANIFEST.MF
   309 Thu May 11 01:35:26 PDT 2017 Main.class
[0] address@hidden:~
$ jar -tvf /tmp/embed-absolute-classpath-in-jar/Greeter.jar
     0 Thu May 11 01:35:28 PDT 2017 META-INF/
    69 Thu May 11 01:35:28 PDT 2017 META-INF/MANIFEST.MF
   396 Thu May 11 01:35:26 PDT 2017 Greeter.class
[0] address@hidden:~
$ grep /tmp/embed-absolute-classpath-in-jar 
/tmp/embed-absolute-classpath-in-jar/*
Binary file /tmp/embed-absolute-classpath-in-jar/Main.jar matches
/tmp/embed-absolute-classpath-in-jar/Main.txt:Class-Path: 
/tmp/embed-absolute-classpath-in-jar/Greeter.jar
[0] address@hidden:~
$ strings /tmp/embed-absolute-classpath-in-jar/Main.jar | grep 
/tmp/embed-absolute-classpath-in-jar
Class-Path: /tmp/embed-absolute-classpath-in-jar/Greeter.jar
[0] address@hidden:~
$ 
--8<---------------cut here---------------end--------------->8---

Based on this test, it looks like we can embed absolute paths in
uncompressed JAR files.  This is great!  It means that if we can package
Java libraries in this way, we won't need to propagate inputs for Java
libraries (because Java will find the classes via the embedded
Class-Path values), and the usual reference scanning mechanism will just
work (because the JAR files are not compressed).

I don't know what limits there are on the number of entries one can put
into the Class-Path line, but hopefully that won't be an issue.

-- 
Chris

Attachment: embed-absolute-classpath-in-jar.tar.xz
Description: Binary data

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]