5

Possible Duplicate:
Java: Subpackage visiblity?

This is a continuation of question Java: Subpackage visiblity?. The reason for asking is to draw attention of broader community.

Question Is there any relation between two packages: odp.proj and odp.proj.subpackage?

Someone tried to answer it here but failed to describe it.

M. Justin
  • 14,487
  • 7
  • 91
  • 130
Gaurav Agarwal
  • 18,754
  • 29
  • 105
  • 166
  • No subpackage. One/Group of classes belongs to a package. – kosa Nov 20 '12 at 21:08
  • 2
    @Perception: OP already provided that link in question. – kosa Nov 20 '12 at 21:12
  • The closest Java has to this is; a class can see/access the `private` members of any other class in the same class file, even if they are not nested. – Peter Lawrey Nov 20 '12 at 21:48
  • @Nambari - yes I know, but unless I am missing something in his question it ***is*** an exact duplicate. Just because he linked it doesn't obviate the fact. – Perception Nov 21 '12 at 01:16
  • I would argue that this is not a duplicate — "subpackage" is defined in the [JLS](https://docs.oracle.com/javase/specs/jls/se13/html/jls-7.html#jls-7.1), and it has nothing to do with visibility (which is what the potential duplicate question is asking about). Supbpackages, classes, and interfaces are the three package member types. There is one and only one language effect of subpackages: a class or interface within a package cannot share the same name as a subpackage of the package. Also, subpackages are "intended to be convenient for organizing related packages in a conventional manner". – M. Justin Jan 28 '20 at 21:37
  • I retract my previous comment about it not being a duplicate. I based my assessment on the question's (now-former) title ("Does Java has any concept of Subpackage"). However, the question body was asking about the relation between a package & its subpackage, which is less obviously a non-duplicate. I've updated the title to fit question being asked. – M. Justin Sep 22 '20 at 21:13

4 Answers4

6

No, there's no relation between odp.proj and odp.proj.subpackage from the Java language perspective.

For code, odp.proj.subpackage would reside in a sub directory of odp.proj, and some tools and IDE's might group them together in a UI, but regarding language access control, or other langage feature there's no relation.

Java does not have the concept of a subpackage, so odp.proj.subpackage and odp.proj are as different from each other as any other differently named packages.

nos
  • 223,662
  • 58
  • 417
  • 506
4

Short answer

The exact feature you are looking for doesn't exist.

Long Answer

They considered doing it for Java 1.7, but the case is dormant.

As far as what's actually real, there is no relationship at all between odp.proj and odp.proj.subpackage other than a directory structure, the protected keyword and things like import odp.proj.*; - except that statement doesn't get any classes from odp.proj.subpackage

One way to approach what you want is to release an API specification for what you want to expose and leave the rest undocumented or privately documented. Possibly you could even obfuscate the private classes in each release using something like ProGuard.

durron597
  • 31,968
  • 17
  • 99
  • 158
3

Java has no concept of subpackages.

Beyond organization, packages define the accessibility of methods/fields with the protected and "package" (blank) modifiers, which allows same-class and same-package access. However, this same-package access does not include subpackage classes as well.

FThompson
  • 28,352
  • 13
  • 60
  • 93
  • Also, not specifying a modifier allows intra-package access. In fact, `protected` is actually *more* visible than an unspecified access modifier, since it also allows subclasses to access the member in addition to access within the package. – Brian Nov 20 '12 at 21:33
0

Usually if a package name contains the "internal" word, than the user should not use it directly, because it is not guarantieed, that those packages will be present in the future releases. This is only a naming convention, but still works as a workaround.

Gábor Lipták
  • 9,646
  • 2
  • 59
  • 113