This section describes how to build a Java applet that uses the Host Access Class Library (HACL). Also described in this section are the requirements for preparing and compiling the source code.
Programs that use HACL classes must import the appropriate HACL packages to obtain class definitions and other compile-time information. The HACL packages can be imported into a Java source file using the following statements:
import com.ibm.eNetwork.ECL.*; // Base HACL classes
To import the HACL listener interfaces and event classes (only needed when using HACL events):
import com.ibm.eNetwork.ECL.event.*; // HACL event classes
To import the advanced HACL screen recognition classes (only needed when using the HACL screen recognition classes):
import com.ibm.eNetwork.ECL.screenreco.*; // Advanced HACL screen recognition classes import com.ibm.eNetwork.ECL.screenreco.event.*; // Advanced HACL screen recognition event classes
HACL files are located in the install_dir\toolkit\jars directory, where install_dir is the directory where you installed the Host Access Toolkit files (for example, C:\Program Files\IBM\Host Access Toolkit\toolkit\jars). The Java 2 environment is supported. JAR files for the Java 2 environment are located in the following directories:
where install_dir is the directory into which the Toolkit files are installed.
The following files contain full HACL support (except for a few noted exceptions):
These files support HACL functionality in English and include:
These files support HACL functionality in all languages that Host On-Demand supports (including English), and include:
These files are suitable for Bean Builder environments and for writing Java applications. However, since they are not signed, they are not suitable for downloading over the web through a web browser.
For downloading HACL applets, the HACL support has been divided into several smaller signed component archive files. JAR files for Appletviewer environments and Microsoft Internet Explorer environments are provided. Since download delays are important in web browser environments, the component archive files will allow users to specify only those components which will actually be used and will avoid costly delays of downloading support that will never be used.
To further optimize download times, release versions of the components are also provided. The release versions of the components have the trace code removed which means they will be smaller and download faster than their debug counterparts. Most users will predominantly use the release versions of the components for web environments and only use the debug versions when problem determination is required. For Java application environments, users can use either release or debug components (or even the habeans.jar file) since download times are not a factor.
Most components have debug and release versions, stored in subdirectories of the same name. However, some components, such as host code pages, only have a release version. Except for the host code page archives, you cannot mix some release versions and some debug versions. If problem determination is needed, or you are using debug components since download times are not important, you must use all debug components.
The table shown below shows all the different components, their release and debug names, and the components that they depend on.
Note: Except for hafntib, hafntap, hafnthe, hafntar, and the host code pages, the Java 2 versions of these components have a "2" on the end of the JAR file name (for example, habase2 and habasen2).
The following table shows the component names for the host code pages:
All applications will use the habase (or habeans) and hacp archive files since those contain the core HACL files and core codepage files, respectively.
To successfully compile and run your application, the CLASSPATH environment variable must be updated to include the JAR files needed by your application. For example, if you need 5250 file transfer, you would need to include ha5250xn.jar, ha5250n, haxfern.jar, and hamacrtn.jar in your CLASSPATH. You can also set the classpath using the Java compiler's -classpath parameter when compiling your application.
To find the HACL classes in the JAR file, the classpath variable (or -classpath parameter) must point directly to the JAR files. For example, if your Java 2 application uses 3270 and SSL functions, and the jar files are located in the c:\jars directory, the classpath should look like this:
CLASSPATH=c:\jars\habasen.jar;c:\jars\hacp.jar;c:\jars\ha3270n.jar;
c:\jars\hassln.jar
When an applet that uses HACL is run in a browser environment, the browser must be able to find the HACL classes. Most browsers will search for Java classes relative to the location specified by the 'codebase' tag in the <applet> tag or, if no codebase is specified, relative to the HTML document itself. See your browser documentation for more information on how to expose classes in the browser environment.
Alternatively, the jar file can be specified directly in the HTML document using the <archive> tag in the <applet> tag. For example:
<APPLET archive="habasen.jar" CODE="MyClass.class" WIDTH=400 HEIGHT=300></APPLET>
When running your program as an application, you need to make sure the CLASSPATH environment variable contains the fully qualified pathname of the HACL jar(s).
[ Top of Page | Previous Page | Next Page | Table of Contents]