module-import declaration

[Brian Goetz]

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.)

On 2/26/2024 12:53 PM, Tagir Valeev wrote:
> Hello!
>
> On Fri, Feb 23, 2024 at 4:18 PM Brian Goetz <brian.goetz at oracle.com> 
> wrote:
>
>     > Simple SQL examples with an "import java.sql.*" and a reference
>     to a class "Date" to not compile anymore.
>
>     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.
>
>
> I think, there still will be a standard way to disambiguate the 
> collision, which works with star-imports:
>
> import module java.base;
> import module java.sql;
> import java.util.Date;
>
> // Now, unqualified Date refers to java.util.Date, everybody is happy, 
> and the import table is still very compact.
>
> With best regards,
> Tagir Valeev.
>
>
>
>
>
>     On 2/23/2024 4:56 AM, Remi Forax wrote:
>>     Hello,
>>     I've just read the draft of the third version of the implicit class JEP
>>        https://openjdk.org/jeps/8323335
>>
>>     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240226/03aa5286/attachment-0001.htm>