tags:

views:

180

answers:

5

Does anyone understand why Java is missing:

  • An access specifier which allows access by the class and all subclasses, but NOT by other classes in the same package? (Protected-minus)
  • An access specifier which allows access by the class, all classes in the same package, AND all classes in any sub-package? (Default-plus)
  • An access specifier which adds classes in sub-packages to the entities currently allowed access by protected? (Protected-plus)

I wish I had more choices than protected and default. In particular, I'm interested in the Protected-plus option.

Say I want to use a Builder/Factory patterned class to produce an object with many links to other objects. The constructors on the objects are all default, because I want to force you to use the factory class to produce instances, in order to make sure the linking is done correctly. I want to group the factories in a sub-package to keep them all together and distinct from the objects they are instantiating---this just seems like a cleaner package structure to me.

No can do, currently. I have to put the builders in the same package as the objects they are constructing, in order to gain the access to defaults. But separating project.area.objects from project.area.objects.builders would be so nice.

So why is Java lacking these options? And, is there anyway to fake it?

A: 

I think a part of your issue is in this sentence:

The constructors on the objects are all default, because I want to force you to use the factory class to produce instances, in order to make sure the linking is done correctly

Do you really need to force the users of your code to only be able to use certain methods/constructors?

Can you not simply document something like "for this class to work properly, all instances must be build by using this factory?" and trust them to follow the documentation you gave to them?

Anyone who deviates from your documentation is doing so at their own risk and peril.

matt b
Integrating design constraints into the implementation is always better than documenting it. Just like parameterizing a List is better than saying in a Javadoc that it will always contain Strings. Compile errors express design violations better and more effectively than documentation ever will.
Mark Peters
+7  A: 

Does anyone understand why Java is missing:

  • ...
  • An access specifier which allows access by the class, all classes in the same package, AND all classes in any sub-package? (Default-plus)
  • An access specifier which adds classes in sub-packages to the entities currently allowed access by protected? (Protected-plus)

Java's packages are not hierarchical - there are no sub-packages (even though the directory structure suggests it). Packages that are "inside" other packages are not really sub-packages, they are just packages of which the name happens to start with the same prefix as the "parent" package. You can also see this when importing packages; a statement like

import java.awt.*;

only imports everything in the package java.awt, and not for example everything in java.awt.image.

So therefore there are also no access specifiers that work for sub-packages.

Jesper
+3  A: 

Check out the superpackages features which will, reportedly, be coming in Java 7:

Chris Dennett
Much thanks for the links. Superpackages, as described in that java.net article, seem like they would fit the bill exactly. I could use a non-exported class in the same package as my objects to gain default access to their properties, and then provide public getters and setters to be called by the builders in my builders sub-package (I should also stop using the term sub-package since they're not heirarchial...)
Tom Tresansky
+1  A: 

Presumably, to keep things simple.

While we're on the topic of wishing: I miss an access specifier that allows a field to be modified only using the this pointer (object-level instead of class-level encapsulation). And it would be nice to be able to specify different access modifiers for reading and writing a field.

Edit: It was a specific goal in the design of the Java language to have a simple language, particularly in constrast to C++. Of course, this comes at a price in expressiveness; some things are harder to do in Java than C++ because the compiler offers less support. Consider the omission of const. It makes it pretty cumbersome to safely expose read-only references to internal state. However, it also prevents beginners from being confused by numerous compiler errors related to const-correctness.

meriton
This doesn't keep things simple. It adds undue complexity, as per the OP's specific situation. The only way it is "simpler" is in the sense that there's less to understand. Adding specifiers, however, in no way prevents you from using only those which currently exist.
Stefan Kendall
If the question's proposal were adopted, there would be 7 access specifiers in the Java language. Can you come up with 7 easy to memorize names that accurately reflect the visibility of the member in question? (protected- is not such a name ...)
meriton
... and just to clarify what I mean by "simple", I was referring to the first design goal of the Java language, which states that the Java language should be "simple".
meriton
+3  A: 

To answer your questions one at a time:

* An access specifier which allows access by the class and all subclasses, but NOT by other classes in the same package? (Protected-minus)

This was in Java 1.0 (private protected was the modifier) and removed. I'm not entirely clear on why, but it was definitely viewed as something not worth the hassle. The current arrangement makes all modifiers go from less restricted to more restricted which is simpler (as in less potential variation) which is a Java design goal.

* An access specifier which allows access by the class, all classes in the same package, AND all classes in any sub-package? (Default-plus)

* An access specifier which adds classes in sub-packages to the entities currently allowed access by protected? (Protected-plus)

These two are not available for a related reason. Java currently doesn't have a notion of a sub-package, it just pretends to by the fact that the regular file and jar based classloaders (as well as the compiler) follow the directory structure of the underlying file system to find files. Java will be addressing this more extensively with JSR 294 (the "superpackage") (as others have pointed out) which will give you much more granular control of what is published outside of the package (and therefore you could make things public if you want to, and it still would not be visible).

Yishai