<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
This mail would have benefited from some additional thought before writing (and especially before turning the “this is a disaster” knob to 11 or trotting out the overused trope of “considered harmful”.)
<div class=""><br class="">
</div>
<div class="">Yes, OF COURSE some people dislike star imports, and with some vaiid reasons, including the ones you raise. Did you think that there was even a tiny chance that we were not aware of this? Someone of your extensive experience should be able to
go through the thought process of:</div>
<div class=""><br class="">
</div>
<div class=""> - I think this is a bad idea</div>
<div class=""> - But, smart people who think deeply about language evolution and its impact on the world of code through about it for a long time and came to a different conclusion</div>
<div class=""> - Perhaps there is more to it than I think, I should inquire </div>
<div class=""><br class="">
</div>
<div class="">before writing such a jumping-to-disaster mail. (I think also you misunderstand the motivation for why most style guides disrecommend star imports; it is not primarily readability, as no one in the real world actually reads imports, and questions
of “where is this class” are well handled by IDEs; the primary motivation is usually stability, which comes from its explicitness.)</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">So yes, all of these arguments were well understood from the outset, and were discussed during the design process. What is missing from the “but of course everyone knows this” analysis is that the concerns over star imports have a context: code
that has reached the mature phase of its lifecycle, and for which stability has become the most important consideration. Within that context, these concerns are valid, but this context does not remotely cover the whole experience of writing Java code. </div>
<div class=""><br class="">
</div>
<div class="">Some of the countervailing considerations included:</div>
<div class=""><br class="">
</div>
<div class=""> - Single-class imports have tradeoffs that go beyond the mere “typing less”. It also means _reading less_; not having to grovel through hundreds of import lines to get a sense of the dependencies. Java developers complain about this as an aspect
of Java’s “boilerplate”.</div>
<div class=""> - For new code (or new developers), the fussiness of imports is an impediment to getting things done. The arguments about stability do not apply here, and enforcing them “for your own good” seems almost kind of mean. </div>
<div class=""> - For codebases that prefer single imports, automated refactoring is widely available, so starting out with module or package imports is not creating a long-term problem.</div>
<div class=""> - Expressing a dependency on a package or module is a more abstract statement than a single class. </div>
<div class=""> - Expressing a dependency on a module is _intrinsically more sensible_ than expressing it on all (or most) of the packages in a module. Users who want to “use Jackson” have to grovel through tutorials to figure out which packages to import.
</div>
<div class=""> - Having modules be the unit of dependency, but packages be the unit of import, is an accidental asymmetry that should be corrected. Most modules (java.base notwithstanding) have a single purpose an a single “import module com.foo.WhizzyJsonParser”
is a clear statement of semantic intent. In fact, this is sometimes a _clearer_ statement of intent than importing all the individual classes. </div>
<div class=""> - Even within the context of stable, mature code, dealing with emergent name clashes requires only trivial remediation. So even such codebases may prefer the more abstract expression of module dependency because the costs of mitigating the resulting
instability is low.</div>
<div class=""> - The preference of some for star imports is a preference; this isn’t really a good argument for “so no one should be allowed to code like this"</div>
<div class=""><br class="">
</div>
<div class="">Which is to say, _sometimes_ the benefits of star imports do not exceed their costs. And in those cases, you are correct, you should not use them! But that doesn’t make them intrinsically bad, or mean that we should force single-import on all
users because they are not ideal in all contexts. </div>
<div class=""><br class="">
</div>
<div class="">Finally, one more point on the sky-is-falling rhetoric: it’s not helpful. We saw this with local variable type inference (var); many developers catastrophized loudly that this would destroy the readability of Java code, but that didn’t happen.
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 19, 2024, at 4:49 AM, Cristian Mocanu <<a href="mailto:cvmocanu@gmail.com" class="">cvmocanu@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-size:small">Hello,</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">My name is Cristia Mocanu, and I am a Java developer with almost 20 years of experience.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">I was made aware of "JEP-476 module import" recently.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">I strongly recommend making sure this JEP is abandoned and never gets merged into Java.</div>
<div class="gmail_default" style="font-size:small">The reason is that a module import shares the same problem with the star import: it makes the code much more difficult to understand without an IDE (e.g. when reviewing a PR on GitHub).</div>
<div class="gmail_default" style="font-size:small">The problem with the star import is so bad, that many official code styles, and many teams I worked in, explicitly forbid star imports, making the build fail if one is found (i.e. by using Checkstyle's AvoidStarImport
rule).</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">The module import, just like the star import, will have the very bad effect of encouraging people to write code that is difficult to understand.</div>
<div class="gmail_default" style="font-size:small">The advantage would be that the VIM guy can type less when writing a Java file. Don't get me wrong, I use VIM myself (even the IdeaVim plugin), but the last time I wrote an import manually was probably 15 years
ago - in the real world, we type the class name, and IntelliJ or some other IDE writes the import for us.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">With fewer words: this JEP has nasty disadvantages, without providing any real world benefit.</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">Kind regards,</div>
<div class="gmail_default" style="font-size:small">Cristian</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>