sandermak / modulescanner Goto Github PK

Inspect Maven Central to check what libraries are Java modules (automatic or explicit)

Java 100.00%

modulescanner's Introduction

modulescanner

Tracking Java's Progress Through Maven Central

For raw access to Maven Central, you can use Google's mirror: https://console.cloud.google.com/storage/browser/maven-central-eu/repos/central/data

First results as of 2018-11-13 are listed at https://github.com/jodastephen/jpms-module-names#modules-published-on-maven-central

modulescanner's People

Contributors

Stargazers

Watchers

Forkers

karianna ivannov sormuras

modulescanner's Issues

explicit mode?

Being able pass a list of files to scan will be very helpful for doing scans, both for scanning the deltas of new releases to Central, and for breaking the initial baseline scan up into several smaller more reasonable scans.

Cleanup output of jdeps so it is easier to parse

Currently the output is a concatenation of the verbatim lines in jdeps:

sun.misc.Resource Removed. See http://openjdk.java.net/jeps/260 + sun.misc.URLClassPath Removed. See http://openjdk.java.net/jeps/260 + sun.misc.Unsafe See http://openjdk.java.net/jeps/260

It's easier to process/analyze when only the classnames are left. I'm partial to also preserving the replacement that's suggested.

Detect broken MR-JAR files

For example, when a MR-JAR contains a version 9 directory within its META-INF facility, it shouldn't contain classes that are compiled with --release 10 or higher.

See this broken Java module as a reference: https://repo1.maven.org/maven2/org/lwjgl/lwjgl/3.2.2/lwjgl-3.2.2.jar

In its META-INF/versions/9/ directory are classes reporting bytecode level 54.0 (Java 10):

IIRC, jar is not used to create the JAR file. Correct, @Spasi?

Result reported where automatic module appears to have dependencies

After initial runs by Sonatype, some JARs are reported as automatic modules, but also have moduleDepencies listed. That's not possible, an automatic module doesn't have an explicit module descriptor and therefore can't have explicit dependencies.

Some examples of JARs that exhibit this behavior: com.hack23.cia:service.api:2018.8.17 and javax.measure:unit-api:2.0-EDR

Modular JAR files created with recent JDK

Does the scanner support JAR files created with JDK 14 or newer?
Does it only depend on the JRE that is used to run the scanner on?
If yes, on which Java version does the scanner run "at Maven Central"?

Enhance ModuleInspector to record module's API

List, in case of an explicit module, all exported package names.

Quote from Alex Buckley:

📀 Java module
Name: org.ow2.asm.foobar
API: 2 packages (org.ow2.stuff, org.ow2.morestuff) [show them! they're listed in exports. commitment!]

💿 Automatic Java module
Name: foo.bar.quux (derived from JAR manifest)
API: 9 packages (derived from JAR content, may not be stable) [don't show them, they're not stable!]

⚪ Automatic Java module
Name: foo.bar.awesome (derived from JAR filename, may not be stable)
API: 10 packages (derived from JAR content, may not be stable) [don't show them, they're not stable!] (edited)

Giving a flavor of the API is important. It's what distinguishes a Java module from all the components supported by build systems on the right hand side.

Filter for explicit modules is too broad

modulescanner/src/main/java/org/adoptopenjdk/modulescanner/ModuleInspector.java

Lines 54 to 68 in ac537db

 // Get the module descriptor (module-info for explicit modules) if there is one 

 private Optional<ModuleDescriptor> getModuleDescriptor() { 

 return jarFile.stream() 

 .filter(entry -> entry.getName().contains("module-info")) 

 .findFirst() 

 .map(entry -> { 

 try { 

 return ModuleDescriptor.read(jarFile.getInputStream(entry)); 

 } catch (IOException ioe) { 

 LOGGER.error("Failed to get the module-info descriptor", ioe); 

 // TODO Not sure we want to throw a RuntimeException here 

 throw new RuntimeException(ioe); 

 } 

 }); 

 }

There are artifacts that contain copies module-info.class files from other artifacts. Two examples:

java.base -> https://repo.maven.apache.org/maven2/de/mirkosertic/bytecoder/java.base/2023-12-01/
java.naming -> https://repo.maven.apache.org/maven2/org/frgaal/compiler/21.0.0/

invoking CSV mode

I have tried various version of the following and cant seem to get the csv generation to work.

mvn exec:java -Dexec.mainClass="org.adoptopenjdk.modulescanner.Main" -Dexec.args="src/test/resources/test-maven-repo 20170101000000 /home/maven/test.csv

Is the CSV mode suppose to be working in the current version of the source? If so what is the correct way to invoke it?

Detect false positives

Initial scan results show several JARs that are either classified as automatic module or explicit module, because they shade another JARs that has a module-info.class descriptor or MANIFEST.MF file. These should ideally not be counted as automatic or explicit modules. Even better, this situation should be flagged so that library maintainers can resolve this, because this will break their library on the module path.

	// Get the module descriptor (module-info for explicit modules) if there is one
	private Optional<ModuleDescriptor> getModuleDescriptor() {
	return jarFile.stream()
	.filter(entry -> entry.getName().contains("module-info"))
	.findFirst()
	.map(entry -> {
	try {
	return ModuleDescriptor.read(jarFile.getInputStream(entry));
	} catch (IOException ioe) {
	LOGGER.error("Failed to get the module-info descriptor", ioe);
	// TODO Not sure we want to throw a RuntimeException here
	throw new RuntimeException(ioe);
	}
	});
	}