Sub packages in Java

After 3 years of my programming life with Java, it was a really a surprise to me when I recently discovered that there is no concept of “sub-packages” at all in Java.

I was trying to disallow access to certain methods defined in a class to all classes residing outside the package. Of course, the default method access is the answer for this problem. However, to be exact, what I wanted to achieve was to allow access to classes residing in the so-called sub-packages and disallow the access to all other classes outside the package.

Though the package a.b is internally stored in a folder b within the folder a, to Java a and a.b are entirely different.  The package structure is just for the developer to organize his codes in any logical way he wants. For the compiler they are totally irrelevant. It doesn’t care!

I couldn’t accept that this is a ‘feature’ in java. I was looking for some kind of exception or some way to allow access to some specific classes. But, my hours of search in the net ended in mere vain!

Then the reality struck and I realized that I am left with just 2 options to go about this condition:

  1. To make the methods as protected instead or package-private and inherit them in the sub-package classes.
  2. To move all the classes in the sub-package to the main package itself.

But the option 1 is not really a solution. Because by extending the class any other class residing any where else in the code base can inherit those methods – Which I really did not want to happen. So, I was forced to choose the option 2 and loose my package structure and code organization.

However, there is a news that this ‘might’ change from java 7. Take a look at this link (read the question 2.5 in section 2) giving the JSR request for more modularity. You may also wish to take a look at these articles which talk about the concept of super-packages intended to be introduced in Java 7:

This means, until the release of java 7, you just cant do anything about this – sub packages do not have any special relationship with their parent packages! 😦

Advertisements

3 comments

  1. Tomek · · Reply

    Hi all,

    The above problem is far more complicated than you described above. If you need something larger than few lines of code or if you want to earn money with Java, you need another level of visibility — I name it “project level access”.

    Supose you write commercial public clases. Those clases can be final, or not final (if you are so bountiful to your customers). But you usualy need pelhotra of hard working tools’ classes (sometimes hundereds or even thousands organised in subpackages) for doing your internal servings.

    It is obvious why you cannot declare those classes “public” — they are your own secret know-how.

    And it is also obvious, that a set of percfectly designed classes can serve for all application classes one can only imagine.

    It is extremaly important to keep tools’ classes in reasonable, readable folder hierarchy and TO BE ABLE to use them in any commercial classes WITHOUT putting them into the same package folder.

    So there is extremaly important (as it looks Java will be a standard “for forever”) to be able to declare “project ” keyword at the beginning of a Java file. The “project” (analogously to “import”) would concatenate listed packages into one unit with default visibility, creating something like a kind of new package.

    When it is done, there is no necessary the subpackages be visible in the parent package, because if they should to, the parent could always use the “project” clause.

    It is also important to understand, that such Java extension doesn’t cause any semantic problem, as at this very moment there is no semantic problem to duplicate tools’ classes among different packages (:-)))))))))))))))))))))))))))).

    Cheers for everyone.
    Tomek

  2. Tomek · · Reply

    Hi again,

    I red the “article from Java.net” mentoned. Completely MINDLESS (no way to declare all as public — it is like a return to middle-age). My concept is the clearest you can imagine. And nothing else is needed.

    Tomek

  3. Ashok Kumar P S · · Reply

    Probably we can restrict it at run-time at least as below (>= JDK 1.4) 🙂

    public void printMyNamePublic() {
    StackTraceElement[] stackTrace = new Throwable().getStackTrace();
    String temp = stackTrace[1].getClassName();
    String callingClassPackage = temp.substring(0, temp.lastIndexOf(“.”));
    temp = stackTrace[0].getClassName();
    String thisClassPackage = temp.substring(0, temp.lastIndexOf(“.”));

    boolean isSamePackage = callingClassPackage.equals(thisClassPackage);
    boolean isSubPackage = false;
    if (!isSamePackage) {
    isSubPackage = callingClassPackage.startsWith(thisClassPackage) && callingClassPackage.charAt(thisClassPackage.length()) == ‘.’;
    }

    System.out.println(“Caller Package: ” + callingClassPackage);
    if (isSamePackage || isSubPackage) {
    System.out.println(“Ashok Kumar P S”);
    } else {
    System.out.println(“You don’t have permission to ”
    + “call this method.”);
    }
    }

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: