<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Thanks Stephan.
<div><br>
</div>
<div>Indeed; that bug got fixed reasonably recently <a href="https://bugs.openjdk.org/browse/JDK-8332890">https://bugs.openjdk.org/browse/JDK-8332890</a> :-)</div>
<div><br>
</div>
<div>Gavin<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 25 May 2024, at 16:12, Stephan Herrmann <stephan.herrmann@berlin.de> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>Hi Gavin,<br>
<br>
Thanks for clarifications.<br>
<br>
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?<br>
<br>
Looking at your answer my reaction now was: sure why should module-info mention types that are not exported?<br>
<br>
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).<br>
<br>
Next I tried this with javac 23-ea build 24, with these results:<br>
- module import in module-info doesn't seem to be evaluated yet<br>
- importing the current module (anywhere) gives<br>
"module mtest does not read: mtest" :)<br>
<br>
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.<br>
<br>
thanks,<br>
Stephan<br>
<br>
<br>
Am 24.05.24 um 15:36 schrieb Gavin Bierman:<br>
<blockquote type="cite">Hi Stephan,<br>
Thanks for your email. Yes, example 7.5.5-2 is missing information to make it more intelligible; sorry about that.<br>
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.<br>
More concretely, consider this slight expansion of the example:<br>
importmodule M;<br>
module M {<br>
exports p1 to M1;<br>
exports p2;<br>
exports p3 to M;<br>
usesC;<br>
}<br>
The effect of the import module M declaration is to bring in:<br>
1. Package p2, because it's exported by M to all comers, including M; and<br>
2. Package p3, because it's exported in a qualified fashion to M.<br>
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!):<br>
//A.java<br>
package p1;<br>
class A {}<br>
//B.java<br>
package p2;<br>
class B {}<br>
//C.java<br>
package p3;<br>
class C {}<br>
//module-info.java<br>
import module M;<br>
module M {<br>
exports p1 to M1;<br>
exports p2;<br>
exports p3 to M;<br>
uses A; // error<br>
uses B; // ok<br>
uses C; // ok<br>
}<br>
Hope this helps, and thanks once again. I’ll clarify the spec.<br>
Gavin<br>
<blockquote type="cite">On 18 May 2024, at 14:33, Stephan Herrmann <stephan.herrmann@berlin.de> wrote:<br>
<br>
Hi Gavin,<br>
<br>
I'm having difficulties interpreting this example:<br>
<br>
import module M;<br>
module M {<br>
...<br>
uses C;<br>
...<br>
}<br>
<br>
Literal interpretation would suggest that this imports<br>
"all the public top level classes and interfaces in the following packages:<br>
* The packages exported by the module M to module M. ..."<br>
<br>
The notion of exporting to self does not seem to be defined, is it?<br>
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.<br>
<br>
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)?<br>
<br>
At least the requirement that M is read by M is satisfied, according to a comment in JLS 7.3.<br>
<br>
thanks,<br>
Stephan<br>
<br>
<br>
Am 26.04.24 um 12:07 schrieb Gavin Bierman:<br>
<blockquote type="cite">Dear experts:<br>
The first draft of a spec covering JEP 476 (Module Import Declarations (Preview))<br>
https://cr.openjdk.org/~gbierman/jep476/latest/ <https://cr.openjdk.org/~gbierman/jep476/latest/><br>
Feel free to contact me directly or on this list with any comments.<br>
Thanks<br>
Gavin<br>
<blockquote type="cite">On 17 Apr 2024, at 19:58, Mark Reinhold <mark.reinhold@oracle.com> wrote:<br>
<br>
https://openjdk.org/jeps/476<br>
<br>
Summary: Enhance the Java programming language with the ability to<br>
succinctly import all of the packages exported by a module. This<br>
simplifies the reuse of modular libraries, but does not require the<br>
importing code to be in a module itself. This is a preview language<br>
feature.<br>
<br>
- Mark<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>