Kurshit
Kurshit

Reputation: 143

JAVA: Conflicts with Same Package and class names present under different Source folders

I am facing a conflict with class and package names that have same name under different source. In a nutshell, the directory structure looks somewhat like this:

src/test/java
    com.service.helper
        Constants.java

src/intTest/java
    com.service.helper
        Constants.java
    com.service.utility
        SomethingTest.java

The few constant strings defined in both Constants.java are same and few are exclusive to these classes. Now I have a SomethingTest.java file under src/intTest/java which should utilize Constants.java defined under src/intTest/java.

However, it seems it is using Constants.java file which is defined under src/test/java package. Thus, I am not able to use constant string defined in Constants.java under src/intTest/java file.

Could anyone please give any clarity why is it so? Can I really access Constants.java defined under src/intTest/java, without changing package structure of current file names?

Appreciate the help. Thanks.

Upvotes: 4

Views: 4427

Answers (2)

Maciej
Maciej

Reputation: 2004

You have 2 choices here:

  1. rename Constants to IntConstants (to be unique)
  2. (recommended) put intTest (I guess it's integration test) to it's own package.

Choice 2 is recommended as integration tests does not need to be in the same package as tested class, as it just tests public API of you application and do not need access to any package-scope variables. If it's otherwise in your case, please consider refactoring your code to align it with good practice, and do not expose internal state outside. Putting integration tests to different package helps to keep this practice.

Upvotes: 2

GhostCat
GhostCat

Reputation: 140641

The identity of a Java class is its "absolute" name, as in x.y.z.SomeClass. When you have two classes that have absolute identical package and class names, then "java" isn't able to distinguish them.

In other words: this is bad practice. You really want to avoid such situations. The solution is not to work around "my tool is complaining" but organize your source code in ways that are more in line with "standard java conventions".

In other words: the best thing to do would be to either rename some of the packages, or make sure to have unique class names.

Upvotes: 4

Related Questions