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

[Gavin Bierman]

Thanks Stephan.

Indeed; that bug got fixed reasonably recently https://bugs.openjdk.org/browse/JDK-8332890 :-)

Gavin

On 25 May 2024, at 16:12, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240527/5a09e03f/attachment-0001.htm>