By Nick Heiner

2009-12-27 22:28:56 8 Comments

I have two packages in my project: odp.proj and odp.proj.test. There are certain methods that I want to be visible only to the classes in these two packages. How can I do this?

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. Should I just throw everything into the same package? Use extensive reflection?


@starblue 2009-12-27 22:32:27

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

@JacksOnF1re 2016-05-26 21:39:29

Although I like it this way, it's confusing that most IDEs put packages with the same name together. Thanks for clarification.

@M. Justin 2020-01-28 20:45:51

This is not strictly accurate: the JLS does define subpackages, though the only language significance they have is to prohibit "against a package having a subpackage with the same simple name as a top level type". I have just added an answer to this question explaining this in detail.

@M. Justin 2020-01-28 20:43:29

Most of the answers here have stated that there is no such thing as a subpackage in Java, but that is not strictly accurate. This term has been in the Java Language Specification as far back as Java 6, and probably further back (there does not seem to be a freely accessible version of the JLS for earlier versions of Java). The language around subpackages hasn't changed much in the JLS since Java 6.

Java 13 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 is relevant, 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 is the fully qualified name of a type, then there cannot be any package whose fully qualified name is either or

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 explicitly 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. 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.

That said, a very standard practice in Java is to put the test code in the same package as the source code, but in a different location on the file system. For instance, in the Maven build tool, the convention would be to put these source and test files in src/main/java/odp/proj and src/test/java/odp/proj, respectively. When the build tool compiles this, both sets of files 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.

@ndm13 2018-01-11 18:36:36

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){ = 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); }

    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");
        // Will fail: getDataAsBytes() has protected access in a.ClassInA

        ClassInAInB classInAInB = new ClassInAInB("string");
        // Works: getDataAsBytes() is now accessible

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!

@qxo 2017-04-01 07:51:48

With the PackageVisibleHelper class, and keep it private before PackageVisibleHelperFactory frozen, we can invoke the launchA(by PackageVisibleHelper ) method in anywhere:)

package odp.proj;
public class A
    void launchA() { }

public class PackageVisibleHelper {

    private final PackageVisibleHelperFactory factory;

    public PackageVisibleHelper(PackageVisibleHelperFactory factory) {
        this.factory = factory;

    public void launchA(A a) {
        if (factory == PackageVisibleHelperFactory.INSTNACNE && !factory.isSampleHelper(this)) {
            throw new IllegalAccessError("wrong PackageVisibleHelper ");

public class PackageVisibleHelperFactory {

    public static final PackageVisibleHelperFactory INSTNACNE = new PackageVisibleHelperFactory();

    private static final PackageVisibleHelper HELPER = new PackageVisibleHelper(INSTNACNE);

    private PackageVisibleHelperFactory() {

    private boolean frozened;

    public PackageVisibleHelper getHelperBeforeFrozen() {
        if (frozened) {
            throw new IllegalAccessError("please invoke before frozen!");
        return HELPER;

    public void frozen() {
        frozened = true;

    public boolean isSampleHelper(PackageVisibleHelper helper) {
        return HELPER.equals(helper);
package odp.proj.test;

import odp.proj.A;
import odp.proj.PackageVisibleHelper;
import odp.proj.PackageVisibleHelperFactory;

public class Test {

    public static void main(String[] args) {

        final PackageVisibleHelper helper = PackageVisibleHelperFactory.INSTNACNE.getHelperBeforeFrozen();

        A a = new A();

        // illegal access       
        new PackageVisibleHelper(PackageVisibleHelperFactory.INSTNACNE).launchA(a); 

@Alberto Zaccagni 2009-12-27 22:37:02

Without putting the access modifier in front of the method you say that it is package private.
Look at the following example.

package odp.proj;
public class A
    void launchA() { }

package odp.proj.test;
public class B
    void launchB() { }

public class Test
    public void test()
        A a = new A();
        a.launchA()    // cannot call launchA because it is not visible

@duffymo 2009-12-27 22:41:00

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

@Asaph 2009-12-27 22:36:33

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).

@peter.murray.rust 2009-12-27 22:33:44

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.

@Fredrik 2009-12-27 22:39:34

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.

Related Questions

Sponsored Content

28 Answered Questions

66 Answered Questions

[SOLVED] How do I generate random integers within a specific range in Java?

  • 2008-12-12 18:20:57
  • user42155
  • 4053270 View
  • 3498 Score
  • 66 Answer
  • Tags:   java random integer

44 Answered Questions

[SOLVED] How do I convert a String to an int in Java?

87 Answered Questions

[SOLVED] Is Java "pass-by-reference" or "pass-by-value"?

32 Answered Questions

[SOLVED] When to use LinkedList over ArrayList in Java?

21 Answered Questions

[SOLVED] Java: when to use static methods

57 Answered Questions

[SOLVED] How to create a memory leak in Java?

42 Answered Questions

[SOLVED] How do I efficiently iterate over each entry in a Java Map?

59 Answered Questions

[SOLVED] How do I read / convert an InputStream into a String in Java?

2 Answered Questions

Sponsored Content