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

[Matt Jones]

David,

In general I agree with moving forward on Java versions as soon as it makes
sense.  Which for me translates to simply making sure it is available on
operating system versions that are commonly used in our user community.

The long focus for us on Java 1.5 was based on lack of availability of Java
1.6 on our target platforms, most notably Mac OS X 10.4 and 10.5 which are
used by many scientists.  Only relatively recently has it come to 10.5, and
even then it has a number of interoperability problems that I have
encountered with some Java apps.  I suspect that 1.7 will be similarly
delayed, but one never knows.  I think we should support it as early as
possible, but we should not abandon 1.6 until 1.7 is available on our main
target operating systems.  Right now that includes Windows XP, Vista, and 7,
Mac OS X 10.5 and 10.6 (and maybe 10.4?), and several linux distros.  Maybe
Java 1.7 will become available across these OSes that are in common use by
our clientele more quickly than 1.6.

Matt

PS The Kepler 2.0.0 release should deprecate support for Java 1.5, so that
its no surprise that the next release will require at least Java 1.6.

On Tue, Mar 23, 2010 at 10:54 AM, David Welker <david.v.welker at gmail.com>wrote:

> Oh, I just realized that there was one thing I said that was confusing.
> Kepler currently works with both 1.5 or 1.6. So, you can use either as a
> user. This didn't used to be the case, but it is now. I just wanted to make
> sure I didn't confuse anyone on that point in my last email. =)
>
>
>
> On Mar 23, 2010, at 4:22 AM, David Welker wrote:
>
>  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
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20100323/35961d71/attachment.html>