<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="">
I think you missed the point, though. The point was not to reopen the debate; it was to help you realize that your opinion is just one of many, and the fact that you disagree doesn’t mean that the others are wrong (and that we should design the language around
deterring their wrongness.).
<div class=""><br class="">
</div>
<div class="">You seem very quick to dismiss opinions other than your own as “invalid” and therefore not worthy of learning from. I would suggest trying to acquire the ability to look at your own (seemingly very strong) opinions with the same degree of skepticism.
Otherwise, you will find a very difficult time convincing anyone to agree with you, which you will probably find frustrating. </div>
<div class=""><br class="">
</div>
<div class="">As a reminder, amber-dev is not the feature design list; if you are hoping to reopen the discussion, you have to come with arguments or data that are new. I hope that the discussion so far has convinced you that all of this has been said before,
and considered appropriately. (And “they didn’t agree with me” the same as “this was not considered appropriately.”)</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 10:23 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 dir="ltr" class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-size:small">Hi Brian,</div>
<div class="gmail_default" style="font-size:small"><br class="">
</div>
<div class="gmail_default" style="font-size:small">> - I like single imports because they feel more clear</div>
<div class="">
<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 class="">
</div>
<div class="">
<div class="gmail_default" style="font-size:small">> - I like star imports because they express the dependencies more abstractly</div>
<div class="">
<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 class="">
</div>
<div class="gmail_default" style="font-size:small">> - I like star imports because they make the code more compact</div>
<div class="">
<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 class="">
* 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 class="">
</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 class="">
</div>
<div class="gmail_default" style="font-size:small">Kind regards,</div>
<div class="gmail_default" style="font-size:small">Cristian</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</div>
<br class="">
<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" class="">brian.goetz@oracle.com</a>> wrote:<br class="">
</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;" class="">To illustrate that your view about star imports is merely one of many, have a look at
<div class=""><br class="">
</div>
<div class=""> <a href="https://urldefense.com/v3/__https://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad__;!!ACWV5N9M2RV99hQ!IROk1_ntj_34eXGUsBIXLP4QGJW9N1ZdcgFJ4EUMW9iUYE8tvRxXXVnZNI7eCwmu5U2hEIPsH7yoaYOKkQ$" target="_blank" class="">https://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad</a></div>
<div class=""><br class="">
</div>
<div class="">Summarizing the answers to this q (considering only answers with more than a few upvotes): </div>
<div class=""><br class="">
</div>
<div class=""> - Star imports are bad because they clutter the namespace with stuff you don’t need, and might conflict</div>
<div class=""> - I like single imports because they feel more clear</div>
<div class=""> - Star imports are bad because there are conflicts like java.util.List vs java.awt.List</div>
<div class=""> - I like star imports because they express the dependencies more abstractly</div>
<div class=""> - Even if there are no conflicts now, there could be conflicts arising later, which means star imports are less stable</div>
<div class=""> - I like star imports because they make the code more compact</div>
<div class=""><br class="">
</div>
<div class="">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 class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Nov 19, 2024, at 8:52 AM, Cristian Mocanu <<a href="mailto:cvmocanu@gmail.com" target="_blank" class="">cvmocanu@gmail.com</a>> wrote:</div>
<br class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-size:small">Hi Ron,</div>
<div class="gmail_default" style="font-size:small"><br class="">
</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 class="">
</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 class="">
</div>
<div class="gmail_default" style="font-size:small"><br class="">
</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 class="">
</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 class="">
</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 class="">
</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 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>
<br class="">
<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" class="">ron.pressler@oracle.com</a>> wrote:<br class="">
</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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
— Ron<br class="">
<br class="">
> On 19 Nov 2024, at 09:49, Cristian Mocanu <<a href="mailto:cvmocanu@gmail.com" target="_blank" class="">cvmocanu@gmail.com</a>> wrote:<br class="">
> <br class="">
> Hello,<br class="">
> <br class="">
> My name is Cristia Mocanu, and I am a Java developer with almost 20 years of experience.<br class="">
> <br class="">
> I was made aware of "JEP-476 module import" recently.<br class="">
> <br class="">
> I strongly recommend making sure this JEP is abandoned and never gets merged into Java.<br class="">
> 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 class="">
> 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 class="">
> <br class="">
> 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 class="">
> 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 class="">
> <br class="">
> With fewer words: this JEP has nasty disadvantages, without providing any real world benefit.<br class="">
> <br class="">
> Kind regards,<br class="">
> Cristian<br class="">
<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>