If you want to enforce that kind of consistency - that no two
application modules should export same named package - it should be
possible to implement a user defined jlink plugin to enforce the same.
-Sundar
On 10/13/2016 12:35 AM, Alan Bateman wrote:
> On 12/10/2016 19:17, Karl Heinz Marbaise wrote:
>
>> Hi,
>>
>> i have a question concerning the jlink command in JDK 9..(EA +138 build)
>>
>> I have created two modules lets call them module A and module B
>> (module-info.java):
>>
>> module A {
>> requires java.base;
>> exports com.single.package;
>> }
>>
>> module B {
>> requires java.base;
>> exports com.single.package;
>> }
>>
>> both export the same package: com.single.package
>>
>> The question is: Shouldn't the jlink command fail in such cases cause
>> both modules export the same package ?
>>
>> Otherwise it would mean to fail at the time of starting the generated
>> JVM image which I think is too late...
> You can resolve independent modules A and B without error (and get a
> configuration that contains both) because there isn't any module that
> reads both. If you had module C that requires both A and B then you'd
> get an error to say that A and B export com.single.package to C.
>
> So this is why it succeeds at link time. There isn't any notion of
> class loader at link time and jlink cannot know how the modules will
> be mapped to loaders at run time. jlink could assume that all modules
> will likely be defined to the same class loader and thus reject the
> above but it doesn't.
>
> As to whether the resulting run time image is useful or not then it
> depends on the initial module. If the initial module is C that only
> requires A then it will work, same thing if the initial module is D
> that only requires B. On the other hand, if you do `java -jar X.jar`
> then the initial module is the unnamed module, which by convention,
> will cause all modules in the runtime image with an API to be resolved
> (the module system does not know anything about what X needs). In that
> scenario when A and B will be resolved but will fail when attempting
> to map both to the application class loader. I will guess that is what
> promoted your mail.
>
> -Alan
