Me and my R&D team maintain a large codebase. We've divided our business logic into multiple packages. some of which have classes with identical names.

As you can guess, the names conflict when both classes are referenced in the same Java file.

For example:

com.myapp.model (package)
 - Device (class)
 - ...

com.myapp.data (package)
 - Device (class)
 - ...

We had a debate on what's the best practice to treat these cases and the following options came up:

1st Option

  • Renaming the class, adding a prefix


2nd Option

  • Using the full package+class name when both are referenced


What's more correct in terms of code management and scalability?

we are currently mixing both approaches and starting to have inconsistency

  • If it's occasional it probably does not matter - if it is a recurring pattern I would probably name the classes more precisely to prevent it from becoming a mess.
    – assylias
    Jan 17, 2016 at 23:39
  • You have no idea how much I loath java.util.Date and java.sql.Date - especially since java.sql.Date is a subclass of java.util.Date and so nicely slips out of data layers (and doesn't serialize nicely to JSON).
    – user40980
    Jan 19, 2016 at 19:16
  • Option 2.1 Always use the fully qualified name, even if the other is not referenced
    – Caleth
    Oct 19, 2018 at 14:34

3 Answers 3


Use the package name. This type of problem is precisely why Java uses the package naming convention that it does. It prevents these sorts of problems, whether it's two teams in the same company or two teams on opposite sides of the earth.


As of now you have one ModelDevice class (Device in the model package). What if you have another such ModelDevice for a different classification? The problem may still persist and the overheads will also continue to increase.

Though for the time being you may find that renaming classes be of some good help, for a long run the suggested alternate is to go by prefixing the package names, which is what the Industry Standard.


Just to add one aspect that hasn't been mentioned yet:

Have a look at the usage patterns, i.e. the Java sources that reference one or both classes.

IMHO, in the majority of cases, source files should reference only one of the conflicting classes, and from the context it should be clear whether they deal with the model or the data world. If that's difficult for any reason, I'd rename the classes, as I generally don't like package-prefixed class names in source code (it degrades readability).

If you have source files that deal with both worlds, they might be bridging classes with the resonsibility to translate between two different views of the world, and here I'd prefer to find package-prefixed class names.

But seeing both Device classes in one source might as well be a hint that the source violates the single-responsibility principle by mixing tasks from the model and the data world.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.