Java: Subpackage visibility?

Question

You can't. In Java there is no concept of a subpackage, so odp.proj and odp.proj.test are completely separate packages.

The names of your packages hint that the application here is for unit testing. The typical pattern used is to put the classes you wish to test and the unit test code in the same package (in your case odp.proj) but in different source trees. So you would put your classes in src/odp/proj and your test code in test/odp/proj.

Java does have the "package" access modifier which is the default access modifier when none is specified (ie. you don't specify public, private or protected). With the "package" access modifier, only classes in odp.proj will have access to the methods. But keep in mind that in Java, the access modifiers cannot be relied upon to enforce access rules because with reflection, any access is possible. Access modifiers are merely suggestive (unless a restrictive security manager is present).

Most of the answers here have stated that there is no such thing as a subpackage in Java, but that is not accurate. The term is defined in the Java Language Specification (JLS) and has been since the initial version of the specification.

Java 15 JLS:

The members of a package are its subpackages and all the top level class types and top level interface types declared in all the compilation units of the package.

For example, in the Java SE Platform API:

• The package java has subpackages awt, applet, io, lang, net, and util, but no compilation units.
• The package java.awt has a subpackage named image, as well as a number of compilation units containing declarations of class and interface types.

The subpackage concept has practical implications, as is enforces naming constraints between packages and classes/interfaces:

A package may not contain two members of the same name, or a compile-time error results.

Here are some examples:

• Because the package java.awt has a subpackage image, it cannot (and does not) contain a declaration of a class or interface type named image.
• If there is a package named mouse and a member type Button in that package (which then might be referred to as mouse.Button), then there cannot be any package with the fully qualified name mouse.Button or mouse.Button.Click.
• If com.nighthacks.java.jag is the fully qualified name of a type, then there cannot be any package whose fully qualified name is either com.nighthacks.java.jag or com.nighthacks.java.jag.scrabble.

However, this naming restriction is the only significance afforded to subpackages by the language:

The hierarchical naming structure for packages is intended to be convenient for organizing related packages in a conventional manner, but has no significance in itself other than the prohibition against a package having a subpackage with the same simple name as a top level type declared in that package.

For example, there is no special access relationship between a package named oliver and another package named oliver.twist, or between packages named evelyn.wood and evelyn.waugh. That is, the code in a package named oliver.twist has no better access to the types declared within package oliver than code in any other package.

---

With this context, we can answer the question itself. Since there is no special access relationship between a package and its subpackage, or between two different subpackages of a parent package, there is no way within the language to make a method visible to two different packages in the requested manner, while restricting its access from other packages. This is a documented, intentional design decision.

Either the method can be made public and all packages (including odp.proj and odp.proj.test) will be able to access the given methods, or the method could be made package private (the default visibility), and all the code that needs to directly access it must put in the same (sub)package as the method.

Regarding the test use case, a standard practice in Java is to put the test code for a type in the same package as its source code, but in a different location on the file system. For instance, in both the Maven and Gradle build tools, the convention would be to put the source files in src/main/java/odp/proj and the test files in src/test/java/odp/proj. When compiled by the build tool, the items in both directories end up in the odp.proj package, but only the src files are included in the production artifact; the test files are only used at build time to verify the production files. With this setup, test code can freely access any package private or protected code of the code it's testing, as they will be in the same package.

In the case where you want code sharing across subpackages or sibling packages that isn't the test/production case, one solution I've seen some libraries use is to put that shared code as public, but document that it is intended for internal library use only.

This is no special relation between odp.proj and odp.proj.test - they just happen to be named as apparently related.

If the odp.proj.test package is simply providing tests then you can use the same package name (odp.proj). IDEs like Eclipse and Netbeans will create separate folders (src/main/java/odp/proj and src/test/java/odp/proj) with the same package name but with JUnit semantics.

Note that these IDEs will generate tests for methods in odp.proj and create the appropriate folder for the test methods it doesn't exist.

When I do this in IntelliJ, my source tree looks like this:

src         // source root
- odp
   - proj   // .java source here
- test      // test root
  - odp
     - proj // JUnit or TestNG source here

As others have explained, there is no such thing as a "subpackage" in Java: all packages are isolated and inherit nothing from their parents.

An easy way to access protected class members from another package is to extend the class and override the members.

For instance, to access ClassInA in package a.b:

package a;

public class ClassInA{
    private final String data;

    public ClassInA(String data){ this.data = data; }

    public String getData(){ return data; }

    protected byte[] getDataAsBytes(){ return data.getBytes(); }

    protected char[] getDataAsChars(){ return data.toCharArray(); }
}

make a class in that package that overrides the methods you need in ClassInA:

package a.b;

import a.ClassInA;

public class ClassInAInB extends ClassInA{
    ClassInAInB(String data){ super(data); }

    @Override
    protected byte[] getDataAsBytes(){ return super.getDataAsBytes(); }
}

That lets you use the overriding class in place of the class in the other package:

package a.b;

import java.util.Arrays;

import a.ClassInA;

public class Driver{
    public static void main(String[] args){
        ClassInA classInA = new ClassInA("string");
        System.out.println(classInA.getData());
        // Will fail: getDataAsBytes() has protected access in a.ClassInA
        System.out.println(Arrays.toString(classInA.getDataAsBytes()));

        ClassInAInB classInAInB = new ClassInAInB("string");
        System.out.println(classInAInB.getData());
        // Works: getDataAsBytes() is now accessible
        System.out.println(Arrays.toString(classInAInB.getDataAsBytes()));
    }
}

Note that this only works for protected members, which are visible to extending classes (inheritance), and not package-private members which are visible only to sub/extending classes within the same package. Hopefully this helps someone!

EDIT: If there is no concept of a subpackage in Java, is there any way around this? I have certain methods that I want to be available only to testers and other members of that package.

It probably depends a bit on your motives for not displaying them but if the only reason is that you don't want to pollute the public interface with the things intended only for testing (or some other internal thing) I would put the methods in a separate public interface and have the consumers of the "hidden" methods use that interface. It will not stop others from using the interface but I see no reason why you should.

For unit tests, and if it is possible without rewriting the lot, follow the suggestions to use the same package.