Skip to main content


10 replies [Last post]
Joined: 2003-06-20

I've always found it odd/unintuitive that subpackages have no significance.;

is unrelated to;

Intuitively, it seems to me, should be in foo and should be able to access its package local members. I don't know if this will address the desire that some people have for the "friend" keyword.

Reply viewing options

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

All existing programs must maintain existing meaning. That is, in the absence of any package visibility declaration, a package and a subpackage have no special visibility relationship.

Therefore any new syntax would need to declare an "opening up" of visibility rather than a "hiding" of it. (otherwise all existing code would suddenly get opened up, just because it didn't hide a relationship).

Also, the package visibility declaration should be on the package being accessed, not the package accessing it. That is a package should say which subpackages have access to its (otherwise) package private declarations.

Your suggestion seems to violate both these requirements.

Joined: 2004-01-30

I totally disagree with this; it breaks package encapsulation. By making a class (or constant, method, etc) as package private you are declaring that only this package (and absolutely no others) can use this class.

By allowing "package inheritance" anyone could inherit from any package (e.g. java.lang) and have access to the package private items.

Joined: 2004-03-18

Notwithstanding the legalities, you can break this already if you want (and your lawyer will let you)
[code]package java.lang;
class MyClass {
/** access java.lang package private stuff */
The way you prevent this happening to your code is to "seal" the package in the jar file. A language extension that implemented the sort of thing being suggested in this thread could probably be made to work cooperatively with package sealing as well. I guess a sealed package is like[code]final package java.lang;[/code]

It is worth noting that (via JSR-175) there is now a recommended "source" file for the package itself (currently to support annotations for the package) called

Joined: 2004-01-01

It seems that my suggestion of using "extends" caused some confusion.

I aggree 100% with bruce chapmans definition of requirements.

1.) All existing programs must maintain existing meaning.
2.) The package visibility declaration should be on the package being accessed, not the package accessing it.

So "package extends foo" was supposed to mean that code in "foo" should be able to access code in "" (no vice versa).

Joined: 2004-03-18

Not confused.

If you look at the indenting, my comment was a reply to COXCU not you, it just came after your reply to coxcu.

I am not sure about extends because in the usual case of allowing a subpackage to have "package private" access to the main package, the syntax is[code]package main extends main.sub;[/code] whereas the normal use of extends is[code]class Sub extends Main[/code]Note how the package extends relationship is inverted with respect to the class extends relationship. I dont like that.

Neither do I like coxcu's use of "private", we should open up, not hide access.

Of the existing keywords, "protected" would seem to have the closest meaning to the access being granted, and "import" has closest generic (normal language) meaning to what is happening. [code]
package foo protected,foo.rab;


package foo import,foo.rab;[/code]

just my 2 cents worth.

Joined: 2004-01-28

Couldn't things like this be added to the file with package level Annotations.

e.g @SubpackageAccess({"",""}) package foo;

Perhaps it could allow something like this

@SubpackageAccess({""}) package foo; - thus allowing for reaching even a package like

Anway, that's my 2 cents

Joined: 2004-03-18

The third sentence of the final release of JSR-175 (annotations) says '[i]These annotations do not directly
affect the semantics of a program[/i]'.

I think we will find over time that this will be enforced much more vigorously than the wording might suggest.

Using annotations to change the visibility would break this rule.

Yes, might be a good place to put a new subpackage visibility declaration.

Yes, the ellipsis notation (or .* to borrow from import) might be useful and safe as well.

Joined: 2003-12-02

sounds logical, but will need extensive study as to the potential impact this has on existing code.

Joined: 2003-06-11

It does indeed sound logical, especially if you are coming to Java from a more block structured language. The way the private modifier effects nested classes violates the same intuition. Changing the semantics of existing code would break things left and right. I can tell you that without any study.

Adding a prefix to the package declaration is one way to create a more structured package hierarcy.

package foo;
private package;
private package;

foo can see, but not can see

Java needs something like this because the success of unit testing methodologies have effectively made the package a smaller unit of code.

Joined: 2004-01-01

I would also appreciate to have the option to treat code in subpackages exactly like code in the same package (optionally to avoid negative impact on existing code).

how about

package extends foo;

This could tell the compiler that code in "foo" can treat code in "" as if were in the same package.