Is there any way to access another package without the public modifier?

Question

Let's say I have packages:

com.mycomp.packone
com.mycomp.packtwo

Is there any way for me to access protected members of a class in packone from a class in packtwo, but not allow public users to do so? The only way I can think of is with protected access and using a subclass. But that just pushes the problem into the subclass, because I would want the same access restrictions there as well.

The context for this is we are redesigning our main API and want to make it more modular. Right now it is all in one giant package. I wasn't here for that design, but I assume it is because there is a lot of protected usage.

Answer 1

The protected modifier is your only option for now (JDK7 not out yet). As you said, this still allows subclasses in other packages to access protected members. You can prevent subclassing by declaring your classes as final but I'm not sure if this will be compatible with your use case. It's also important to keep in mind that all the access modifiers in Java are merely suggestions and easily bypassed by reflection.

Answer 2

Java packages are severely limited (IMHO) in that there is no special treatment for the hierarchy of packages and containment between them. Each package is independent and the dot notation is for human eyes only. The ability to limit access to specific clients is also broken (how it makes me wish C++'s friendship mechanism sometimes...)

AFAIK, this is your only option for now until Java 7 hopefully fixes things up.

One thing you could consider though (if your project fits) is to use something like OGSi. It's modularization and exporting infrastructure allows you to do things that are more fine tuned than what the language allows.

Answer 3

Like Asaph said, break the rules using reflection (use getDeclaredMethod for a method instead of a field):

package com.mycomp.packone;

public class Introvert {
    protected String secret = "TOP SECRET!";
}

package com.mycomp.packtwo;

import java.lang.reflect.Field;

public class Extrovert {
    public String talk(){
     return this.getSecret();
    }

    @SuppressWarnings("unchecked")
    protected String getSecret(){ // everybody in packtwo can call me!
     try {
      Class introvertClass = Class.forName("com.mycomp.packone.Introvert");
      Object introvert = introvertClass.newInstance();
      Field secretField = introvertClass.getDeclaredField("secret");
      secretField.setAccessible(true);
      return (String) secretField.get(introvert);
     } catch (Exception e) {
      throw new RuntimeException(e);
     } 
    }

    public static void main(String[] args){
     Extrovert extrovert = new Extrovert();
     System.out.println(extrovert.talk());
    }
}

Answer 4

Consider re-designing your API to have "external" and "internal" APIs.

While you cannot do this using native Java access modifiers, you could package your classes using:

package com.mycomp
package com.mycomp.internal

In com.mycomp package, you publish your public APIs which you allow "public" users to depend on; most of the time, there are more interfaces than classes in this package.

com.mycomp.internal package is where you implement most of the interfaces found in com.mycomp. Naming a package internal effectively tells people that classes in the package are internal to the API, and choosing to depending on internal packages may break their codes in future releases. What's more, if you could use OSGi, you can export only the com.mycomp package, thus making com.mycomp.internal effectively "hidden" from the rest of the world.

FWIW, mockito employs this method of packaging for its API.

The disadvantage to this method is the reliance on a convention.