Re: Why is it allowed to have several modules with the same name?

[Alan Bateman]

On 27/12/2020 09:50, Gunnar Morling wrote:
Thanks for clarifying, Alan. So it is intended and well-documented, 
it's still not quite clear to me though *why* that is. Wouldn#t it be 
more in line with the module system's goal of reliability to reject 
such error-prone configuration?
Reliable configuration is mostly about ensuring that there aren't 
missing dependencies, cycles between dependencies, or split packages. 
You get reliability with the module path by only reading the first 
definition of a module. If someone put 10 versions of the same module on 
the module path then classes will only be loaded from the first module, 
unlike the class path where you risk loading classes from more than one 
of the artifacts.


If it helps, the java --validate-modules option is useful for detecting 
and reporting issues. It will print an informational message when there 
are multiple definitions of a module on the module path.


-Alan

Re: Making jlink Plug-in API public

[Alan Bateman]

On 25/12/2020 10:29, Gunnar Morling wrote:

Hi all,

Are there any plans for making the jlink Plug-in API public any time soon,
perhaps for JDK 17?

I think the ability to implement custom plug-ins that are run at linking
time would open up quite a few interesting opportunities, e.g.

- removing unused members and obfuscation
- adding resources like annotation indexes for the whole image
- verifying that exported and required API methods match (avoiding
NoSuchMethodErrors due to adding incompatible module versions to an image)

The latter would be interesting in particular for monolithic applications
built jointly by multiple teams, avoiding the need to recompile the entire
application if only a single module changed, while still having fidelity
that APIs would match.

The intention in early revisions of JEP 282 was to expose a plugin API. 
It went through many iterations and re-designs during JDK 9 but it 
didn't get to the point where it was really ready to be exposed by an 
incubator module. There was also a complication at the time with 
incubator modules providing implementations of ToolProvider (that issue 
has since been resolved as it became a blocker for jpackage too).


Is it worth giving it a priority boost and re-examine it now? Hard to 
say as it would likely require several iterations and a lot of review 
cycles to bring this to incubation stage. At the same time, our 
experience with plugins to date is that many of the plugins are deeply 
tied to core modules and just aren't maintainable outside of the jdk 
repo. I think it could also be argued that some of the suggestions that 
you list should be be plugins included in the jdk.jlink module. For 
example indexing of annotations was something that was explored and 
prototyped at one point (the original requirements document for the 
module system JSR had an item along these lines). A tool that scans a 
module path to do static analysis and detect incompatibilities could be 
valuable as a link time plugin. Are these plugins that you would be 
interested in developing, contributing, and maintaining?


-Alan.