Java Modularity Proposal: iJAM

Posted by Geoffrey Wiseman on Oct 10, 2007 08:26 AM

Community

Java

Topics

JCP Standards ,

Research

Tags

Java SE ,

JSR 294 ,

JSR 277

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.

1. Back to top

   Similarities with C#

   Oct 10, 2007 9:35 AM by Jared Stehler

   Is this analogous to C#'s notion of assembly-level accessibility with the 'internal' keyword (msdn2.microsoft.com/en-us/library/7c5ka91b(VS.80).aspx)?
   
   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).

   Reply

2. Back to top

   Re: Similarities with C#

   Oct 10, 2007 9:47 AM 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).

   Reply

3. Back to top

   Re: Similarities with C#

   Dec 1, 2007 6:37 PM 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!

   Reply

• Older >