JICE Concept and philosophy

1.  Abstract

This document tries to describe the concept and philosophy behind JICE. In short, JICE tries to help in achieving the following goals:

• there should be a clear model for constructing Java applications
• there should be a way to visualize the structure of Java applications.
• the configuration of Java applications should be more flexible than with existing tools.

2.  Component based application construction model

A running Java application consists of Java objects. Application construction is a process where the objects in the application are created, the state of these objects is initialized and the objects are connected together.

JICE defines a model for application construction, which has previously been lacking in Java.

2.1. Constructing applications with Java code

The most straight-forward way to construct a Java application is to write a bunch of Java code that invokes constructors and factories, sets properties, calls various methods, etc. Traditionally this kind of initialization code has been scattered across many classes in an application. Components initialize their subcomponents, the subcomponents initialize their subcomponents, and so on. Initialization code is put into constructors and various init-methods and into the main method.

This informal construction process is bad, because:

1. It is difficult to find out what the structure of the application is like.
   • This causes all kinds of problems and makes the code more difficult to change.
2. It is difficult to pass object-references to the subcomponents.
   • If the components form some kind of a hierarchy and a subcomponent wants to use an object that is defined somewhere else in the hierarchy, the reference to that object has to be delivered to the subcomponent through its parent components.
   • This adds unnecessary code to the parent components and makes them more closely bound to its subcomponents.

2.2. Constructing a toy from Lego blocks

The Lego world serves as a good metaphora for demonstrating the application construction model encouraged by JICE.

Lego blocks are simple plastic pieces that can be attached to other Lego blocks. Very complex structures - usually cars, spacecrafts and castles - can be built out of them, which has made Lego technology popular amongst children in many generations.

Lego blocks are ideal components. The blocks can easily be used together and an elementary block can be used in many kinds of toys. Some pieces may be more specific, which make it possible to implement some parts of a toy with a more detailed look.

The following chart is a formal overview to the process of constructing a toy with Lego blocks.

1. Instructions list detailed step-by-step operations that are needed in order to construct a toy. The instructions specify two things:
   1. what kind of Lego blocks needed
   2. how the blocks should be attached.
2. There is a storage of available Lego blocks. The construction can not succeed if the storage does not contain the required blocks.
3. The child is a builder. He/she follows the instructions and constructs the toy step-by-step:
   1. The child picks the required blocks out of the storage.
   2. The child attaches the pieces to each other.
4. When all the instructions have been applied, the toy is finished. The toy consists of a set of individual Lego blocks. The toy may be used in several ways:
   • The toy can be played with.
   • The toy can be merged into a bigger whole: a toy-car may be used together with other cars to create a scene of a car-race, for example.
   • etc.

(Of course, most children do not always follow the official instructions but create the toys by using their imagination. But if you by a Lego set, it will contain instructions on how to create the toys that you see in the cover of the set.)

2.3. Application construction model in JICE

JICE copies the toy construction model of the Lego world and uses it to construct Java applications. Here is an overview of the process:

Similarities to the Lego process are obvious. Here is a explanation of the details:

1. The instructions take the form of a JIC file, an XML file that specifies the kind of Java instances are needed and how they are combined together.
2. In addition to the JIC file, some runtime parameters can be provided. The parameters are simply Java objects that are created outside JICE.
3. Classpath serves as a storage of available components. The classpath contains the Java classes and therefore specifies the kind of Java objects that can be used in the application.
4. JIC Engine replaces the child. It is a Java application that reads the instructions and constructs the application step-by-step:
   1. Java objects are instantiated by invoking constructors or factories.
   2. The objects are combined together - one object may be the value of some other object's property, etc.
5. When all the instructions have been applied, the graph of Java instances is ready. This instance graph can be used in several ways:
   • If the graph forms an application, it could be used as is.
   • If the graph could be a part of a bigger whole: a component in an application, for example
   • etc.

2.4. Advantages of the construction model

The construction model solves both of the problems that a code-based approach had:

1. A JIC file visualizes at least a part of the application structure. It is easier to see what kind of components the application consists of.
2. Object references can be passed around in a JIC file. It is easy to deliver object references to subcomponents. The parent components are not affected with the process.

The model encourages a programming style where all the Java classes are more or less general components with the minimum amount of harcoded details and "glue code". More specialized classes may be created when needed. Applications are assembled from these Java blocks.

3.  Visualialization of the application structure

There are no good ways to visualize the structure of a Java application. Java code is usually edited one class at a time and even the structure of a single class is difficult to see by just looking at the code - the multiple methods and fields of a class can be categorized only by their access priviledges, not by their functionality or use.

Tools like UML and JavaDoc provide some insight to the structure formed by multiple Java classes, but they are poor at visualizing the runtime structure - the structure formed by the actual Java objects. We usually see only general rules, like that an object of type A usually has x objects of type B. It is difficult to see how many objects of type B does the object of type A actually has in the application.

JICE makes it possible to put most, if not all, of the application construction logic into a centralized location. The configuration written in JIC Language describes instances, not classes. The mapping from the XML format to the Java objects is direct: an XML element corresponds roughly to a single Java instance. Therefore the XML tree corresponds very closely to the Java object tree.

Of course, this visualization is only partial. The objects in an application form a graph, not a tree. The XML document visualizes only a tree. Also, many parts of the application will still be defined inside the actual Java code, which is not visible in the XML files. However, JICE still visualizes the structure better than plain Java code.

4.  Configuration of unexpected properties

Some configuration tools, Java properties files at least, expect that the developer knows what things in the application can be configured and what parts are hardcoded into the Java code.

This approach has advantages: it is easy to prohibit the configuration from messing with the core logic.

However, very often there is a need to configure more things than were originally expected. To make new things configurable, the developer has to make code changes. There is a burden in making more aspects configurable.

JICE encourages the developer to make more things configurable than expected and tries minimize the cost of making a new aspect of the application configurable.

This feature of JICE is most evident when comparing JICE with Java properties.

4.1. Parametrization of a Java class

When a Java class is written, the author of the class must provide some ways to parametrize the behaviour of the instances of the class. This means that the author prepares the class with various kinds of constructors and adds setXXX-methods into the class. The decisions of the author can limit the ways how the objects of the class can be parametrized.

The parameterizations of the individual Java classes affect how the whole application is parametrized.

4.2. Parametrization in Java property files

If the application is to be configured with Java properties, the developer must decide what properties of the Java classes can be configured with the properties files.

This selection of configurable properties is a second decision that limits the ways how the application can be parametrized. Probably only the most critical properties are set to be configurable at first. New aspects are made configurable as the application matures. The support for a new property must always be coded into the application - there must be some code that reads the property and handles the value.

4.3. Parametrization in JICE

JICE can call any method of a Java instance that is specified in a JIC file. When configuring an application with JICE, the programmer does not have to make the second limiting decision as in the case with Java properties files. The first step, the parametrization of the Java classes is enough.

If some new property needs to be configurable, no code changes are needed if the Java API supports the parametrization of this property. If the Java API is not properly parametrized, the developer has to implement the parameterization into the Java classes. However, no new configuration handling code needs to be written.

5.  Attributes are used for meta-data

JIC Language uses attributes only describing meta-data and put all actual data-values into elemens and cdata sections. All Java-specific details are put into attributes. Elements visualize the structure of the Java-application and all the actual data values are put into cdata-sections. The element names are directly related to the Java API in question, which makes the code both more compact and readable.

6.  Laborous to create, easy to modify

JIC Language is quite verbose, as is XML content in general. JIC Language does not try to do its job with a minimum amount of code - the verbose but simple format is considered as an advantage.

The idea is, that once the JIC file has been written, the content should be as readable as possible. The values of individual properties should be easy to change even by a person that has never seen that particular file. Therefore all the objects and values can be given a descriptive name, so it should be easy to locate the correct spot.