<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4" face="monospace">Yes, this is exactly as I expected
      it would work.  Just as single-import takes precedence over
      on-demand package import, it would do so over on-demand module
      import as well (since the latter is just a "macro" for a bunch of
      on-demand package imports.)  </font><br>
    <br>
    <div class="moz-cite-prefix">On 2/26/2024 12:53 PM, Tagir Valeev
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAE+3fjaDaxF5j366QvP_+xp8JXdnAwO8moTuDPAcg63veuVnrw@mail.gmail.com">
      
      <div dir="ltr">
        <div>Hello!</div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Fri, Feb 23, 2024 at
            4:18 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div><font size="4" face="monospace">> Simple SQL
                examples with an "import java.sql.*" and a reference to
                a class "Date" to not compile anymore.<br>
                <br>
                Yes, it is unfortunate that there is this collision in
                java.base.  But this argument is not compelling; I have
                yet to see a program that imports java.sql.* that
                doesn't also import java.util.*.  So every user has to
                navigate this collision anyway.  <br>
                <br>
              </font></div>
          </blockquote>
          <div><br>
          </div>
          <div>I think, there still will be a standard way to
            disambiguate the collision, which works with star-imports:</div>
          <div><br>
          </div>
          <div>import module java.base;</div>
          <div>import module java.sql;</div>
          <div>import java.util.Date;</div>
          <div><br>
          </div>
          <div>// Now, unqualified Date refers to java.util.Date,
            everybody is happy, and the import table is still very
            compact.</div>
          <div><br>
          </div>
          <div>With best regards,</div>
          <div>Tagir Valeev.</div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div><font size="4" face="monospace"> <br>
                <br>
                <br>
              </font><br>
              <div>On 2/23/2024 4:56 AM, Remi Forax wrote:<br>
              </div>
              <blockquote type="cite">
                <pre>Hello,
I've just read the draft of the third version of the implicit class JEP
  <a href="https://openjdk.org/jeps/8323335" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/jeps/8323335</a>

There is a funny paragraph about why there is a need for an import module syntax.

"""
One theme of this JEP is the elegant evolution of simple programs to proper declared classes that can reside in larger codebases; there is no beginners' dialect that must be translated away. In other words, it should be simple to evolve an implicitly declared class to an explicitly declared class. As implicitly declared classes automatically import (as needed) all the accessible classes and interfaces of every exported package in the module java.base, there should be a way to specify this in a traditional compilation unit with explicit class declarations.

To this end, we add a new kind of import declaration: the module-import declaration. It imports (as needed) all the accessible classes and interfaces of every exported package in a given module.
"""

So the thought process is: we do not want a dialect for beginners, but we want an import all, so we are introducing a feature nobody ask for, called module-import so look, this is not a dialect, this is an implicit import-module java.base.

That's a funny !


Taking a step back, I'm not sure that the idea of an "import all" is even a good idea.

It makes the notion that classes are organized in packages hidden so the notion of package documentation (important for beginners) disappear.
Simple SQL examples with an "import java.sql.*" and a reference to a class "Date" to not compile anymore.
We know that import * has a bad behavior when upgrading dependencies, so hidding many import * behind a new import-module syntax means students will have to unlearn import-module later.

regards,
Rémi
</pre>
              </blockquote>
              <br>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>