Skip to main content

two new access modifiers

3 replies [Last post]
Joined: 2004-02-10

Java needs two new access modifiers.

1. For methods and fields, a modifier that means "accessible by subclasses only".

As it stands, I am forced to use "protected" to indicate this, but that leaves the method vulnerable to abuse from other classes in the same package.

2. For classes, a modifier that means "visible to classes on the same level or deeper in the package hierarchy"

For example, given the following packages:

Such a class in package would be visible in all these packages. One in would be visible in the bottom 3.
Once again, as it stands I am forced to make classes public if I want to share them between these packages, leaving them open to abuse from the whole wide world.

I think the keyword "protected" might be reused for number (2), and maybe we could truly confuse the issue and pirate "internal" from C# for number (1).

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-03-04

In Java 1.0 was supported modifier 'private protected' which means "accessible by subclasses only", but it was removed in later versions.

btw. nice text about java history, there is part about modifiers too.

Joined: 2003-06-10

Do you mean the problem, that "protected" makes it also visible to the classes in the same package? Then I'm with you. This was a stupid decision. I also would like to have following visibility levels:

public...everything can access it
private...only the same class can access it
protected...only the class or subclasses can access it (nobody from outside)
friend...only the classes in the same package can access it

The two last should be able to be combined:
friend protected...only the class or subclasses and the classes from the same package can access it (like "protected" now).


Joined: 2004-12-15

Maybe I'm missing something, but it seems that the notion of a package is that it is controlled by a given developer (or group of developers). As such, they presumably understand how the classes in the package work and how not to break them. If you are designing a package such that a "client" can extend the package then it seems that you are asking for trouble. Instead, packages should be "closed" and clients should use and extend such classes from some client package.

Bottom line, I don't see the need for friend visibility in this context. (This is not to say that some manner of friend access would be useful in some other context.)