Introduction to JICE

Author: Timo Laitinen
Date: 2004-10-07

Contents

1. Overview
1. 1. What is JICE?
1. 2. JICE and application initialization
1. 2. 1. Application initialization model
1. 2. 2. Why to use JICE in application initialization?
1. 3. JICE and application configuration
1. 3. 1. What is application configuration?
1. 3. 2. Why to use JICE for configuring applications?
1. 4. What kind of applications should use JICE?
1. 5. What makes JICE unique?
2. A simple example
3. Things JICE can't do

1. Overview

1. 1. What is JICE?

The term JICE is used for referring the whole thing - JIC Language together with the JIC Engine. The term JIC Engine is used for referring only the Java classes.

In this context, initializing an application means creating the Java instances in the application and setting the state of these instances.

Configuring an application means modifying an application slightly without touching the actual application code.

1. 2. JICE and application initialization

A running Java application consists of Java instances. Initialization is a process where these Java instances are created and their state is set.

The process consists mainly of multiple constructor and method invocations which are executed more or less in sequence. New Java objects are instantiated, properties are set, methods are called, the objects are combined together, etc.

JICE is an engine for initializing Java applications. It specifies an XML language called JIC Language for describing the kind of Java instances an application has. JIC Engine is a set of Java classes for processing the XML data. It reads the instructions in an XML file and initializes the necessary Java instances by using reflection.

1. 2. 1. Application initialization model

The following chart gives an overview of the application initialization process.

JICE Process

Here is a explanation of the details:

  1. A JIC file is an XML file containing the information of the Java instances to be created. These instructions are written in JIC Language.
  2. In addition to the JIC file, some runtime parameters may be provided. These parameters are just Java instances created outside JIC Engine.
  3. Classpath contains all the available Java classes and therefore specifies the kind of Java objects that can be created.
  4. JIC Engine reads the instructions of the JIC file and creates the required Java objects with reflection.
  5. The result of the process is a graph of Java objects. The graph can be the whole application or part of a larger application.
  6. The resulting object graph may live a life of its own or it can be used in some other process.

1. 2. 2. Why to use JICE in application initialization?

1. 3. JICE and application configuration

In addition to application initialization, JICE can also be used in application initialization. Application initialization and configuration are closely related, as the initialization usually includes configuring the application. But the two terms are separated here so that we can analyze JICE from two point of views.

1. 3. 1. What is application configuration?

In this context, configuring an application means modifying some parts of an application without touching the actual application code. It is in contrast to programming, which definitely includes the modification of the application code.

Applications typically have various kinds of configuration files that specify some details of the application in addition to the application code. Traditionally the configuration files contain minor details like fonts, colors, localized texts, etc. An application is configured by editing these configuration files.

In general, Configuration files are used because there is a need to change some parts of an application easily. Application code is often not flexible enough - it has to be compiled, the editing requires programming skills, etc.

An application using configuration files consists of:

application = application code + configuration data

There is no clear rule on how to decide what things should be configurable and what things should be put in application code. The minor details are a good candidate for configurable things - putting detailed values into the code is considered hardcoding, which is a bad thing in general. The implementation of the core application logic and features should be defined in the application code. However, there is a gray area between these two things.

1. 3. 2. Why to use JICE for configuring applications?

In general, JICE is suitable to be used as a configuration tool because the instructions in the JIC files are easier to change than Java code:

As a configuration tool, JICE provides three things:

  1. a flexible format for specifying the details of the application
  2. the possibility to implement larger structure changes
  3. modification of application configuration with XML tools

The JIC Language is a good format for describing details: strings, numbers, booleans, urls, file paths, colors, fonts, date and number formats, etc. The format is very verbose and declarative, so it is relatively easy to both find the value to be modified and modify the value without breaking anything.

However, in addition to the specific data values, a JIC file defines also some parts of the application structure. This has both pros and cons. The format enables even complex structure changes, which is typically not possible with other configuration tools. On the other hand, the content in a JIC file is more complex than in a configuration tool that is specialized in specifying only details - like Java properties files, for example.

The fact that JICE uses XML files brings in all the advantages of XML. It is for example possible to modify the configuration of an application with XSLT.

1. 4. What kind of applications should use JICE?

1. 5. What makes JICE unique?

The focus on initialization and the XML format, JIC Language, are the most unique inventions in JICE. Here is a list of the features that are the most important:

2. A simple example

An application using JICE will have one or more JIC files, XML files containing JIC Language code. Each JIC file specifies a graph of Java instances. Depending on the application, this Java instance graph can be only a simple Java object that is used as part of the whole application or a more complex graph - perhaps the whole application itself.

Here is an example of a simple JIC file that specifies a java.text.DateFormat instance with the pattern dd.MM.yyyy HH:mm:ss z and locale fi,FI:

<?xml version="1.0" encoding="UTF-8"?>
<dateFormat xmlns="http://www.jicengine.org/jic/1.0"  class="java.text.SimpleDateFormat"  parameters="pattern,locale">
  <pattern>dd.MM.yyyy HH:mm:ss z</pattern>
  <locale  class="java.util.Locale"  parameters="language,country">
    <language>fi</language>
    <country>FI</country>
  </locale>
</dateFormat>

In an application that wants to use the DateFormat instance, the JIC file can be processed with the following Java code:

try {
  // locate the jic file
  org.jicengine.io.Resource jicFile = new org.jicengine.io.FileResource(new java.io.File("examples/DateFormat-2.jic"));

  // process the file with JIC Engine
  Object result = org.jicengine.JICE.build(jicFile);

  // we assume that we got a DateFormat instance
  java.text.DateFormat dateFormat = (java.text.DateFormat) result;

  // use the dateFormat for something..
} catch(Exception e){
  // handle the exception..
}

The code invokes JIC Engine that actually processes the file. JIC Engine reads the XML data and uses reflection for creating the required Java instances.

Of course, the same result can be achieved by specifying the DateFormat in the Java code. But this way the information of the DateFormat will be in a format that is more susceptible to change.

Some considerations:

3. Things JICE can't do