Fwd: Re: Modules with packages duplication

[Georgiy Rakov]

I've attached zip file with test.sh renamed to test_sh, hope this will help.

On 18.05.2016 18:16, Jonathan Gibbons wrote:
> Without yet looking at your zip file, it is possible to compile 
> classes that will not load in the application class loader, because of 
> the restrictions defined for the boot layer. That does not imply the 
> classes themselves are invalid, since they can be loaded and run in 
> suitable configured layers/classloaders.
>
> -- Jon
>
>
> On 05/18/2016 05:53 AM, Georgiy Rakov wrote:
>>
>> Hello Jon,
>>
>> we've encountered situation when class files resulted from successful 
>> compilation cause runtime error; the sources are compiled by single 
>> javac invocation. This looks like incorrect javac behavior, namely it 
>> seems that javac should produce compile-time error if one tries to 
>> compile sources which will cause error at runtime. Could you please 
>> confirm if it's really is.
>>
>> More details are provided in the forwarded message below. I have also 
>> attached an archive with minimized testcase and scripts to run it. In 
>> order to run it please:
>>
>> 1. Unzip attached archive to some machine (Windows or Unix);
>>
>> 2. If it's Windows rename test18/test_bat to test18/test.bat.
>>
>> 3. Modify JDK_HOME variable inside test18/test.bat (or 
>> test18/test.sh) to point to your JDK installation.
>>
>> 4. Run test18/test.bat (or test18/test.sh).
>>
>> Thank you,
>>
>> Georgiy.
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: 	Re: Modules with packages duplication
>> Date: 	Thu, 05 May 2016 18:21:20 +0300
>> From: 	Konstantin Barzilovich <konstantin.barzilovich at oracle.com>
>> Organization: 	Oracle Corporation
>> To: 	ML OpenJDK Jigsaw Developers <jigsaw-dev at openjdk.java.net>, Alan 
>> Bateman <Alan.Bateman at oracle.com>
>>
>>
>>
>> Hello Alan,
>>
>> Thank you for the answer.
>>
>> I have one more question connected with duplication of packages.
>> Now we can compile two modules with the duplicated package without compile-time error if there is no module which can access both of them.
>> But in case of these two modules are readable by third module, in runtime it will result in error of boot Layer, as you said.
>> Is it okey, that compiler allow us to compile code, that will cause runtime failure?
>>
>> Here is minimal test case:
>> ------------------------------
>> module1/module-info.java
>> module module1 {
>>       exports pack;
>> }
>>
>> module1/pack/A.java:
>> package pack;
>> public class A{}
>>
>> module2/module-info.java
>> module module2 {
>> }
>>
>> module2/pack/A.java:
>> package pack;
>> public class A{}
>>
>> module3/module-info.java:
>> module module3{
>>       requires module1;
>>       requires module2;
>> }
>>
>> Thanks,
>> Konstantin.
>>
>> >
>> > On 04/05/2016 14:18, Konstantin Barzilovich wrote:
>> >> Hello,
>> >>
>> >> I can see that RI checks if there are packages with the same names in >> different modules (named or unnamed).
>> >> This check fails even if there is no clash (no module can read both >> packages).
>> >> Will it be the same in final version of JDK9 or it can be changed soon?
>> >>
>> > I think you are asking about modules on the application module path > (`java -modulepath ...`) that are resolved at startup. These are defined > to the application class loader so they cannot have overlapping > packages. It's trivial to do things like map each module in its own > class loader but that messes with visibility with lots of implications > (particularly when running with both a class path and module path or > where you bringing automatic modules into the picture). So what you are > seeing is specific to the boot Layer and no specific short term plans to > change this.
>> >
>> > -Alan
>