Java Modularity Proposal: iJAM

by Geoffrey Wiseman on Oct 10, 2007 |

A new proposal, iJAM, has circulated on the
JSR-294 and modules-dev mailing lists suggesting some changes to the logic supplied in the strawman proposal for JSR-294 'superpackages', and has received some positive feedback from Doug Lea:

[The proposal] is VERY nice! It took a couple of reads to see that the non-reverse dfs was not only what you want, but the key to cleanly supporting "import own M" and "import M as X".

iJAM: a more expressive & intuitive semantics describes potential weaknesses of the Java module system:

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.

For more information about these and related topics, consider reading JSR-277: Java Module System, JSR-294: Improved Modularity Support in the Java Programming Language, JSR-291: Dynamic Component Support for Java SE as well as InfoQ's coverage of the debate on the overlap and the value of each of these proposals and the early access release of 277 and 294 from the OpenJDK project.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Similarities with C# by Jared Stehler

Is this analogous to C#'s notion of assembly-level accessibility with the 'internal' keyword (

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).

Re: Similarities with C# by Rodolfo Rothganger

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).

Re: Similarities with C# by Robert Kohlenberger

It's unfortunate that "private protected" was dropped from Java. I've heard 3 reasons given for why it was dropped:

1. too confusing
2. doesn't fit into a neat progression from private to public
3. unnecessary

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!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss
General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

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.