Java packages do not appear to keep a reference to their inputs

Hello,

I'm not a Java expert, but this appears to me problematic:

Digging a bit more, peeking into the .jar file, which is a ZIP archive:

Still, no traces of the other libraries such as 'java-commons-pool'

which should be referenced.

I assume this means grafts doesn't currently work for Java libraries.

--

Thanks,

Maxim

You're right, java package don't retain references to there input, that's why we propagate required dependencies (mh… sometimes). I don't know how they could reference dependencies directly.

Le 17 octobre 2022 23:04:47 GMT+02:00, Maxim Cournoyer <maxim.cournoyer@gmail.com> a écrit :

Julien Lepiller <julien@lepiller.eu> writes:

A better workaround would be to add a phase that installs file(s) in the

output(s) that contain references to the required store items. They

could simply be text files with one line per reference. That would at

least protect the dependencies from the garbage collector.

The remaining unsolved problem is, of course, grafting.

Mark

--

Disinformation flourishes because many people care deeply about injustice

but very few check the facts. Ask me about https://stallmansupport.org.

Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

Could we, along with installing Java classes as directories instead of

.jar archive files [0] at a more specific prefix, define a search path

specification that'd set CLASSPATH? Currently I don't see anything

setting CLASSPATH outside of the build systems, so even if we propagate

Java things, I don't see how it'd find them in a profile.

[0] Not exactly sure how that's done yet, but it's mentioned here: https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html

--

Thanks,

Maxim

On 18-10-2022 04:45, Maxim Cournoyer wrote:

FWIW, when I used java things in Guix, I manually did

CLASSPATH=$GUIX_ENVIRONMENT/... or the CLI equivalent (some option

argument of 'java').

Some more automatisation, e.g. in the form of search paths as you

propose, would be nice though.

Greetings,

Maxime.

Am Montag, dem 17.10.2022 um 22:45 -0400 schrieb Maxim Cournoyer:

I'd recommend writing an xml file like

<path id="${java-package-name}.classpath">

<pathelement location="${output-jar}" />

<pathelement path="${input1.classpath}" />

...

<pathelement path="${inputn.classpath}" /> 

</path>

to a well-known location. Then we could reuse those files in ant-

build-system.

Cheers

Hello,

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

A nice read is [0], which mentions the existence of a 'Class-Path' main

attribute that can go in the manifest file. If using unpacked jars

works the same as .jars (which are just zip files) for Java, then we

could not only have dependency correctly referenced and loaded via

'Class-Path', but also the grafting mechanism would work, since the

paths would appear in clear (not obfuscated due to zip compression).

Our current usage of JarIndex doesn't suite the bill it was intended

for; this is a performance trick to index all the .jars of a .jar pack;

it'll only list its dependencies if they are packed in the same jar,

which is not what we do or want as a distribution.

[0] https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html

--

Thanks,

Maxim

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Ugh, Class-Path only accepts relative path, not absolute paths:

The location of the JAR file or directory represented by this entry

is contained within the containing directory of the context JAR. Use

of "../" to navigate to the parent directory is not permitted, except

for the case when the context JAR is loaded from the file system.

Perhaps we could patch Java so that it's loader is more adapted for our

use case, or extend its manifest with a Guix-specific Guix-Class-Path

section that'd allow for absolute paths.

--

Thanks,

Maxim

Hi Maxim,

Maxim Cournoyer ???

Groan. Which package(s) compress .jars?

(I found a few in -checkouts, which is its own potential thing,

but that aside.)

Kind regards,

T G-R

Tobias Geerinckx-Rice via Bug reports for GNU Guix ???

OK, found one: openjdk@16.0.1's /lib/jrt-fs.jar.

Kind regards,

T G-R

Hi Tobias!

Tobias Geerinckx-Rice <me@tobias.gr> writes:

Oh, aren't they all? I hadn't realized .jar compression was optional.

I believe our ant-build-system produces compressed jars; in fact it uses

'zip' directly to pack them.

--

Thanks,

Maxim

Hello,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

Actually, reading [0] again, it seems a JAR *is* a zip archive, so

cannot be either compressed or uncompressed.

[0] https://docs.oracle.com/en/java/javase/19/docs/specs/jar/jar.html

--

Thanks,

Maxim

Hi, replying to a few emails at once.

The ant-build-system uses zip -0 to produce an uncompressed archive. By default, jar produces a compressed one, so there's a repack phase for that:

http://git.savannah.nongnu.org/cgit/guix.git/tree/guix/build/ant-build-system.scm#n226

Embedding the classpath in the manifest is possible but would not have the expected effect. That's because a line in the manifest cannot exceed 72 bytes (see "line length" in https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Notes_on_Manifest_and_Signature_Files),so the classpath will look like:

Class-Path: ../../../1234567891011

1213141516/share/java/foo.jar

Although java would read that fine, the grafter will not see it, nor be able to graft foo in a meaningful manner: java would still use the ungrafted version even if another file references foo.

Le 18 octobre 2022 16:56:01 GMT+02:00, Maxim Cournoyer <maxim.cournoyer@gmail.com> a écrit :

Hello,

Julien Lepiller <julien@lepiller.eu> writes:

Ah, I had missed the -0 == uncompressed part. Thank you.

Although it looks like the 72 bytes line width limitation may has to do

with binary data:

Binary data of any form is represented as base64. Continuations are

required for binary data which causes line length to exceed 72

bytes. Examples of binary data are digests and signatures.

Worth a try in my opinion (I'm giving it a shot as I write this).

Thanks for the explanations!

Maxim