Skip to main content

subpackages

10 replies [Last post]
regexguy
Offline
Joined: 2003-06-20
Points: 0

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

com.foosoft.foo;

is unrelated to

com.foosoft.foo.bar;

Intuitively, it seems to me, foo.bar 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.
brucechapman
Offline
Joined: 2004-03-18
Points: 0

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.

scholnicks
Offline
Joined: 2004-01-30
Points: 0

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.

brucechapman
Offline
Joined: 2004-03-18
Points: 0

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 */
}[/code]
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 package-info.java.

bmandl
Offline
Joined: 2004-01-01
Points: 0

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 foo.bar extends foo" was supposed to mean that code in "foo" should be able to access code in "foo.bar" (no vice versa).

brucechapman
Offline
Joined: 2004-03-18
Points: 0

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.bar,foo.rab;

or

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

just my 2 cents worth.

wgauvin
Offline
Joined: 2004-01-28
Points: 0

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

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

Perhaps it could allow something like this

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

Anway, that's my 2 cents

brucechapman
Offline
Joined: 2004-03-18
Points: 0

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, package-info.java 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.

jwenting
Offline
Joined: 2003-12-02
Points: 0

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

coxcu
Offline
Joined: 2003-06-11
Points: 0

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 foo.bar;
private package foo.bar.baz;

foo can see foo.bar, but not fo..bar.baz.
foo.bar can see foo.bar.baz.

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

bmandl
Offline
Joined: 2004-01-01
Points: 0

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 foo.bar extends foo;

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