Geek Answers Handbook

Collision name in java import

If we change the compiler , Java skips the import X as Y syntax, which would be useful in cases like mine: at this very moment I am working on a project that has several classes with the same name but belonging to different packages.

I would like to have something like

 import com.very.long.prefix.bar.Foo as BarFoo import org.other.very.long.prefix.baz.Foo as BazFoo class X { BarFoo a; BazFoo b; ... }

Instead, I end up with something like

 class X { com.very.long.prefix.bar.Foo a; org.other.very.long.prefix.baz.Foo b; ... }

This looks pretty harmful here, but in my particular case I need to use horizontal scrolling to view the source code, and this means that exacerbates a program that is already a mess.

In your experience, what are the best practices in this case?

+6
source share
5 answers

I feel your pain, no matter what solution you use, the fact that there are two classes with the same name is rather confusing.

There are several solutions. :

  • If this is your code, just rename one of them (or both)
  • If this library (more likely) imports a more frequently used class, fully qualify the other, as suggested by Jeff Olson.
  • Try to avoid them in the same class if possible.
  • You can write your own BarFoo and BazFoo that do nothing but extend their respective Foo classes, thereby providing them with their own names. You can define them as inner classes. Example:
 private BarFoo extends com.very.long.prefix.bar.Foo{ //nothing, except possibly constructor wrappers } private BazFoo extends com.very.long.prefix.bar.Foo{ //nothing, except possibly constructor wrappers } class X { BarFoo a; BazFoo b; //... }

There are some disadvantages:

  • You will need to override the constructors
  • It will not be the same class if you need to pass it to a function that explicitly checks its getClass .

You can solve these shortcomings by wrapping Foo classes rather than extending them, for example:

 private BarFoo { public com.very.long.prefix.bar.Foo realFoo; } private BazFoo extends com.very.long.prefix.bar.Foo{ public com.very.long.prefix.baz.Foo realFoo; } class X { BarFoo a; BazFoo b; //now if you need to pass them someMethodThatTakesBazFoo(b.realFoo); }

Choose the simplest solution and good luck with it!

+8
source

Best practice is code refactoring.

Or classes should not have the same name, because they are normal to use them as in the same classes, and therefore choosing the same name for both options is not reasonable. Therefore, at least one of them should be renamed.

Or it’s not normal to use them as in the same classes, because they relate to completely different levels of abstraction (for example, the database access code and the UI code, for example), and the code should be reorganized to use each class, where it should be used and not elsewhere.

+5
source

What I usually did in these situations was to import the most commonly used Foo in my class, and then fully qualify the other:

 import com.very.long.prefix.bar.Foo class X { Foo a; org.other.very.long.prefix.baz.Foo b; ... }
+4
source

OP is here.

Over time, I developed a strategy to address this limitation of the Java language. I don’t know if this has flaws (I have never found them so far), but if so, please comment on this question.

The idea is to replace the last part of a fully qualified name with a class instead of a package and have the actual classes defined as static inner classes.

 class Bar { static class Foo { ... } }

So we have something like

 import fqnBar import other.fqnBaz ... Bar.Foo a; Bar.Foo b;

This is actually a very clean way to do this. Of course, this only applies to classes that you control, not libraries.

Known disadvantages

+1
source

You might want to check out Kotlin , which is compatible with Java.

If there is a clash of names in Kotlin, you can eliminate the ambiguity by using the local renaming of the associated object as a keyword:

 import foo.Bar // Bar is accessible import bar.Bar as bBar // bBar stands for 'bar.Bar'

Further information can be found at https://kotlinlang.org/docs/reference/packages.html

+1
source

More articles:


All Articles