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?
- JICE = Java Instance Configuration Engine
- JICE is an XML-based tool for initializing and configuring Java applications.
- JICE is essentially an XML -> Java mapping tool
-
JICE consists of:
- JIC Language - An XML vocabulary for configuring Java objects.
- JIC Engine - set of Java classes that transform the XML data into Java objects.
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.
Here is a explanation of the details:
- A JIC file is an XML file containing the information of the Java instances to be created. These instructions are written in JIC Language.
- In addition to the JIC file, some runtime parameters may be provided. These parameters are just Java instances created outside JIC Engine.
- Classpath contains all the available Java classes and therefore specifies the kind of Java objects that can be created.
- JIC Engine reads the instructions of the JIC file and creates the required Java objects with reflection.
- The result of the process is a graph of Java objects. The graph can be the whole application or part of a larger application.
- 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?
- JIC Language provides an easy format for encoding initialization instructions.
- JICE specifies a model for application initialization. It is easier to understand where the objects in the application are initialized and when.
- JICE collects all the initialization instructions into a central location - an XML file. Initialization process is easier to modify when the information is not scattered.
- The XML file provides a common context for all of the objects. Object references are easy to pass around.
- The elements in the XML file correspond to the Java instances in the application, so the tree hierarchy formed by the XML elements visualizes the structure of the application.
- JICE doesn't require anything special from the application classes - instance of any Java class can be initialized.
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:
- The information is interpreted. No recompilation is needed.
- JIC files don't contain complex logic. The content is easier to understand than Java code.
- The XML format is verbose. This enhances the readability of the content.
As a configuration tool, JICE provides three things:
- a flexible format for specifying the details of the application
- the possibility to implement larger structure changes
- 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?
- JICE could be used in any kind of Java application.
- JICE should be used in situations where a graph of Java instances needs to be constructed.
-
JICE is especially usable in situations where agility is needed:
- the graph of Java instances needs to be modified often/easily
- new Java instance graphs needs to be specified quickly.
- JICE could be used for specifying the structure of the whole application or part of the application.
- An application could have multiple JIC files
-
JICE could also be used for initializing or configuring the Java system
- JICE can call static methods
- setting of system properties, initializing static factories, etc. is all easy to implement with 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:
- common XML format for all - JIC Language is very general, the same format can be used in any kind of Java application.
- nice XML format - the format is as compact as an XML format can be and still adheres to common XML modelling guidelines - values are put inside elements and attributes are used for meta-data.
- focused in initialization - JICE doesn't try to enable scripting in XML. All logic still belongs into the Java code.
- no Java API hiding - the format doesn't try to hide the Java API that is being manipulated by the XML data. JICE is for programmers and there's no reason to introduce a new abstraction layer that only confuses things.
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
:
<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:
- JICE can instantiate any kind of Java class - No default constructors or specifal subclassing required.
- No parsing code needs to be written - The application needs to only locate the JIC file and use JIC Engine for processing the file.
-
Details are hidden from the application - the application doesn't know how the
DateFormat
was created. It knows only that a specific JIC file will yield aDateFormat
instance. - The XML code is close to Java code - It contains class names, for instance.
- No additional rule files are needed - Some Java-XML binding tools require a rule file that specifies how the XML data is mapped to Java and vice versa. This is not required in JICE.
- The XML code adheres to XML guidelines - data values are in inside elements, meta-data is in attributes.
3. Things JICE can't do
- No mapping from Java to XML - JICE is not a Java-XML binding tool. There is a mapping from XML to Java, but no reverse mapping.
- new Java classes can't be specified - JICE can only create Java instances of existing Java classes.
- The XML format is fixed - Only JIC Language is supported. However, you could generate the JIC Language code from some other XML format by an XSL transformation.
- No control flow statements - no if-else, switch or loop structures. JICE isn't therefore a scripting tool. All logic must be put in Java classes.
- no exception handling - JICE can call Java methods, but can't catch or throw exceptions by itself.