[External] : Re: JEP-476 module import considered harmful

[Ron Pressler]

This is, indeed, a well-known opinion. But the opposite opinion, which is also well-known, can be argued just as well: X can only come from either module `a` or module `b` but not both, and if you don’t already know X and want to understand the code, you’ll spend much more time learning X’s documentation — with the help of an IDE or without — than finding it; this effort will need to be repeated by anyone reading the code who doesn’t know what X does. You may counter that the extra time spent finding the documentation is not worth it, to which the other side will respond that a great many projects are not reviewed by strangers who are unfamiliar with the types used, and so there’s no point adding noise for the sake of reviewers who don’t exist. This debate can go on and on, with well-reasoned arguments on both sides.

If there is one universal in programming, it is that experienced developers often disagree on what’s right, each finding their own arguments more convincing than others'. Sometimes the language designers find one side’s arguments decisively more convincing (at least in the context of Java language features), but this is not one of those times, and so, those who dislike module or star imports are welcome to not them.

If, after having used the feature, you find a problem that you believe has not been recognised by the designers (that you assumed the problem you pointed out is well-known suggests that you do not believe that to be the case here) then that would be a valuable report. Otherwise, rehashing the arguments in favour of either side of an old controversy is not helpful, as it doesn’t offer any new information.

— Ron

> On 19 Nov 2024, at 13:52, Cristian Mocanu <cvmocanu at gmail.com> wrote:
> 
> Hi Ron,
> 
> Sorry, I incorrectly assumed that the problem is well known.
> 
> 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`)".
> 
> 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.
> Or, much simpler, open the Java file in an IDE, and check there from what module it comes.
> 
> You're referring to documentation, but I would like to broaden the problem a bit.
> To lookup documentation, I would just use my IDE, which would "know" which module X is coming from.
> 
> 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.
> 
> 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).
> 
> Kind regards,
> Cristian
> 
> On Tue, 19 Nov 2024 at 14:39, Ron Pressler <ron.pressler at oracle.com> wrote:
> Hi.
> 
> 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.
> 
> 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?
> 
> — Ron
> 
> > On 19 Nov 2024, at 09:49, Cristian Mocanu <cvmocanu at gmail.com> wrote:
> > 
> > Hello,
> > 
> > My name is Cristia Mocanu, and I am a Java developer with almost 20 years of experience.
> > 
> > I was made aware of "JEP-476 module import" recently.
> > 
> > I strongly recommend making sure this JEP is abandoned and never gets merged into Java.
> > 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).
> > 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).
> > 
> > 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.
> > 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.
> > 
> > With fewer words: this JEP has nasty disadvantages, without providing any real world benefit.
> > 
> > Kind regards,
> > Cristian
>