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