9 Java JDK1.1 and JDK1.2 Versions,
GMJ1 and GMJ2

1 Introduction

The Java JDK1.1 and JDK1.2 versions (in short, GMJ1 and GMJ2)
of global optimization software are class frameworks [Grybauskas, 1998]. Both GMJ versions implement:
global optimization algorithms ($METHODS$),
functions to be optimized ($TASKS$),
objects to be represented visually ($ANALYSIS$).

GMJ can be run as an applet or as a stand-alone application. One can run applet over the Web. This cannot be done by an application. Security restrictions is the disadvantage of applets. We need security permits to read/write files and to connect third parties (see Section 4.6).

These restrictions are lifted using stand-alone applications. Using stand-alone applications, the most recent Java features supported by the Java Development Kit (JDK) can be exploited. The reason is that web browsers are late adapting new Java Developer Kits (JDK), as usual. If JDK is installed, then applets can be loaded directly by appletviewers.

The JDK1.2 system provides new facilities as compared with JDK1.1. For example, Just-in-Time compilers (jitc) increase the speed several times. The 'policy' files of JDK1.2 exempts trusted users from some security restrictions.

2 Starting GMJ

In this and flowing sections, the user guide of GMJ is described. First we consider the parts that are common for both JDK1.1 and JDK1.2. Then the features of JDK1.2 are mentioned.

1 Configuring Applet

The sample file $gmj.html$ shows how to set configuration parameters of the $gmj$ applet. The $<applet>$ tag of GMJ1 looks like this:

In this example, $code$ specifies the applet class and should not be changed.
$codebase$ specifies the relative URL of the applet class archive file and user class files. The URL is relative to the location of the HTML file where the $<applet>$ tag resides or is an absolute path.
$archive$ lists the class archive files.
$width$ and $height$ specifies the applet size, as it appears on the HTML page.
$TASKS$ lists tasks which are available when the applet loads. Complete class names (package and class name) are separated by $\vert$ symbol.
$METHODS$ lists methods which are supported when the applet loads.
$ANALYSIS$ lists visual analysis classes which are supported when the applet loads.

Here is the fragment of the GMJ2 $<applet>$ tag, which differs from GMJ1:

The difference is that less methods, tasks and analysis objects are included in the GMJ2 example. Different archive file $gmj20.jar$ is used.

2 Configuring Stand-Alone Application

To run GMJ as a stand-alone application, the Java Runtime Environment (JRE) is required. First, $CLASSPATH$ should be configured, so that the GMJ classes can be found by the JRE. An application is started by loading the $lt.ktu.gmj.ui.GMJ$ class. Using Linux the command is:

The application accepts three optional parameters: tasks, methods, and analysis objects. In the example, only one task $Sin$, one method $Bayes$ and one analysis object $Projection$ is included, for simplicity.

3 Running GMJ

1 Display and Control

GMJ displays a tab control that has three choices: $method$, $task$, and $operation$. The appropriate pages can be selected by clicking on the page tabs.

Figures 9.1,9.2, and 9.3 show the method , the task and the operation pages for the $Exkor$ method and the $Sin$ task using GMJ1.

Figure 9.1: Method page with parameter fields.

Figure 9.2: Task page with input fields.

Figure 9.3: Output page with results fields.

Figure 9.4 shows how the function depends on the first variable $x$

Figure 9.4: x-projection.

Figure 9.5 shows how the function depends on the second variable $y$.

Figure 9.5: y-projection.

Figures 9.4 and 9.5 show that using the $Exkor$ method one gets clear projections defining how the objective function values depend on different variables. That provides a sort of "visualization" needed for the preliminary investigations. Using other methods, $Projection$ windows show fuzzy "projections." The reason is that variables change together.

Figures 2.3 (bottom), and 2.4 show projections obtained while optimizing the randomization parameters for the knapsack problem by the method $Bayes$ .
Figure 2.3 (top) shows how the best current value of the knapsack depends on iteration numbers.
The $Spectrum$ window shows how depends the frequency of the objective function $f(x)$ values on iteration numbers. Different frequencies are represented by different colors.

2 Task Selection

Six tasks are installed in GMJ1.

Sin

: the Sine Function.

Tvarka

: the School Scheduling.

Portfolio

: the Optimal Investment, the "Portfolio" problem.

WalrasModel

: the Walras Equilibrium.

Knapsack

: the Knapsack problem.

The detail description of these examples is the subject of the next part of this book. By clicking the $tasks$ label, one opens a list of available tasks. The task is selected by clicking the label of this task.

Figure 9.2 shows the selected task $Sin$. After selection, the tasks implementation class is loaded and the configuration window is opened. The configuration window depends on the actual task selected.

Figure 9.2 shows the window for $Sin$. There are fields that define properties of tasks and the minimization domain. One can keep the default values or change them. If the entered value is invalid or out of bounds, the field turns red and the value is not stored.

3 Operation Control

The minimization process is controlled by the operation page (see bottom of Figure 9.3). There are three control buttons: run, pause, stop. The run button starts the optimization. The pause button interrupts the calculations. To abandon them completely, press the stop button.

4 Analysis of Results

The numerical optimization results are shown in the output table on Figure 9.3 displaying the following parameters:

$Iteration$

shows current iteration numbers,

$F(x)$

, shows current values of the objective function $f(x)$,

$X,\ Y$

, show coordinates of current points.

To select the form of graphical results, one clicks the 'Convergence' field that is at the right side on the top. Three analysis objects are installed.

$Convergence$

shows how the best obtained objective function value depends on iteration number (see Figure 2.3),

$Projection$

shows how the objective function depends on the first variable (see Figure 9.4), the variable number can be changed by clicking at the small button in the lower-left part of the window,

$Spectrum$

shows how depends the frequencyof objective function values on the iteration number.

5 Method selection

In GMJ1 five global methods are installed:

Mig1

: Monte Carlo.

Bayes

: Bayesian by Mockus.

Unt

: Extrapolation by Zilinskas.

Globt

: Clustering by Torn.

Exkor

: Bayesian coordinate search by Zilinskas.

and two local methods:

LBayes

: Stochastic Approximation by Mockus.

Flexi

: Simplex Nonlinear by Nelder and Mead.

For the detail descriptions see [Mockus et al., 1997].

One opens a list of available methods by clicking the $methods$ label of the GMJ tab control. The method is selected by clicking the label of this method. Figure 9.1 shows the selected method $Exkor$. After the selection the method's implementation class is loaded and the configuration window is opened.

The configuration window depends on the actual method selected. As usual, there is the $Iterations$ field where the number of iterations is defined, by keeping the default values or by changing them. The field $Initial points$ (see Figure 9.1) shows the number of observations for a preliminary survey. The preliminary survey is done by some methods including $Bayes$. If the entered value is invalid or out of bounds, the field turns red and the value is not stored.

4 Updating GMJ

Compiling is needed to add new methods, new tasks, new analysis objects. One compiles, too, to change the data which is not on the graphical interface. For example, to add a new task 'NewTask.java', a new method 'NewMethod.java', and a new analysis object
'NewAnalysis.java' one does these operations:

• compile the 'NewTask.java' , 'NewMethod.java',
  and 'NewAnalysis.java'
  making the corresponding $class$ files
  
  
• create the additional archive file '$gmjg\_add.jar$' by including the new class files
  
  
• update the applet 'gmjall.html' by updating the $TASKS$,
  $METHODS$, and $ANALYSIS$ parameters and by adding the new archive file
  
  

1 New Tasks

The task class implements the Task interface:

The interface $Task$ is derived from $Customizable$. This means that it is configurable by users. Details are explained in Section 4.3.
A user defined method $double f$ calculates values of the objective function at the $Point\ pt$
The class $Point\ pt$ defines the array of optimization variables belonging to the $Domain$.
The object $domain$ returns the class $Domain$, which defines a set of feasible decisions.

In GMJ1 this is a rectangular region defined by the lower and upper bounds of optimization variables.
The $Domain$ is an abstract class:

The abstract function $dimensions$ should be overridden to return the descriptions of the domain dimensions. These descriptions are in analysis and configuration windows.
Variables $min$, $max$ and $defaultPoint$ are created by the class $Domain$ and initialized by the derived class, as required. The $Point$ class implements a point in a $n$-dimensional set $Domain$.

The class $Point$ constructs from a $Dimension$ object.

One does the following six steps to implement a new task:

• derive a class from the class $Domain$,
• provide the constructor to initialize the default dimension range and the default point,
• override the method $dimensions$ and return descriptions of the dimensions of the domain,
• create the new class, which implements the interface $Task$, or extend an abstract class AbstractTask to make the code compatible with future GMJ releases,
• override the method $domain$,
• override the method $f$.

1 Example of Task Sine

2 New Methods

GMJ can be extended providing additional optimization methods, which may be more efficient or more flexible. The method class should implement the $Method$ interface:

The interface $Method$ is derived from the interface $Customizable$, which requires it to be configurable by the user. $iterations$ returns the total number of iterations.

Most of the optimization methods have the configurable $iterations$ property. Therefore, the $MethodBase$ abstract class is implemented on top of the $Method$ interface. It overrides the $iterations$ and the $customize$ methods. The method $run$ is overridden by inheriting from $MethodBase$. The method $run$ runs the optimization method on the selected $Task$, writes the results to the specified $ResultLogger$, and returns the best result.

The $ResultLogger$ interface gathers the generated results and stores them. The $ResultLoger$ interface defines the following members:

The method $log$ is to log the result of each iteration of the method.
Usually, the class implementing the $ResultLoger$ updates the user interface objects reflecting the method's progress when $log$ is called. Some methods need a history of optimization. The method $logAt$ provides that by returning the $Result$ logged previously in the iteration $it$ using the method $log$. The class $Result$ contains the iteration state:

3 Configuring Property Manager

Many objects are configured by users. For example, a user may want to change the number of iterations or the ranges of the optimization domain. $PropertyManager$ shows the properties, which may be changed. The $PropertyManager$ is a property list that is described by this interface:

The method $add$ is to add new $Property$ objects to the list. The property consists of a property name or a label and a value editor. The value editor is for changing the value of the property.

The important component of the $Property$ object is the
$PropertyProvider$. This is an object, which knows how to retrieve the value of the property and how to store it after the changes made by the editor. The custom value retrieval and storage methods are implemented because in Java one cannot to pass primitive objects by reference.

A set of property providers is in the GMJ package, including:

• the class $DoubleArrayProvider$ accesses the double array elements
• the class $FieldProvider$ uses the JDK1.1 Reflection classes providing access to any field of a class

1 Example

The following sample code shows how to add a property called the "Initial Speed" stored as the second element of the array $customData$. The initial speed can change in the range from 10 to 50 km/h. by this interface:

Here is an example how to add a property named "Offset" stored in a public variable $offset$ of the calling class

Adding a property to the property manager, an editor of the appropriate type is created. If the user changes the value, the value is automatically checked, validated and stored in the second element of the array. $customData$.

1 Writing Custom Property Provider

When a property value is stored as a field, then a custom access class should be provided to reach that value. This class implements the $PropertyProvider$ interface requiring many functions to be overridden. Most of them are implemented in the $SimplePropertyProvider$ class, which can be used as a base.

1 Example

This sample code shows how to provide an access to the field
$multiplier$ of the $Sin$ class, which is $double$:

Note, that in Java 1.2 reflection is always available. Therefore, applying GMJ2 one applies $FieldProvider$, instead of writing custom providers.

4 New Analysis Objects

GMJ provides three analysis objects: $Convergence$, $Projection$ and $Spectrum$ (see section 3.4). The new tasks may need the new analysis objects. The new analyzers may be derived from any base class. They can be implemented as some windows, or they may log data to some external files. The only requirement is to implement the following $ResultAnalyser$ interface:

To construct analysis objects the method $prepare$ is called. It asks the analysis objects to initialize. A $ResultRepository$ object is passed as a parameter. It contains information to initialize the analyzer.

The method $dispose$ is called when the analyzer is being deleted. It flush the open buffers or close associated windows. The data observer-notifier pattern is to deliver the results of real time calculations to the analysis objects. The data notifier has a list of data observers, which are notified when new data is available. To receive these notifications, the object implements the $ResultObserver$ interface and registers on the appropriate $ResultRepository$ class. The registration time is in the $prepare$ method: before leaving.

The method $logStarted$ signals that new calculations are going to be started.
The method $newResult$ signals, that a new result has just been added to the $ResultLoger$.
The method $newProgressResult$ signals that a method has made
progress and did find the better point.
The method $finalResult$ signals that the optimization is over.
The method $logDisposed$ signals that the $ResultLog$ is depreciated and cannot be used anymore. In such a case the observers should delete all the references to the $ResultLogger$ objects.

1 Example

Here is a simple analyzer to print the progress to console windows

5 Programming Tips

1 Aborting Calculations

If optimization lasts too long, a user wants to abort the calculations, as usual. When the $STOP$ button is pressed or the applet is about to exit, then an $interrupted$ flag is set for the $calculation$ thread. Therefore, $task$ and $method$ writers are advised to test for

2 Implementing Interfaces

Creating a custom method or task, the class implements a corresponding interface, as usual. The better alternative is to extend an abstract class, if available. For example, "extend $AbstractMethod$" is better as compared with "implement $Method$." This makes a code more compatible with future GMJ releases.

3 URL Address

The original web-sites are attached to the servers 'optimum.mii.lt' or 'mockus.org'. Therefore, in some examples, the URL addresses should be updated to extract data from the local server .

On the 'Task' menu of GMJ1 global optimization software the examples are: "Portfolio," "Tvarka," and "Knapsack." In the task of school scheduling 'Tvarka.java', the URL address of the applet host is defined automatically and is shown on the graphical interface. In the task "Knapsack", some URL address is shown on the screen. It should be updated by users. In the "Portfolio" task, the URL is defined in the file 'Portfolio.java'. Therefore, recompiling is needed to extract the data.

6 Security Restrictions

1 stand-alone Application

Loading applets from their hosts, called as "applet hosts," one meets security restrictions. Applying GMJ one often needs to read/write a file on a client site or to connect to a strange host. A host that is different from the applet host is called as the "strange host."

If GMJ is loaded as a stand-alone application, one can accomplish these tasks without security restrictions. Loading GMJ as an applet one is running in a "sand-box." That means: no reading/writing files on client sites, no connections to strange hosts.

2 Signed Applets

A way to escape the sand-box is to sign the applet. The signature is a guarantee to others that the applet is friendly. The signature does not prevent damage, but it serves as a stamp of good intention. It identifies the responsible party, if damage does occur.

A way to guarantee that a signature is authentic is to notarize it by a Certificate Authority (CA). The Certificate Authority authenticates the identity of the applicant and then issues a signing certificate.

Anything signed with a signing certificate will bear the name of CA besides the signer name. The signature can be traced, by way of CA, to the signer.

"VeriSign,Inc." is the recognized CA. Signing certificates can be obtained at:
$http://digitalid.verisign.com/software\_publishers.html$
For an individual, it costs $40 per year for both Netscape and Internet Explorer. The prices are expected to drop. Here is a fragment of a signed applet:

The ARCHIVE parameter is parsed by Netscape. The CABBASE parameter is parsed by Internet Explorer. Different browsers use different signatures.

For example, the "Netscape" requires to change some parts of Java software, besides signing $jar$ files.

Signing in "Sun Appletviewer" is simpler. The description is in the JDK documentation. Here a user needs the certificate and a "policy" file, where all his rights are listed.

To sign "Internet Explorer" one downloads the Microsoft Java Developer Kit. The additional information is in [Vitek and Jensen, 2000] and on web-sites:
$http://www.fastlane.net.\tilde{~}tlandry/javafaq.txt$
$http://ourworld.compuserve.com/homepages/\\ jozart/article/index.html$

Note, that one should not change the existing 'gmj20.jar' file in GMJ2. Otherwise, security restrictions might be violated. Therefore, extending GMJ a user creates his own $jar$ files.

5 Features of GMJ2

1 Custom Result Analyzers

Visualization is a convenient way to represent the input of tasks and the results. As usual, the different tasks need different visualization. For example, considering the school scheduling (see chapter 3), one wants to see the best obtained schedule. Considering the existence of the equilibrium in the Walras model (see chapter 11), it is important to see how profit functions depend on prices, resources, and other parameters.

In such cases the output is implemented as an analysis object (see section 4.4). However, we need many analysis objects to satisfy all the tasks. To show only task-specific analysis objects, in GMJ2 the $Task$ class implements the $yzers 0$ interface

The $analyzers$ function returns a class list of custom analyzers of the task.

1 Example

This is a sample task implementation. It states, that there exists a custom analyzer, called "Diagram".

2 Domain Constraint Function

Using GMJ1, the methods consider rectangular feasible regions. These regions are bounded by lower and upper limits defined on the screen. Therefore, in GMJ1 "non-rectangular" constraints are included using penalty functions. This is not always convenient.

In GMJ2 the class $Domain$ is extended to represent any
non-rectangular domain. This domain includes the function.

This function defines a constraint value at the point $pt$. It returns number 1 by default (see Figure 9.6). Writing new methods in GMJ2, one checks the constraint function before calling the objective function $f$ of the $Task$. If a method does not support constraints, one multiplies the constraint value by $f$ and minimizes the result.

Implementing a task in GMJ2, the custom domain class can be derived from the $DomainWithConstraint$ class. This enables a user to specify the constraint function at run time. $DomainWithConstraint$ adds an entry field in the task configuration panel. In this panel, any algebraic expression can be entered and compiled at run time (see Figure 9.6).

Figure 9.6: Task page for the $Sin$ task with one nonlinear constraint.

Here the constraint is entered by algebraic expression $-X1^2-X2^2+1$ meaning that $-x_1^2-x_2^2+1 \ge 0$. Using these tools, GMJ2 users can specify any constraint function.

3 Video-conferencing by GMJ2

Using GMJ2 in the videoconferencing, one needs Multiple Monitor Support. One can render on multiple screens by creating $Frame$, $JFrame$, $Window$, or $JWindow$ objects with the $GraphicsConfiguration$ of the target $GraphicsDevice$.

The new Frame constructor,
$Frame(GraphicsConfiguration)$, enables creation of a Frame object on a different screen device.

The new Window constructor,
$Window(Window, GraphicsConfiguration)$, constructs a new invisible window with the specified window as its owner and the $GraphicsConfiguration$ of a screen device.

The new $GraphicsConfiguration\ getBounds$ method returns the bounds of the $GraphicsConfiguration$ in device coordinates. If you have a virtual device, then the device coordinates returned from $getBounds$ are virtual device coordinates.

Finally, the new Component
$getGraphicsConfiguration$ method returns the $GraphicsConfiguration$ with which the $Component$ was created.

In a virtual device configuration consisting of more than one physical screen device, the $GraphicsConfiguration$ objects' coordinates are relative to the virtual coordinate system. For this reason, virtual coordinates must be used when calling the $setLocation$ method of a $Frame$ or $Window$. Similarly, calling $getBounds$ of a $GraphicsConfiguration$ in a virtual device environment returns virtual device coordinates.

The following code sample creates a $JFrame$ object for each $GraphicsConfiguration$ on each screen device in the $GraphicsEnvironment$. It offsets the coordinates of the intended location of the $JFrame$ with the bounds of the $GraphicsConfiguration$ to ensure that the $JFrame$ appears on the screen of the specified $GraphicsConfiguration$.

If the bounds of a $GraphicsConfiguration$ is not taken into account in this sample, a $JFrame$ would appear at location $(i*50, i*60)$ on the primary screen, which might be different than the screen of the specified $GraphicsConfiguration$.

For more information on how the Java 2D API supports multi-screen environments, see Rendering in a Multi-Screen Environment in the Programmer's Guide to the Java 2D API.

This applies to other examples using Java1.2.

4 Running GMJ2

The $constraint$ function is included into the $Tasks$ page of of GMJ2 (see Figure 9.6). In this Figure the $Sinn$ task is active. There are several different tasks: $Tvarka$, $WalrasModel$, $DuelStarwars$, $FlowShop$ and four types of sine and cosine. $Sinn$ is sine with a non-linear constraint. $Sinl$ is sine with a linear constraint. $Sinc$ is sine without constraints and $Cosc$ is cosine without constraints. The task $Tvarka$ is for the school scheduling [Nemajunas and Remeikis, 1999]. $WalrasModel$ is for the Walras problem and $DuelStarwars$ is for the Duel problem.

The $Methods$ menu of GMJ2 is in Figure 9.7.

Figure 9.7: The method window of GMJ2.

There are five global methods: $Mig1$, $Bayes$,$Exkor$,$Globt$, and $Unt$ and three local methods $Shitk$, $Flexi$, and $Lbayes$. The method $Shitk$ is the Java version [Margelevicius, 1999] of the non-linear programming method by Schittkowski [Schittkowski, 1985]. Names of remaining methods are the same as in GMJ1.

The $Analysis$ menu of GMJ2 is in Figure 9.8.

Figure 9.8: The analysis menu.

Three analysis objects: $Convergence$, $Projection$, and $Spectrum$ are common for all tasks. Four analysis objects: $Tvarka$, $WalrasProfit$ and $DemoAnalyzer$ are task-specific. $Tvarka$ shows the initial and the optimized school schedules. $WalrasProfit$ shows how the server profit depends on prices and other parameters. The task-specific analysis objects should be seen, if corresponding tasks are on. Otherwise, they should be closed. The analysis object $DemoAnalyzer$ satisfies this condition. $DemoAnalyzer$ is the graphical interface of the duel problem. One see it, if the $DuelStarwars$ task is on. Figure 9.9 shows this.

Figure 9.9: The analysis menu including the $DuelStarwars$ task.

Optimization results and the convergence line is in Figure 9.10.

Figure 9.10: Optimization results and the convergence line.

In the 'Spectrum' window there is an additional option. The window shows how depends the distribution of $f(x)$ values on each variable $x_i$ (see Figure 9.11).

Figure 9.11: The distribution of $f(x_1,x_2)$ values with respect to $x_1$.