requires public for automatic modules

[Paul Bakker]

Thanks for the answer Remi. I'm wondering if a (optional) build step is considered. During build the byte code analysis that jdeps does could be used to generate better metadata for automatic modules. This would be a compromise between using automatic modules without this metadata and actually adding a module-info to a JAR file (which isn't a great option for 3rd party libs).

I've looked at several (small) code bases now, and using default modules keep resulting in a long list of transitive dependencies that I would prefer not to have in my module. Because of that a top down migration process doesn't result in proper modules when using automatic modules, and that would be a bad start when migrating to modules. The required trial and error work will frustrate users as well.

Paul



> On 22 Apr 2016, at 11:12, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Hi Paul,
> 
> ----- Mail original -----
>> De: "Paul Bakker" <paul.bakker.nl at gmail.com>
>> À: jigsaw-dev at openjdk.java.net
>> Envoyé: Vendredi 22 Avril 2016 10:52:23
>> Objet: requires public for automatic modules
>> 
>> Hello,
>> 
>> I'm experimenting with automatic modules again. I have a module
>> "demonstrator" that uses Jackson Databind.
>> 
>> 	import com.fasterxml.jackson.databind.ObjectMapper;
>> 	....
>> 	ObjectMapper mapper = new ObjectMapper();
>> 	String json = mapper.writeValueAsString(modularityBook);
>> 
>> In module-info.java I have the following:
>> 
>> 	requires jackson.databind;
>> 
>> On the modulepath I have jackson.core, jackson.databind and
>> jackson.annotations.
>> Building results in an error:
>> 	
>> 	 class file for com.fasterxml.jackson.core.Versioned not found
>> 
>> This makes sense because the ObjectMapper class that I'm using implements the
>> Versioned interface (from jackson.core).
>> When generating a module-info.java using jdeps for the jackson.databind JAR
>> however, it generates the following:
>> 
>> 	requires public jackson.annotations;
>> 	requires public jackson.core;
>> 
>> This is much closer to what I would expect when using the jackson.databind
>> module.
>> When using jackson.databind as an automatic module, I will end up with a list
>> of requires for transitive dependencies that I shouldn't have to care about.
>> Why don't automatic modules take better care of transitive dependencies, so
>> that the application's module-info looks similar to what it would after
>> transforming the dependencies to named modules?
>> 
> 
> because it will require the runtime to parse the bytecode of an automatic module, which is a slow operation.
> 
>> Also, jdeps doesn't actually show this problem when looking at the code when
>> still on the classpath:
>> 
>> 	jdeps -cp lib/jackson-databind-2.7.3.jar
>> 	out/com/javamodularity/demonstrator/Demo.class
>> 	
>> 	Demo.class -> lib/jackson-databind-2.7.3.jar
>> 	Demo.class -> java.base
>> 	   com.javamodularity.demonstrator (Demo.class)
>> 	      -> com.fasterxml.jackson.databind
>> 	      jackson-databind-2.7.3.jar
>> 	      -> java.io
>> 	      -> java.lang
>> 
>> Best regards,
>> 
>> Paul Bakker
>> 
>> 
>> 
> 
> regards,
> 
> Rémi