4 ms·

Can someone explain to me why java has never considered as "import com.package.foo.bar as bar" feature? I really think fully qualified names can be disgusting w

Can someone explain to me why java has never considered as "import com.package.foo.bar as bar" feature? I really think fully qualified names can be disgusting when you have two classes of the same name.

halfastack 8y ago
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() ..?
- kbsletten 8y ago
  I think he's saying: import java.util as jvutil; import com.betterlist as better; class Example { jvutil.List list = new better.List(); }
hyperman1 8y ago
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.
- idontpost 8y ago
  > 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.
  - halfastack 8y ago
    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.
    - ptx 8y ago
      > As a Java developer, I know what "List" is Is that java.awt.List or java.util.List?
    - idontpost 8y ago
      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.
vbezhenar 8y ago
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.
- ptx 8y ago
  You can still write import com.package.foo.bar.Something as barSomething according to the documentation: https://kotlinlang.org/docs/reference/packages.html 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.

halfastack 8y ago

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() ..?

kbsletten 8y ago
I think he's saying: import java.util as jvutil; import com.betterlist as better; class Example { jvutil.List list = new better.List(); }

hyperman1 8y ago

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.

idontpost 8y ago
> 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.
- halfastack 8y ago
  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.
  - ptx 8y ago
    > As a Java developer, I know what "List" is Is that java.awt.List or java.util.List?
  - idontpost 8y ago
    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.

vbezhenar 8y ago

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.

ptx 8y ago
You can still write import com.package.foo.bar.Something as barSomething according to the documentation: https://kotlinlang.org/docs/reference/packages.html 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.