Automatic module names
forax at univ-mlv.fr
Tue Feb 7 16:42:06 UTC 2017
I've coded such kind of tool  :)
It uses Maven (Aether) to download the dependencies then do a simple static analysis on the downloaded jars to calculate the dependencies and inject the module-info.class.
Because of the runtime dependencies, annotations, Class.forName etc, you also have to provide additional dependencies by hand so it's not the silver bullet.
And you still have the naming problem, which I've solved by asking the user to provide a name for each non modular jars.
So in order to automatically generate the module-info.class, you end up writing an additional configuration file which is not very different of a module-info.java :(
On February 7, 2017 3:03:38 PM GMT+01:00, "David M. Lloyd" <david.lloyd at redhat.com> wrote:
>On 02/06/2017 12:51 PM, Alan Bateman wrote:
>> On 06/02/2017 18:25, David M. Lloyd wrote:
>>> I don't think there is really a substantial increase in risk between
>>> manually modularizing a library and relying on automatic modules.
>> If several projects take on the responsibility to modularize a
>> that they don't maintain then there is no guarantee that they will
>> up with equivalent modules. Static analysis (`jdeps
>> --generate-module-info ...`) gets you so far but it often needs a
>> understanding of the library to be confident that the module
>> that they write for the library is complete. Automatic modules take
>> much of the behavior of a library on the class path so that it's not
>> necessary to synthesize everything that an explicit module would
>As could a tool, which has the added advantage that the module
>information could easily be incrementally narrowed instead of going
>fully from automatic to fully specified. To do incremental change from
>automatic to fully specified, you'd need a tool to generate an
>automatic-equivalent descriptor anyway.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the jigsaw-dev