Draft Spec for Preview of Module Import Declarations (JEP 476)

[Stephan Herrmann]

Hi Gavin,

Thanks for clarifications.

When I had first looked at the spec example I briefly wondered: why should an 
export be needed to import stuff from the current module, perhaps the intention 
was to focus on accessibility, not exports?

Looking at your answer my reaction now was: sure why should module-info mention 
types that are not exported?

Then I recalled that service implementations need not (should not?) be exported. 
So that's probably where exports-to-self could come in to play, if indeed you 
want to use module import to refer to service implementations (not much to be 
gained here, though).

Next I tried this with javac 23-ea build 24, with these results:
- module import in module-info doesn't seem to be evaluated yet
- importing the current module (anywhere) gives
   "module mtest does not read: mtest" :)

Still, from a specification point of view all looks clear to me now. Based on 
'reads' being reflexive there's no strict need for special case rules indeed.

thanks,
Stephan


Am 24.05.24 um 15:36 schrieb Gavin Bierman:
> Hi Stephan,
> 
> Thanks for your email. Yes, example 7.5.5-2 is missing information to make it 
> more intelligible; sorry about that.
> 
> But you are on the right track - we can use the simple name C in the uses 
> directive *if it has been exported to M*. As you spotted, the JLS requires that 
> the "read by" relation is reflexive, so that’s how a module exports to itself.
> 
> More concretely, consider this slight expansion of the example:
> 
> importmodule M;
> module M {
> exports p1 to M1;
> exports p2;
> exports p3 to M;
> usesC;
> }
> 
> The effect of the import module M declaration is to bring in:
> 
> 1. Package p2, because it's exported by M to all comers, including M; and
> 2. Package p3, because it's exported in a qualified fashion to M.
> 
> And, to answer your question, it does NOT bring in package p1 as that is only 
> exported to M1. In other words (and finally filling in all the details!):
> 
> //A.java
> package p1;
> class A {}
> 
> //B.java
> package p2;
> class B {}
> 
> //C.java
> package p3;
> class C {}
> 
> 
> //module-info.java
> import module M;
> module M {
> exports p1 to M1;
> exports p2;
> exports p3 to M;
> uses A; // error
> uses B; // ok
> uses C; // ok
> }
> 
> Hope this helps, and thanks once again. I’ll clarify the spec.
> 
> Gavin
> 
>> On 18 May 2024, at 14:33, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
>>
>> Hi Gavin,
>>
>> I'm having difficulties interpreting this example:
>>
>> import module M;
>> module M {
>>    ...
>>    uses C;
>>    ...
>> }
>>
>> Literal interpretation would suggest that this imports
>> "all the public top level classes and interfaces in the following packages:
>> * The packages exported by the module M to module M. ..."
>>
>> The notion of exporting to self does not seem to be defined, is it?
>> JLS 7 says: "A module categorizes some or all of its packages as exported, 
>> which means their classes and interfaces may be accessed from code outside the 
>> module." i.e., export regulates accessibility across a module boundary, but in 
>> the above example there is no such boundary.
>>
>> Should the module import still be limited to exported packages? But then: 
>> exported to whom? Would a qualified export to some other module M2 hide that 
>> package from the module M itself (wrt the module import)?
>>
>> At least the requirement that M is read by M is satisfied, according to a 
>> comment in JLS 7.3.
>>
>> thanks,
>> Stephan
>>
>>
>> Am 26.04.24 um 12:07 schrieb Gavin Bierman:
>>> Dear experts:
>>> The first draft of a spec covering JEP 476 (Module Import Declarations (Preview))
>>> https://cr.openjdk.org/~gbierman/jep476/latest/ 
>>> <https://cr.openjdk.org/~gbierman/jep476/latest/>
>>> Feel free to contact me directly or on this list with any comments.
>>> Thanks
>>> Gavin
>>>> On 17 Apr 2024, at 19:58, Mark Reinhold <mark.reinhold at oracle.com> wrote:
>>>>
>>>> https://openjdk.org/jeps/476
>>>>
>>>>  Summary: Enhance the Java programming language with the ability to
>>>>  succinctly import all of the packages exported by a module. This
>>>>  simplifies the reuse of modular libraries, but does not require the
>>>>  importing code to be in a module itself. This is a preview language
>>>>  feature.
>>>>
>>>> - Mark
>>
>