Five years waiting for JRE7: it’s justified? (Part 1)

JRE6 was released in 2006 and five years after a major JRE version was released, during last few years java looked stagnant, and many java developers begin to worry, and this concern was amplified when Oracle purchased Sun.

We will try to discover if there’s a big refactoring or maybe many features was added, that can explain this duration between these two releases. In this first part we will focus on design and implementation changes, and the second part will be focused on added features and breaking changes.

With JArchitect we can compare two versions and detect any modifications concerning architecture, design or implementation, We can have a big picture of changes using the following views:

Info View

JRE7 has an improvement of almost 10% compared to JRE6. we notice that the metrics ProjectCa and ProjectCe was decreased,what proof that with JRE7 we have less coupling between projetcs,and it’s an indicator that a refactoring was made for this new release.

Class Browser

What’s interesting with this view is that we can easily discover what’s added (in bold), removed (crossed) and changed (underlined).

Dependency Structure Matrix

The Dependency Structure Matrix is a compact way to represent and navigate across dependencies between components. For most engineers, talking of dependencies means talking about dependency graph. But the matrix can have the following advantages:

• Graph is more intuitive but can be totally not understandable when the numbers of nodes and edges grow (a few dozens boxes can be enough to produce a graph too complex)
• DSM is less intuitive but can be very efficient to represent large and complex graph. We say that DSM scales compare to graph.

After comparison we can see visually what changed, the sign (+) shows that a dependency is added, and the sign(-) indicate that a dependency was removed.

Metric view

In the Metric View, the code base is represented through a Treemap. Treemapping is a method for displaying tree-structured data by using nested rectangles. The tree structure used in JavaDepend treemap is the usual code hierarchy:

• java projects contains packages
• packages contains types
• types contains methods and fields

The treemap view provides a useful way to represent the result of CQL request, so we can see visually the types concerned by the request.
For example to have an idea of types added to JRE7, we can execute the following CQL request:

SELECT TYPES WHERE WasAdded

The blue rectangles represent all code elements added.

Code Changes

Dependency cycles betwen jars

Having a dependency cycle is an indicator of a lack of levelisation, and to improve the design it’s better to avoid them, here’s a nice blog post which describes the goal of layering.

JRE6 as shown by the following dependency graph contains three dependency cycles between jars.

But for JRE7 a refactoring was made, and the dependency cycle between rt and charsets was removed

What changes made in JRE7 responsable of removing this dependency cycle?

To anwser this question let’s discover what rt jar used before in other jars

SELECT TYPES WHERE IsDirectlyUsedBy "rt"

Only HKSCS from charsets was used in rt, this class was removed from charsets to rt, and that explain why the dependency cycle disappear.

But other dependency cycles remains, to see what code elements implied in this dependency cycle, let’s search for types used by rt that exist in other jars concerned by the dependency cycle.

The interesting remark is that for jsse only 2 types remains used, before in jre6 18 types was used, and we hope that for the next release this dependency cycle disappear also.

Abstractness vs Instabilty

The “Abstractness vs Instability” graph can be useful to detect projects that will be difficult to change.
This following post describe the utility of this graph and how to exploit it to improve the design.

It’s interesting to know if with JRE7 this indicator is improved or not.

Here’s the graph concerning JRE6

As we can observe only rt is in the red zone, what means that any changes to rt could impact other jars and a big testing effort is needed to validate that there’s no regression.

And here’s the graph concerning JRE7

rt is shifted a little more than before into the red zone, and it’s not a good point for JRE7, there’s more risk when changing rt.

Methods Changed

To detect implementation refactoring we can search all methods where code was changed.

SELECT METHODS WHERE CodeWasChanged

Only 5% of code was changed.

Methods became deprecated

It’s very useful to know which methods became deprecated to avoid using them.

Only few methods became deprecated.

And we can also search for deprecated methods but still used by other methods, for these cases it’s preferable to refactor them.

SELECT  METHODS WHERE IsDeprecated AND MethodCa >0

Dominant Paradigm: Generics or OOP?

2799 types was added to JRE, and it’s interesting to know if these types are generics or classes

   
SELECT TYPES WHERE WasAdded AND IsGeneric 

Only some types added are generics, so the dominant paradigm still OOP.

Annotations

Annotation is a mechanism for associating a meta-tag with code elements and allowing the compiler or the VM to extract program behaviors from these annotated elements and generate interdependent code when necessary.

It make your development easier by allowing you to spend less time writing boilerplate code under many circumstances by enabling tools to generate it from annotations in the source code.

Let’s search for annotations added in JRE7:

SELECT TYPES WHERE IsAnnotationClass AND WasAdded

Code Complexity

Cyclomatic complexity is a popular procedural software metric equal to the number of decisions that can be taken in a procedure, this metric is computed from source code.

BCCyclomaticComplexity is the same as Cyclomatic Complexity but computed from byte code.

The following request gives us more info about complexity in JRE6

SELECT  TYPES WHERE IsInOlderBuild  AND BCCyclomaticComplexity >0

The average is equal to 20, it’s interesting to know the evolution of this average for new features added to JRE7.

SELECT  TYPES WHERE WasAdded AND BCCyclomaticComplexity >0

The cyclomatic complexity average was a little decreased for new features added to JRE7.

Coupling

Low coupling is desirable because a change in one area of an application will require less change throughout the entire application. In the long run, this could alleviate a lot of time, effort, and cost associated with modifying and adding new features to an application.

Using interfaces and abstract classes improve the low coupling, let’s search for these kind of types in added code of JRE7.

SELECT TYPES WHERE (IsInterface OR IsAbstract) AND WasAdded 

Many interfaces was added, it’s a good indicator that features added are described by their contracts and we have the possibility to have many implementations for the same contract, what make JRE very flexible.

For example if we search types implementing WindowFactory interface.

SELECT TYPES WHERE Implement "com.sun.deploy.uitoolkit.WindowFactory"

Cohesion

The single responsibility principle states that a class should have one, and only one, reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types.

LCOMHS value higher than 0.95 should be considered alarming.

Let’s search for added that can be considered non cohesive.

SELECT TYPES WHERE LCOMHS > 0.95 AND   NbFields > 10 AND   NbMethods >10 AND WasAdded

Only 3 classes could be considered non cohesive.

Conclusion

Meir Manny Lehman said:

“As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.”

We have to be aware of any evolution and try to improve the implementation and design. for that we need to audit the code after each development iteration to keep the code flexible and easy to maintain.

Concerning JRE No big changes concerning refactoring were made, only 5% of the existing code was changed, in the next post we will focus more on added types, and see if there are many features added that can explain this waiting of 5 years.