Java and security bits
Superpackages Restated
There seems to be some confusion about what superpackages are about. My one sentence explanation is: a superpackage is a language construct for information hiding. Let's examine that statement.
"Information hiding" is fancy way of saying "keeping implementation details private." In Java, we have access control modifiers to achieve that: private, default (aka package private), protected and public. But sometimes "public is too public".
I also said "language construct." That means something that is part of the Java language, defined in the Java Language Specification and enforced by all Java compilers (e.g. javac). It will also be part of the Java Virtual Machine Specification so that it is enforced at runtime by the JVM.
Let's look at all the things I did not say: no changes to the type system. No changes to the compile time and runtime access control architecture (just a small extension). No changes to how you must package your apps: if you had organized your application into 6 "components" before, each with its own JAR file, you most likely will do the same thing after migrating to superpackages (see note at the bottom).
In other words, a superpackage is a language construct for information hiding. Really. Nothing more to it than that.
But if that is still too abstract, how about this version: superpackages define an extension to the Java access control mechanism: a new access level for classes, which is wider than "package private" but narrower than "public". One could call the new access level "superpackage private", but that is potentially confusing so please don't use that term.
PS: a runtime infrastructure for component based applications is also desirable, see JSR 277. But that is very much orthogonal to the information hiding objective of superpackages.
Posted at 02:13 May 08, 2007 by Andreas Sterbenz in Modularity | Comments[8]
Try to find a modifier equivalent to superpackage doesn't seem to be relevant.
In my opinion, JSR294 should be a way to set access control on package. By example, if the compiler finds java.util.Collections.sort(...), currently it checks java.util.Collections class modifier and sort member modifier. With JSR294, the compiler will first check java and then java.util package.
It's like when you want to access to a file, the system first checks the access right of the directory.
I am certainly monomaniac but i don't understand why you need to call that "superpackage".
Rémi
Posted by Rémi Forax on May 08, 2007 at 11:46 AM PDT #
Remi, those are reasonable suggestions. Let me explain why we chose something different.
Restricting access on a per package basis is not granular enough. In many cases you want to export some classes in a package but not others.
Making package access hierarchical is not sufficient because in some cases you do not want to organize your project in a package tree for various reasons, including historical reasons. See for example java.io and sun.io. We want to make it possible (and easy) to migrate existing code to use the new construct.
In other words, we need the new access control mechanisms to be simple, but flexible enough to address the these and other requirements. That is what led to the superpackages proposal.
Andreas.
Posted by Andreas Sterbenz on May 08, 2007 at 06:31 PM PDT #
Andreas,
I agree with you that export is necessary.
But please don't criple JSR294 because currently in OpenJDK, package java.lang uses sun.misc package.
We have this architecture because there was no way to do better, but with package access control, we can split sun.misc to java.internal, java.lang.internal, java.util.internal etc.
Please don't complexify a feature because it will help to refactor JDK code.
Rémi
Posted by Rémi Forax on May 09, 2007 at 01:28 AM PDT #
Posted by 159.53.110.144 on May 09, 2007 at 08:58 AM PDT #
Posted by Yury Mishchenko on May 09, 2007 at 01:58 PM PDT #
superpackage D { member package A, B, C; export A.*, B.*; }This would include the three packages to superpackage D and expose all classes from A and B, if I got it right.Richard
Posted by Richard Birenheide on May 25, 2007 at 06:04 AM PDT #
Remi, the JDK is just one example of an existing project that has multiple non-nesting package hierarchies. Other projects are the similar. Allowing them to migrate to superpackages without breaking binary compatibility is important.
159.53.110.144, I am not sure exactly what you are suggesting. If you do not want to "export" a class from a package, you can do that today by declaring it "package private." We want to solve the problem for projects larger than a single package, so there needs to be someway to establish relationships between packages. Grouping packages into a superpackage is a simple solution to that problem.
Yuri, you have one possible answer from Richard. If C is a reusable component independent of A and B, another answer is to make C its own module that can be packaged with A and B using JSR 277 deployment modules.
Andreas.
Posted by Andreas Sterbenz on May 29, 2007 at 01:16 AM PDT #
Posted by Nico on May 30, 2007 at 04:56 PM PDT #