JICE Concept and philosophy

Author: Timo Laitinen
Date: 2004-10-02

Contents

1. Abstract
2. The need for engines
2. 1. JICE vs. Java code
2. 2. What is an engine?
2. 3. Why to use an engine?
2. 4. Scripting languages vs. engines
3. JICE - an engine for initializing Java applications
3. 1. Constructing a toy from Lego blocks
3. 2. Application construction model in JICE
4. JICE vs. existing initialization tools
4. 1. Initializing an application with Java code
4. 2. JICE vs. Java code
4. 3. Existing Java initialization tools
4. 4. Why to use JICE?
4. 4. 1. JICE vs. Java code
4. 4. 2. JICE vs. web.xml
5. The need to configure applications
5. 1. What is application configuration?
5. 2. What are configuration files?
5. 3. Why to use configuration files?
5. 4. Configuration files vs. engines
5. 5. Configuration and initialization
6. The need for application configuration
7. The problem with application configuration
8. Usage scenarios
9. Disadvantages
10. Component based application construction model
11. JIC file visualizes the structure of the application
12. Configuration of unexpected properties
12. 1. Parametrization of a Java class
12. 2. Parametrization in Java property files
12. 3. Parametrization in JICE
13. Attributes are used for meta-data
14. Laborous to create, easy to modify
15. Disadvantages
15. 4. A new XML format needs to be learned
15. 5. JIC Language is for Java programmers
15. 6. No security or information hiding
15. 7. Performance overhead

1. Abstract

This document tries to explain the concept and philosophy behind JICE. This will hopefully help in evaluating whether JICE is usable or not.

2. The need for engines

2. 1. JICE vs. Java code

The biggest competitor to JICE is Java code. Everything that JICE does can be implemented also by writing some Java code. However, Java code isn't good place for specifying things that change - putting details into Java code is said to be hardcoding, which is often considered bad.

JICE makes it easier to initialize and configure application. Of course this doesn't mean that all the initialization code and configuration data must be put into the XML files of JICE. The correct ratio between the content in the XML files and the content in the Java code varies from situation to situation.

2. 2. What is an engine?

In this context, the term engine refers to a software module:

  1. an engine is specialized in performing some particular task
  2. the behaviour of an engine is controlled with some high-level instruction language.

Here are a few example engines that match the definition:

Engine Specialized in Instruction language
A SVG renderer drawing on screen SVG
HTML browser drawing on screen (displaying a GUI) HTML
XSL Transformer transforming an XML document XSLT
SQL Database storing/manipulating data SQL

The example engines are all very advanced - they are very flexible and their instruction languages are very advanced. But they none of them can be considered as a general purpose programming language.

2. 3. Why to use an engine?

Engines are used because:

it is easier to write instructions for an engine and let the engine perform the task than to perform the same task with a general purpose programming language.

2. 4. Scripting languages vs. engines

Scripting languages exists much for the same reason as engines - some tasks are too slow to implement on a system programming language. There are no obvious differences between a a scripting language and an engine. An engine can be thought of as primitive scripting language.

Scripting languages are often more general purpose than engines and engines are more declarative (no if and loop structures, etc.)

3. JICE - an engine for initializing Java applications

JICE is an engine for initializing Java applications.

JICE defines a model for constructing (initializing) an application that has previously been lacking in Java.

3. 1. Constructing a toy from Lego blocks

The Lego blocks serve as a good metaphora that is used for demonstrating the construction model of JICE.

Lego blocks are simple components that, when attached to another Lego blocks, can form more complex structures. Almost any kind of a toy can be built from a set of elementary building blocks, which has made Lego technology popular amongst children in many generations.

Here is a formal description of the process of constructing a toy with Lego blocks.

Lego-Building Process

  1. Instructions list detailed step-by-step procedures that are needed to create a toy. The instructions specify the kind of Lego blocks needed and how they are attached.
    • Of course, most children don't 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. There is a storage of available Lego blocks. The construction requires that the storage contains the required blocks.
  3. The child follows the instructions and builds the toy:
    1. the required blocks must be picked out of the storage
    2. the blocks must be attached to each other.
  4. When all the instructions have been applied, the toy is finished. The toy consists of a set of inidividual Lego blocks. The toy may be used in several ways:
    • The child that constructed or some other child it may play with it.
    • 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.
    • etc.

3. 2. 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:

JICE Process

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

  1. The instructions are put into a JIC file that specifies the kind of Java instances needed and how they are combined together. JIC file is a XML file that contain JIC Language code.
  2. In addition to the JIC file, some runtime parameters can be provided. Parameters are Java instances created outside JIC Engine.
  3. Classpath specifies what kind of building blocks i.e. Java classes are available and therefore specifies the kind of Java objects that can be created. A succesful construction requires that the classpath contains the required classes.
  4. JIC Engine follows the instructions, creates the required Java objects and combines them as required.
  5. When all the instructions have been applied, the Java application is initialized. The application is a graph of Java objects i.e. a Java object that has references to other Java objects. The application may be used in several ways:
    • It could be used as is, for example if the application is a standalone desktop application.
    • The application could be a part of a bigger whole: a component in some application, etc.
    • etc.

4. JICE vs. existing initialization tools

4. 1. Initializing an application with Java code

With plain-old Java code, an application is of course initialized by writing a bunch of Java code that invokes constructors and factories, sets properties, calls various methods, etc.

However, standard Java tools don't specify where this initialization code should be. Typically, the code is scattered across many application classes. Some of the code may be in a main method. There may be special factory classes that perform the initialization or a class may have initalization logic in the constructor or in some init method. There is normally no central location that would specify the structure of the application.

Also, the initialization code is usually ugly. Java language isn't good at expressing multiple method and constructor invocations in a sequence, it is better in expressing application logic and data models.

4. 2. JICE vs. Java code

JICE collects most, if not all, of the initialization code into a central location - into an XML file (a JIC file). The tree hierarchy of the XML file visualizes the structure of the Java instances.

No specific examples are shown here - hopefully other examples of JICE show that JICE is better in initialization than Java code.

4. 3. Existing Java initialization tools

Java world has various technologies that address the problem of initialization.

Technology Description
web.xml Defines the servlets of a J2EE application in an XML file. Each server-implementation has an engine that interprets the XML data and initializes the necessary servlets.
Tag Library Definition (TLD) Specifies the details of a JSP Tag library in an XML file
JAXB A Java-XML binding tool that makes it possible to transform an XML document into a set of Java instances and vice versa.
Apache Ant A Java engine for performing build-process related tasks. The tasks to be performed are specified in an XML file.

Here are a few notes on the technologies:

4. 4. Why to use JICE?

Here are the most important arguments on why JICE is better than existing technologies:

  1. common XML format
    • All of the existing technologies have an XML format of their own.
    • JICE defines a common XML format that could be used any Java application.
    • Developers doesn't have to learn many XML formats.
  2. rich data model
    • JICE manipulates Java objects. It doesn't try to simplify things by manipulating only string values.
    • The rich data model means that the flexibility that comes from the use of an object-oriented programming language is not taken away.
  3. no Java API hiding
    • Many J2EE technologies try to hide the Java API. There are web.xml, application.xml and .tld files, JSP Tags, JSP expressions, etc. that all try to hide Java APIs or abstract away the Java language code.
    • However, usually all of these things are being manipulated by a Java programmer. Why should Java APIs and Java code be hidden from a Java programmer?
    • JICE doesn't hide the Java API of the application that is being initialized.
    • This way an application developer needs to document only the application API - not the options available in the XML format.

4. 4. 1. JICE vs. Java code

4. 4. 2. JICE vs. web.xml

Instead of web.xml, the initialization of servlets could be implemented with a JICE-based solution. Of course, this would require a change in the J2EE specification and will probably never happen. Anyway, this case still demonstrates situations where JICE could be used.

The primary web.xml

JICE could replace and .tld files. They are both XML files that are used for initializing certain kinds of objects.

build.xml files used by Apache Ant could be replaced by JICE, if the Ant API would have been designed to be used directly. However,

5. The need to configure applications

5. 1. What is application configuration?

By configuring an application we mean modifying some parts of the application without building (compiling) the application again. Typical example of a configuration task is the modification of a configuration file (a text-file perhaps?) that causes a change in the appearance of the application - a font or color is changed, etc.

In this context the alternative to configation is programming. Programming means modification of the application code of the application. The modification has effect only after recompilation.

This idea can be summarized by stating that a typical application consists of application code and configuration data:

application = code + configuration

This separation of code and configuration may be blurred in some situations. But it is clear in a Java application that uses Java properties files:

Java application = Java classes + properties files

5. 2. What are configuration files?

The configuration data can be in the form of text-based configuration files or it can reside in a database. The main point is that the content is not expressed in application code. The most common configuration file is probably a text file with some kind of a structure. Typically a configuration files contains trivial details, whereas the complex logic is put in the application code.

5. 3. Why to use configuration files?

In general, configuration files are used because they are easier to create and modify than the application code. Here are some of the problems that configuration files are trying to solve:

Here is a list of various methods that varous configuration tools try solve the problems:

5. 4. Configuration files vs. engines

Configuration files can be thought of as primitive engines. The aspects that can be modified through configuration files are typically very limited. The use of a configuration file in an application may require that some code for reading the configuration files is written. Engines are typically clearly encapsulated and can be readily used.

5. 5. Configuration and initialization

JICE uses the term configuration for referring to the information that tells JICE how to initialize an application. The configuration is always expressed in JIC Language code. So:

Java application
a graph of Java instances.
  • This definition is clear for a Swing application that consists of core application instances and GUI instances. All the objects are connected.
  • The definition doesn't quite apply for a web-application whose instance graph is more scattered - servlets, JSPs, EJBs, etc. But at least some parts of a web-application are clearly graphs of Java objects.
initialization

6. The need for application configuration

JICE is based on the assumption that Java applications needs to be configured. By configuration we mean the modification of some parts of the application without building (compiling) the application again. Typical example of a configuration task is the modification of a text-file that causes a change in the appearance of the application - a font or color is changed, etc.

The alternative to configation is programming. Programming means modification of the Java source code of the application. The modification has effect only after recompilation.

This idea can be summarized by stating that a typical Java application consists of Java classes and configuration data:

Java application = Java classes + configuration data

The configuration data can be in the form of text-based configuration files or it can reside in a database. The main point is that the configuration is not expressed in Java code. There are many formats for expressing the configuration data, and they usually try to achieve some of the following advantages over Java code:

7. The problem with application configuration

8. Usage scenarios

9. Disadvantages

10. Component based application construction model

11. JIC file visualizes the structure of the application

If the application initialization logic is scattered among many Java classes, it is difficult to understand the structure of the application.

Tools like UML can be used for visualizing the relationships of the types (classes) but it doesn't provide information on the objects (instances).

JICE makes it possible to put most, if not all, of the application initialization 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 also direct, i.e. the XML tree corresponds very closely to the Java object tree.

Therefore the XML tree in the JIC file provides at least some kind of a visualization of the structure of the application.

12. Configuration of unexpected properties

Any property can be configured - not just those that were expected to be configured.

This advantage is evident especially when comparing JICE with the use of Java properties files.

12. 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 adds various kinds of constructors and setXXX-methods into the class. The decisions of the author can limit the ways how the objects of the class can be parametrized.

12. 2. Parametrization in Java property files

If the application is to be configured with Java properties, the author of the configuration system must decide what properties of the Java class in question can be configured with the properties file. This is a second decision that can limit the the ways how the objects of the class can be parametrized. Probably only the most critical properties can be configured first. Support for the configuration of other properties is added as the application matures. The support for a new property must always be coded into the application.

12. 3. Parametrization in JICE

JICE can call any method of an object that is specified in a JIC file. The programmer doesn't have to make the second limiting decision as in the case with Java properties files.

The configuration of properties that were not expected to be changed doesn't require a code-change. Only re-configuration.

13. 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.

Here is a short JIC file that creates a javax.swing.JFrame, sets a few of its properties and puts a javax.swing.JLabel inside the JFrame.

<?xml version="1.0" encoding="UTF-8"?>
<jframe xmlns="http://www.jicengine.org/jic/1.0"  action="this.show()"  class="javax.swing.JFrame"  parameters="title">
  <title>This is a JFrame</title>
  <contentPane  instance="PARENT.getContentPane()">
    <label  action="add(this)"  class="javax.swing.JLabel"  parameters="text">
      <text>This is a JLabel</text>
      <opaque  type="boolean">false</opaque>
    </label>
    <opaque  type="boolean">true</opaque>
    <background  type="color">200,90,90</background>
  </contentPane>
  <size  class="java.awt.Dimension"  parameters="w,h">
    <w  type="int">300</w>
    <h  type="int">300</h>
  </size>
</jframe>

If all the attributes are stripped, all the Java specific details disappear, and the content is almost readable to a non-programmer.

<?xml version="1.0" encoding="UTF-8"?>
<jframe xmlns="http://www.jicengine.org/jic/1.0">
  <title>This is a JFrame</title>
  <contentPane>
    <label>
      <text>This is a JLabel</text>
      <opaque>false</opaque>
    </label>
    <opaque>true</opaque>
    <background>200,90,90</background>
  </contentPane>
  <size>
    <w>300</w>
    <h>300</h>
  </size>
</jframe>

14. Laborous to create, easy to modify

JIC Language is quite verbose, as is XML content in general.

On the other hand, the format tries to be as clear as possible. The idea is, that ones the JIC file has been written, the values of individual properties should be easy to change. All the objects or values can be given a name, so it should be easy to locate the correct spot.

15. Disadvantages

15. 4. A new XML format needs to be learned

XML data is typically is very verbose and data in JIC Language format is relatively self-describing, so a person should be able to do minor changes into a JIC file that already exists. Anyone wanting to create a new configuration with JICE must however learn JIC Language.

15. 5. JIC Language is for Java programmers

JIC Language code is too close to Java programming that a non-programmer won't probably understand a thing. If an XML configuration format suitable for non-programmers is needed, JICE is not the solution. (unless XML data in a non-programmer friendly format is transformed in to JIC Language code with e.g. XSLT.)

15. 6. No security or information hiding

There is no way to guarantee that a JIC Language code doesn't contain malicuous instructions. JIC Language code close to Java code. Don't accept if you can't trust the author.

JIC Language code doesn't hide the internals of the Java application that is being configured. If you want to hide something, you have to hide the JIC files also.

15. 7. Performance overhead

Of course, the information expressed in XML must first be parsed. The Java instructions in a JIC file are executed through the reflection API, which is not as fast as plain Java code.