<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Brian,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">>  - I like single imports because they feel more clear</div><div><div class="gmail_default" style="font-size:small">Invalid. How does knowing less feel clearer? Less code is not always easier to understand.</div><br></div><div><div class="gmail_default" style="font-size:small">>  - I like star imports because they express the dependencies more abstractly</div><div><div class="gmail_default" style="font-size:small">How is this a benefit worth having more confusing code? What is the exact benefit?</div><br></div><div class="gmail_default" style="font-size:small">>  - I like star imports because they make the code more compact</div><div><div class="gmail_default" style="font-size:small">Totally invalid!</div><div class="gmail_default" style="font-size:small">Junior developers don't understand that more compact code comes in 2 kinds:<br>* the kind that makes the code easier to understand</div><div class="gmail_default" style="font-size:small">* the kind that makes the code harder to understand</div><div class="gmail_default" style="font-size:small">Having to write the types when declaring variables or fields makes the code less compact, but more readable at the same time.</div><br></div><div class="gmail_default" style="font-size:small">> Which is to say, opinions are all over the map</div><div class="gmail_default" style="font-size:small">Agreed, but not all opinions are valid :)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Kind regards,</div><div class="gmail_default" style="font-size:small">Cristian</div><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Nov 2024 at 15:22, Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div style="overflow-wrap: break-word;">
To illustrate that your view about star imports is merely one of many, have a look at 
<div><br>
</div>
<div>    <a href="https://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad" target="_blank">https://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad</a></div>
<div><br>
</div>
<div>Summarizing the answers to this q (considering only answers with more than a few upvotes): </div>
<div><br>
</div>
<div> - Star imports are bad because they clutter the namespace with stuff you don’t need, and might conflict</div>
<div> - I like single imports because they feel more clear</div>
<div> - Star imports are bad because there are conflicts like java.util.List vs java.awt.List</div>
<div> - I like star imports because they express the dependencies more abstractly</div>
<div> - Even if there are no conflicts now, there could be conflicts arising later, which means star imports are less stable</div>
<div> - I like star imports because they make the code more compact</div>
<div><br>
</div>
<div>Which is to say, opinions are all over the map, and even among star-import haters, the reasons are mostly not about readability, but about conflict management and stability.</div>
<div>
<div><br>
<blockquote type="cite">
<div>On Nov 19, 2024, at 8:52 AM, Cristian Mocanu <<a href="mailto:cvmocanu@gmail.com" target="_blank">cvmocanu@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">Hi Ron,</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Sorry, I incorrectly assumed that the problem is well known.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">You stated it almost correctly: "if a file has `import module a; import module b;` and it uses the type `X`, you would need to search both `a` and `b` to find the documentation for `X` when reading the code,
 rather than just one of them (if we had, say, import X from module a`)".<br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">To make the problem clearer - if I see class X, and I'm not sure from which module it comes from, I need to manually open the source code of all imported modules, and check if they contain the class.</div>
<div class="gmail_default" style="font-size:small">Or, much simpler, open the Java file in an IDE, and check there from what module it comes.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">You're referring to documentation, but I would like to broaden the problem a bit.</div>
<div class="gmail_default" style="font-size:small">To lookup documentation, I would just use my IDE, which would "know" which module X is coming from.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">The basic problem is that it's no longer obvious where X is coming from, only by looking at the source code. For example, if you see `StringUtils`, you can't tell whether it comes from Spring, or Apache Commons
 Lang, or Micrometer, or Apache Commons Codec, or Logback Logstash Encoder, or some other library - it can be any one of the module imports.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Knowing that code is being read many time more often than written, I don't think it makes sense to optimize writing an import by hand (which no one does anyway - the IDE writes it for us) to the detriment of
 introducing confusion when reading the code outside an IDE (like a GitHub PR review).</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Kind regards,</div>
<div class="gmail_default" style="font-size:small">Cristian</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 19 Nov 2024 at 14:39, Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi.<br>
<br>
Merely stating that you you believe some feature to be harmful is not helpful feedback, because we already take it as a given that there are many features that some people strongly believe are very useful while others believe just as strongly to be harmful.
 Such a statement provides no actionable information.<br>
<br>
What could be helpful is trying to precisely articulate a problem you’ve run into. For example, if a file has `import module a; import module b;` and it uses the type `X`, you would need to search both `a` and `b` to find the documentation for `X` when reading
 the code, rather than just one of them (if we had, say, import X from module a`). Is that the problem you’re referring to? Why does it make reading the code so much more difficult for you?<br>
<br>
— Ron<br>
<br>
> On 19 Nov 2024, at 09:49, Cristian Mocanu <<a href="mailto:cvmocanu@gmail.com" target="_blank">cvmocanu@gmail.com</a>> wrote:<br>
> <br>
> Hello,<br>
> <br>
> My name is Cristia Mocanu, and I am a Java developer with almost 20 years of experience.<br>
> <br>
> I was made aware of "JEP-476 module import" recently.<br>
> <br>
> I strongly recommend making sure this JEP is abandoned and never gets merged into Java.<br>
> 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).<br>
> 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).<br>
> <br>
> 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.<br>
> 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.<br>
> <br>
> With fewer words: this JEP has nasty disadvantages, without providing any real world benefit.<br>
> <br>
> Kind regards,<br>
> Cristian<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>

</blockquote></div>