I'd like to have a jar file in which only the API package is accessible. All the other packages (containing implementations) would not be accessible by another jar (nor by any other class).
Is it possible ?
If yes, how ?
Currently scheduled for Java 8 (2012?) is JSR 294. This JSR introduces better modularization language constructs into Java.
Today, an implementation can be partitioned into multiple packages. Subparts of such an implementation need to be more tightly coupled to each other than to the surrounding software environment. Today designers are forced to declare elements of the program that are needed by other subparts of the implementation as public - thereby making them globally accessible, which is clearly suboptimal.
Alternately, the entire implementation can be placed in a single package. This resolves the issue above, but is unwieldy, and exposes all internals of all subparts to each other.
The language changes envisioned will resolve these issues. In particular, we expect to introduce a new notion of modules (superpackages) at the language level where existing public access control would apply only within a language level module and access to API's from outside a module would be restricted to API's the module explicitly exports.
Now I believe the expert group is still discussing the details of this concept. But I believe one thing you might be able to do is this (source: Super Packages in Java 7.0):
superpackage com.myorg.myApp.model
{
member package com.myorg.myApp.model.swing;
member package com.myorg.myApp.model.html;
export com.myorg.myApp.model.swing.SEmployee;
export com.myorg.myApp.model.swing.SDepartment;
export package com.myorg.myApp.model.html;
}
In other words, for a given "superpackage" you can define what is and isn't exported, independent from visibility keywords like public
.
If you have classes that should not be used, put them into a subpackage named "internal". While this does not prevent others from using the classes, it is a strong indication that they should not.
Example:
my.library.Stuff
my.library.StuffFactory
my.library.internal.StuffImpl
my.library.internal.MoreStuff
my.library.internal.xml.DataStuff
While this is not an actual solution, I would consider it a best practice.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With