Finding module-info.class without loading a jar

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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?

--
Mark Raynsford | http://www.io7m.com

Reply | Threaded
Open this post in threaded view
|

Re: Finding module-info.class without loading a jar

Alan Bateman
On 23/02/2018 19:18, Mark Raynsford wrote:

> 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
Reply | Threaded
Open this post in threaded view
|

Re: Finding module-info.class without loading a jar

Mark Raynsford
On 2018-02-24T07:53:16 +0000
Alan Bateman <[hidden email]> wrote:
>
> 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.

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

--
Mark Raynsford | http://www.io7m.com

Reply | Threaded
Open this post in threaded view
|

Re: Finding module-info.class without loading a jar

Remi Forax


On February 24, 2018 12:33:25 PM UTC, Mark Raynsford <[hidden email]> wrote:

>On 2018-02-24T07:53:16 +0000
>Alan Bateman <[hidden email]> wrote:
>>
>> 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.
>
>> 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.

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


--
Sent from my Android device with K-9 Mail. Please excuse my brevity.