[jsr294-modularity-eg] Problems for JSR 294 to address

Alex Buckley Alex.Buckley at Sun.COM
Mon Jan 26 23:31:10 EST 2009

Comments welcome.

1) Packages are typically arranged in hierarchies, but types can only be
used across different branches of the hierarchy by being made public,
which exposes implementation details too widely. Information hiding is
further reduced by interface members always being public.

Non-solution: hierarchical package membership. Redefining existing
well-known semantics is always a bad idea, and this one is especially
complicated. There would need to be a way to stop package-private
artifacts from being accessible to subpackages, or else we would be
strengthening information hiding in one place only to weaken it
elsewhere. Also, there would need to be a way to configure the depth of
exposure of package-private artifacts, since artifacts in package A
should sometimes be accessible to A.B and not to A.B.C, and so on.

2) Dependencies of one type on another are expressed in source and
classfiles, but there is no standard way for a Java compiler or JVM to
interact with its environment to read and resolve dependencies. This
causes compile-time and runtime environments to differ, and complicates
any effort to version types available in the (compile-time or runtime)

Non-solution: standardize the CLASSPATH. One list for all programs and
libraries in the JVM makes versioning almost meaningless, and packages
whose types occur in multiple CLASSPATH entries can behave poorly. (See
Peter Kriens' presentation at Devoxx 2008.)

3) Many packages have grown large over the years. They are effectively
impossible to refactor now, since it is binary-incompatible to rename
types and dangerous to "split" packages. The next-best option is to let
subsets be taken of existing packages, and deliver subsets
independently, but there is no mechanism in the Java language or JVM for

Non-solution: a mechanism for renaming packages and types outside the
Java language. This would require updating Java's model of binary
compatibility, and would make source code incomprehensible.

jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu

More information about the jsr294-modularity-observer mailing list