[kepler-dev] Java 1.6 and Java 1.7 and Kepler

[David Welker]

Hi All,

I wanted to briefly bring up the topic of which version of Java we are
using. We have adopted a very conservative policy of releasing under Java
1.5. However, at this point, Java 1.5 has reached its End of Service Life
(EOSL). This means that Sun (now Oracle) is no longer supporting Java 1.5,
except for business customers who are willing to pay hefty fees. I think we
might be being too conservative for Kepler 2.0, but there are respectable
arguments both ways.

Looking forward, Java 1.7 is scheduled to be released in October of this
year. I was hoping that maybe we could be much more aggressive in adopting
Java 1.7 than we have been with Java 1.6. One of the key innovations of Java
1.7 is the addition of a new keyword called "module" that introduces a new
scope. Basically, in addition to private, public, and package scope, there
will be a new module scope. In this way, module developers can control what
methods and classes are accessible outside of a module. This will facilitate
the basic object-oriented goal of information hiding and allow module
developers to change their internal implementations with confidence that no
classes outside of the module depends on the parts of the module that are
within module scope (side effects, of course, excepted), but allow all other
parts of the module to make use of those parts, whether or not those parts
are in the same package. Right now, there is no good way to do this. Package
scope is too restrictive, as it is normal and typical to have multiple
packages in the same module that depend on each other, especially when
modules are composed of classes that were originally developed in different
contexts. Right now, the only way to allow such sharing across packages in
the same module is to use public (or in a minority of cases, protected
scope). But this opens up those parts of the module to being used and
depended upon outside of the module and greatly increases the uncertainty
and cost of change. With the module keyword, in contrast, you would have
complete confidence in what parts of the module may be depended upon outside
of the module.

Basically, architecturally, from a Kepler perspective, what this will
concretely enable is much greater confidence in substituting one module for
another with fewer unexpected disruptions. Instead of defining an interface
for just a class, it will be possible to define an interface for an entire
module with complete confidence that other modules depend on that interface
and nothing else. Under the status quo, the public keyword is used much too
often in Kepler. We use the public keyword not because we truly intend for
the whole world to be able to invoke certain functionality, but instead
merely so other parts of the same module can invoke that functionality. The
unintended consequence is excessive coupling across modules and much less
clarity in what would actually need to be done in order to substitute the
functionality of one module for another.

This is also related to a proposal I plan to introduce after Kepler 2.0 is
released to bring the concept of what I call "services" to Kepler. More on
that later...

Java 1.7 will also feature other support for modules, and significantly, the
JDK itself is being modularized via Project Jigsaw. Although Project Jigsaw
is primarily aimed at modularizing the JDK, it will also be available for
any developers who wish to use it in their own projects. This is very
exciting, as the way the classpath is managed will likely be different and
designed with modularity specifically in mind (although, for backwards
compatibility, the former linear method of managing the classpath that is so
characteristic for previous versions of Java will continue to be supported)
and much more robust for complex systems (such as ours) that feature
multiple modules. I imagine and predict also that after Java 1.7, a strong
ecosystem of third-party tools will also develop to support modules. In
addition to Project Jigsaw, significantly the module system supported by
OSGi will also benefit from these changes. It seems regardless of what
direction we take with modules in the future, whether we align ourselves
with OSGi, Jigsaw, or keep the current custom module system, that Java 7 and
the new ecosystem it brings about will be tremendously helpful.

As we have moved to a module-centric architecture and this is one of the
major features of Kepler 2.0, we really could use the "module" keyword. I am
opening up this discussion a little early perhaps, as Java 1.7 will not be
available until October and further availability on Mac has traditionally
lagged. Nonetheless, I think now is the time to start thinking about this. I
think we should seriously consider and have an open mind to adopting Java
1.7 rapidly after it is available for both Windows, Linux, and Mac rather
than sticking with Java 1.6 for a long time. I first mentioned the
possibility of moving from Java 1.5 to Java 1.6 on January of 2009. It is
now March of 2010 and we are still using Java 1.5 even though its service
life is over and the release of Java 1.7 is just around the corner. This
makes sense to some degree, since there were not necessarily any truly
compelling reasons to move to Java 1.6, besides significant performance
improvements including in start up time and some API improvements. But for
Java 1.7, I think the case is much stronger given the strong synergies with
our new module architecture, so I am hopeful that we can think about moving
more rapidly in upgrading Java than we have been in the past.

Just some food for thought...

-David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20100323/8d79ae46/attachment-0001.html>