The JCE Checker


This tool is based on a set of rules which are devoted to statically ensure the communication integrity property (see Luckham, or ArchJava for more details). The principles of the tools and its behaviour are closed to the JavaCompExt which was used to extract component types from a Java source code.

JCE analyses Java code source of an Eclipse project and reports some information and graphical views related to the component quality of the code. In some sense it is related to tools like PMD or findbugs. The main information is a classification of the types in CTypes and DTypes.
DTypes are types which could be target or source of a hidden communication channels while CTypes are less  subject to this kind of problems.

The rules run by the tool are :

1) To check wrong profiles, that is signatures responsible for a potential reference capture;
2) To propagate DTypes along subtyping and composition links;
3) To check array and generics usages;
4) To tag exception classes as DTypes;
5) To check downcasting from a type external to the project to a potential component type;
6) To check inner classes.

These rules are intended to avoid component escaping from their enclosing parent, however they cannot ensure
the full detection of these problems. We expect to complete this set in the future. Furthermore, legacy code do not contains connection information of components (or only some parts) thus compliance of the component communications with the architectural links can be only partially done.

A deep comparison with JCE and SOMOX was done in this report. The purpose was to verify that both tools do not extract the same information. This may seem obvious but both are able to analyze Java source code and to produce component types, primitive, composite and data types. However, SOMOX is a component extractor or recovery tool which is able to suggest component types in a source code, even if it is a pure OOP application. This tool is a metrics based tool and it clusters some parts of the application which could become true component types in a new restructuring step. Another important difference, which makes JCE more specific, is the underlying component models. JCE relies on a component model with true first-class component, that is component have types which  are implemented by Java classes. It also supports a notion of subtyping, abstract and concrete component types. Usually most of the component recovery tools and also  architecture compliance checkers consider that a composite is implemented by a packages. In this case component are kinds of syntactic structures not first-class values.

The current .jar need Java 1.6, Eclipse 3.5 Galileo and JDT, it can be install in the dropins folder of your Eclipse installation then restarting Eclipse.