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 <[email protected]>
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
