Finding module-info.class without loading a jar

[Mark Raynsford]

Hello.

I'm analyzing the contents of jar files and basically need to answer
the question "is this jar file modularized?". To do this, I search for
a module-info.class file in the root of the jar file (and parse it with
ASM), or I look for an Automatic-Module-Name entry in the jar manifest
if there doesn't appear to be a module descriptor available.

Unfortunately, some projects don't put the module-info.class file in
the root of the jar. Some of them place them in
META-INF/versions/9/module-info.class, for example. I could search
every possible subdirectory in the jar for something that looks like a
module-info.class, but I'd prefer not to have to. Is there a standard
method in the JDK that can find the module descriptor class file for me
based on the rules the JVM uses to find the descriptor upon loading a
jar?

[Alan Bateman]

Post by Mark Raynsford
Hello.
I'm analyzing the contents of jar files and basically need to answer
the question "is this jar file modularized?". To do this, I search for
a module-info.class file in the root of the jar file (and parse it with
ASM), or I look for an Automatic-Module-Name entry in the jar manifest
if there doesn't appear to be a module descriptor available.
Unfortunately, some projects don't put the module-info.class file in
the root of the jar. Some of them place them in
META-INF/versions/9/module-info.class, for example. I could search
every possible subdirectory in the jar for something that looks like a
module-info.class, but I'd prefer not to have to. Is there a standard
method in the JDK that can find the module descriptor class file for me
based on the rules the JVM uses to find the descriptor upon loading a
jar?

The JarFile API does this for you. Are you sure you've used the
constructor that specifies the runtime version? Once you do that then
getJarEntry("module-info.class") will locate the module-info.class in
the versioned section. Use JarEntry::getRealName to satisfy yourself
that it always locates the right one (say where you have a
module-info.class in the top-level directory and one each in
META-INF/versions/9 and META-INF/versions/10).

ModuleDescriptor.read is an easy way to parse the module-info.class in
case you need it.

-Alan

[Mark Raynsford]

On 2018-02-24T07:53:16 +0000

Post by Alan Bateman
The JarFile API does this for you. Are you sure you've used the
constructor that specifies the runtime version? Once you do that then
getJarEntry("module-info.class") will locate the module-info.class in
the versioned section. Use JarEntry::getRealName to satisfy yourself
that it always locates the right one (say where you have a
module-info.class in the top-level directory and one each in
META-INF/versions/9 and META-INF/versions/10).

Ah, thank you. I had completely overlooked this constructor.

Post by Alan Bateman
ModuleDescriptor.read is an easy way to parse the module-info.class in
case you need it.

Yes, I'm planning to move to this from ASM.

[Remi Forax]

Post by Mark Raynsford
On 2018-02-24T07:53:16 +0000

Post by Alan Bateman
The JarFile API does this for you. Are you sure you've used the
constructor that specifies the runtime version? Once you do that then
getJarEntry("module-info.class") will locate the module-info.class in
the versioned section. Use JarEntry::getRealName to satisfy yourself
that it always locates the right one (say where you have a
module-info.class in the top-level directory and one each in
META-INF/versions/9 and META-INF/versions/10).

Ah, thank you. I had completely overlooked this constructor.

Post by Alan Bateman
ModuleDescriptor.read is an easy way to parse the module-info.class

in

Post by Alan Bateman
case you need it.

Yes, I'm planning to move to this from ASM.

The main difference between the ModuleDescriptor and the ModuleVisitor of ASM is that you can read the annotations with the ModuleVisitor.
So it may not worth having ASM as dependency.

Remi