I assume it is because Java developers rely very heavily on their IDEs. Most of these IDEs simply hide the import statements by default. So you assume the imports are irrelevant, unless explicitly spelled out - and clashes are rare enough to not be much of a problem in practice. If imports are renamed, you would have to actually care about the import statements.

> If imports are renamed, you would have to actually care about the import statements.

Not really. VS Code transparently handles aliasing of imports in JS. You still never need to look at them manually AND you get the benefit of cleaner naming.

I have difficulty seeing what this would add. As a Java developer, I know what "List" is, just like I know what "ArrayList" is. If someone instantiated new better.ArrayList(), I immediately have to check what the hell is the import (go to the top of the class, uncollapse the import statements, and see what is "better").

As with all code readability, I assume to write and use import aliases, that's very easy. The person who's gonna read it after you, they've got a problem. And that's why I'd personally be strongly against this in my code review.

Using the example from your other reply:

import java.awt.List as awtList

import java.util.List as utilList

Granted, there's not a lot of scenarios where you have this sort of collision, but it does happen and using aliasing makes the code easier to read.

> As a Java developer, I know what "List" is

Is that java.awt.List or java.util.List?

That's a real problem that I've encountered. There were three web services which I consumed. They used a lot of classes with the same name and I had to work with them from one class. I had to use fully qualified names everywhere. At one point I rewrote this code using Kotlin. Kotlin had this feature, you could write "import com.package.foo.bar" and you could use "bar.Something" in your code. My code was sane. But in some release they decided to remove that feature for some reason.

You can still write

  import com.package.foo.bar.Something as barSomething

according to the documentation: https://kotlinlang.org/docs/reference/packages.html

Although you'd have to do it for each class, so importing the whole package with an alias would be nice.

What do you mean? You can do both:

- import com.package.foo.Bar -> use Bar.methodOfBar() in code

- import static com.package.foo.Bar -> use methodOfBar() in code

What does "import com.package.foo.bar as bar" add? Other than some kind of aliasing, as in you import Bar, but alias it as Baz, so then you use Baz.methodOfBar() ..?

I think he's saying:

    import java.util as jvutil;
    import com.betterlist as better;

    class Example {
      jvutil.List list = new better.List();
    }