We discovered that although the module system helps solve many complicated software design issues, it is not expressive enough to solve what we call the high-level separation problem. We also found that the module and class definition lookup functions gave slightly unintuitive behaviour.

The high-level separation problem exists when two modules depend on a third module, but do not want to share said module. The unintuitive lookup functions addresses the reverse depth-first search (parent then self) proposed, which can make it difficult for a lower-level module to control its own scope.

The iJAM proposal attempts to solve these problems with the following solutions: - Depth-first (self then parent) lookup of class and module definitions - Import clauses that allow control over sharing of modules.

Both the early-access release of the Java Module System and iJAM can be downloaded, experimented with, and tested; this is a good opportunity to experiment with the proposals, see them in action and even offer your feedback.

I think this sounds like a good idea, but would prefer if we could somehow integrate it into the standard JAR packaging (i.e. a descriptor in META-INF with a slight tweak of javac) instead of creating a new .superpackage file type.

On a side note, I also prefer C#'s protected keyword semantics over Java's (in C#, a protected member is accessible only to derived types, while in Java protecteds are accessible to all types in the same package, which you can acheive in C# with a 'protected internal' declaration).

java had (on version 1.0.2) the "private protected" declaration which had the same behaviour than the C# protected keyword. It was drop because there was no simpler path for increasing visibity of methods an class (private -> private protected -> protected -> public or private -> private -> package -> protected -> public).

None of these is an adequate rationale in my view, and much as I hate to admit it, C# was correct in re-introducing this access level. (C# was also correct in making "private" and not "package" the default access level - Always make it easier to do the right thing!)

Here's why those 3 arguments are wrong:1. If you're confused about the difference between subclass and package access, you shouldn't be writing commercial code.2. If a useful feature complicates a nice linear implementation, then maybe the nature of the problem is not linear. Don't blame the feature - blame nature!3. The reason given for being unnecessary is that, since all classes in a package are written by the same programmer, "package protected" is like protecting programmers from themselves. But that's b***s*** because anybody can hack a new class into an existing, compiled package, and then have access to any protected methods. Java's old "package protected" and C++/C# "protected" level allows programmers to restrict access to runtime instances of the class or subclass - not so easy to hack!

This is an important issue, and I hope somebody out there in the land of Java language specs is listening!

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.