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:
- an engine is specialized in performing some particular task
- 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.
- A running Java application consists of Java instances.
- Initialization is a process where the Java instances of the application are created and the state of these instances is set.
- JICE is an engine that makes the initialization easier than it would be with Java code
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.
-
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.
- There is a storage of available Lego blocks. The construction requires that the storage contains the required blocks.
- The child follows the instructions and builds the toy:
- the required blocks must be picked out of the storage
- the blocks must be attached to each other.
- 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:
Similarities to the Lego process are obvious. Here is a explanation of the details:
- 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.
- In addition to the JIC file, some runtime parameters can be provided. Parameters are Java instances created outside JIC Engine.
- 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.
- JIC Engine follows the instructions, creates the required Java objects and combines them as required.
- 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:
- All technologies use XML
- Each technology uses an XML format of its own
- All technologies provide an XML->Java mapping.
- JAXB provides also mapping from Java->XML.
- The available data-values are strings or ids. Numbers, booleans, objects are not directly supported or the support is limited.
- All technologies try to hide the Java API that is being manipulated with the XML
- a
web.xml
contains class names but init-params and url-mappings are abstractions of the resulting Java instances. Init-params are Strings, the implementation of url-mappings is vendor-specific. - In JAXB, the XML document that is mapped to the Java instances is typically not Java related. A special rules file is used for specifying the details of the mapping.
- The XML format is the main interface to Apache Ant. Ant has a Java API also that can be used directly, but the API is not designed for this.
- a
4. 4. Why to use JICE?
Here are the most important arguments on why JICE is better than existing technologies:
-
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.
-
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.
-
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.
- Many J2EE technologies try to hide the Java API. There are
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:
- Faster modification - Some parts of the application need to be changed often. Application code is usually static and slow to change.
- Easier modification - There is a need to change some parts of the application without thinking too much. The modification of application code typically requires programming skills and the change can cause problems.
- Modification of related but scattered things - Some aspect of the application needs to be changed, but the data related to the aspect is scattered all over the application code and is difficult to find.
- New application instances - There is a need to have create many variations of the application that are partially different.
Here is a list of various methods that varous configuration tools try solve the problems:
- No compilation - application code needs to be compiled, configuration is typically interpreted.
- Simpler format - the configuration format may simpler so that one doesn't have to think so hard when modifying the configuration. Some configuration formats are even intended for non-programmers.
- Domain specific - the configuration format may be specialized into the application domain, where as the application code is typically expressed in some general purpose programming language. Again, this makes the configuration more easier to understand.
- Collection of related data - all data related to a certain aspect is collected into the same configuration file.
- Overriding of default values - configuration format makes it possible to define default values which can be overridden when possible.
- Selection of the configuration files - new instances of the application are created by changing the set of configuration files used.
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:
- configuration - a set of instructions that specify what Java instances should be created and how their state should be set.
- initialization - the process where the instances are created and their state is set.
- 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.
<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.
<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.