15

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

    ModelDevice
    DataDevice
    

2nd Option

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

    com.myapp.model.Device
    com.myapp.data.Device
    

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

we are currently mixing both approaches and starting to have inconsistency

3
  • 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

4 Answers 4

23

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.

5

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.

3

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.

0

The standard Java classloaders don't support having multiple class with the same name.

This is what OSGI allows you to do. OSGI allows you to have multiple versions of the same class. Without going into the detail, an OSGI framework internally does some ClassLoader trickery to allow that to happen. You can even have two different versions of a class running at the same time. There's a learning curve to implementing an OSGI application. Most 3rd party open source jar files you can get from the internet are implemented as OSGI bundles. An OSGI bundle is a standard java jar file that contains osgi header information.

2
  • This doesn't make sense. You can perfectly well have classes with the same name, provided they aren't part of the same package.
    – CPlus
    Dec 2, 2023 at 1:22
  • I was referring to the fully qualified class name. I guess I didn't make that clear. Standard Java classlooaders don't support multiple classes with the same fully qualified name (package and class). My point is that you can do that in OSGI. They represent different versions, and both versions could be in use. There are rules to using different versions. This allows you to upgade a class used in one subsystem, without forcing you to upgrade all subsystems to accommodate a class revision.
    – Tom R
    Feb 28 at 21:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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