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 <fo...@univ-mlv.fr> wrote: > > Hi Paul, > > ----- Mail original ----- >> De: "Paul Bakker" <paul.bakker...@gmail.com> >> À: jigsaw-dev@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
