<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4" face="monospace">(I think we've had this discussion
already? Seems eerily familiar.)<br>
<br>
I realize that some people think star-imports are a bad idea, and
some style guides recommend against it. But these are
preferences, which make sense in certain situations, and not in
others. <br>
<br>
This argument goes: since star imports are bad, adding even more
powerful star imports is definitely bad. But the premise is
flawed, so this argument does not hold.<br>
<br>
_The judge rules that "star imports are bad" arguments are
inadmissible in this case._<br>
<br>
As a thought experiment, if we had modules from Java 1.0, would we
have stopped at package-star imports and not module-star imports?
This seems unlikely. Packages and modules are tools for grouping
related classes, which are likely to be used together. Saying "I
want to use facility X" is an entirely reasonable thing. Some
facilities are packaged in a single package, so existing
star-import works for them, but some are spread out over several
packages that are almost always imported together (look at any
"how to use Jackson" article, and you'll see that you have to
import at least from jackson.core and jackson.databind to get much
done.) Arguably we should have added module-star imports in 9,
but this was impractical given the constraints at the time. <br>
<br>
Turning to the "does it help beginners / simple programs"
question, modules are a more sensible granularity of imports for
simple programs. Such a program would prefer to say "I want to
use Jackson", not "I want to use these three Jackson packages", or
"I want to use these seventeen Jackson classes." <br>
<br>
As to the "onramp" angle, imports and packages are yet another
program-structuring tool that benefits larger programs. Having to
learning them on day one is counterproductive. <br>
<br>
</font><font size="4" face="monospace">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
</font><font size="4" face="monospace"><br>
(I think I've asked you before to keep away from the cheap
high-school-debating tricks...) This is a misuse of "unlearn".
Unlearning in this context refers to a dead-end convenience, which
hides what is going on but can't be used for more than the
simplest cases, and therefore has to be completely discarded and
the user starts over. (This is an onramp to the wrong highway.)
But this most surely isn't that.<br>
<br>
Users can progress smoothly from "implicit java.base import" ->
"explicit java.base import" -> "explicit package import" ->
"explicit class import" as the more fine-grained tools start to
add value. But I suspect it will be a long time for most users
before they would ever have to go past module imports; seeing a
list of module imports at the top is a pretty clear statement of
what the classes dependencies are. I don't see anything to
unlearn here, ever; all I see is a simple form that can naturally
be expanded to a fussier form as the specificity of the fussy form
is needed, and which is revealed to be little more than said
expansion. <br>
<br>
> 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>
<br>
<br>
<br>
</font><br>
<div class="moz-cite-prefix">On 2/23/2024 4:56 AM, Remi Forax wrote:<br>
</div>
<blockquote type="cite" cite="mid:1763566181.13617007.1708682168799.JavaMail.zimbra@univ-eiffel.fr">
<pre class="moz-quote-pre" wrap="">Hello,
I've just read the draft of the third version of the implicit class JEP
<a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/8323335">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>
</body>
</html>