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

[David Welker]

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