Today developers are creating a full spectrum of Internet applications and systems ranging from enterprise servers to handheld devices that manifest a number of unique requirements. Although these applications and systems are commonly written in Java, they have different footprint requirements depending on the platform they run on. However, they need to have the same look and feel regardless of where they're deployed.

This article will describe the technical considerations that enable an application or system to run on a broad range of platforms. Minimizing the memory footprint to suit a range of environments, from network servers to PDAs and other devices, is the core of this issue. Applications that require a minimum memory footprint will benefit from two important factors: (1) the JVM (Java Virtual Machine) class loader and (2) a development strategy for building applications or systems using Java "factories."

How to Build Dynamic Footprint Applications and Systems
The JVM class loader has the ability to load and unload from memory the subset of class files needed at any given time by the application or system (see Figure 1). By contrast, Algol-based applications, including those written in C or C++, require the entire executable to be brought into memory in order for any part of the application or system to execute, even if only a subset of the functionality is required at runtime (see Figure 2). This is an important and significant difference that can dramatically impact the runtime memory footprint.

To achieve the greatest possible benefit from the JVM class loader, PointBase has employed Java "factories" in the design and architecture of its database management system. Using factories allows developers to minimize class file size (and disk requirements) by including only those factories needed by the application. More significant, a disciplined implementation of factories in the database ensures a minimum memory footprint - the JVM class loader keeps in memory only those classes needed at any one time by the application.

Using the discipline of factories and the JVM class loader allows you to create dynamic footprint applications and systems that won't require special tailoring by an end user to meet limited memory requirements, especially for memory-constrained devices and systems such as PDAs.

Code Snippets
The following code snippets provide a simple example of the method that PointBase has used to create Java factories. This particular section of code demonstrates the compilation factory for a SQL Create Table statement.

public class createTableCompilationFactory
{
public compilerInterface getCompiler( )
{
    return new createTableCompiler( );
}
public definerInterface getDefiner( )
{
    return new createTableDefiner( );
}

public compilerInterface getExecution( )
{
    return new createTableExecution( );
}

public parserInterface getParser( )
{
     return new createTableParser( );
}
}

The methods in this class are invoked when an SQL Create Table statement is executed in the application.

With most SQL statements a database management system needs to parse the statement, check definition information in the system catalogs and then compile it into an internal format for execution. With PointBase, when an SQL statement is encountered the appropriate factory will be used to invoke constructors that cause the parsing, definition, compilation and execution aspects of an SQL statement. This approach allows you to separate unassociated functionality, and dynamically limit or add functionality without causing linking problems commonly encountered with other development languages.

Benefits of Maintaining Applications Written Using Java Factories
Algol-based applications and systems don't have the ability to dynamically load objects. The entire executable must be loaded into memory in order for even one object to execute. Additionally, most Algol-based languages don't support or allow the factory concept.

Many developers may attempt to circumvent the restrictions of Algol-based applications by recompiling the application for each environment with only those features that they need. For example, some C-based database systems require the user to go through numerous steps with their application and database in order to generate a reduced runtime footprint (see Figure 3).

This methodology has a significant limitation when the application needs to be modified as these steps must be repeated and the application redeployed to all installations. This approach is extremely expensive and labor intensive for the application developer and the end user who must redeploy the application.

However, Java dynamically adapts to the applications and systems without end-user intervention. Algol-based products require end users to adapt their applications and systems. This difference is fundamental and crucial to deploying and managing small footprint applications in the field.

PointBase and Dynamic Footprint
PointBase delivers an object-relational database management system written in 100% Pure Java. Developers who wish to embed the PointBase database system within their application typically include the classes from the PointBase jar file in their own application's jar file. The developer can then control and monitor the runtime memory and disk footprint of the entire solution, including the database (see Figure 4).

For customers who don't need the full range of database functionality, PointBase's Java factory architecture provides a simple, automated way to customize the database for each application. For example, many applications don't need SQL security (privileges). Others, such as "palm" applications, only need SQL DML (Delete, Insert, Update), SQL Queries (Select) and Transaction management (Commit and Rollback) functionality. PointBase supports a wide range of application requirements and will dynamically minimize the footprint for a full range of applications and environments.