views:

492

answers:

7

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?

+4  A: 

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

starblue
+2  A: 

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.

peter.murray.rust
+12  A: 

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

Asaph
nitpicking: ... merely suggestive unless a restrictive security manager is present.
meriton
@meriton: fair enough. I updated my answer.
Asaph
A: 

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. //cannot call launchA()
    }
}
Alberto Zaccagni
A: 

Look into Modules in Java 1.7

bmargulies
"Both of the Sun-led JSRs on modularity (JSR 294, Improved Modularity Support in the Java programming language, and JSR 277, Java Module System) are now in an inactive state." - http://www.infoq.com/news/2009/12/state-of-osgi
mjustin
A: 

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.

Fredrik
+1  A: 

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
duffymo