General Information FAQ

Contents

1.0 Getting started, current software releases available & future development

1. (a) What software releases for the Java™ Platform are currently available?
   (b) On what platforms is the JDK and SDK and related development software available?
2. What are your product offerings on the Java™ platform?
3. Is there any way I can determine if my Java application will run on the 64-bit Alpha platform?
4. What are your plans for supporting Java 3D API?
5. Would you explain the version-naming convention used for your SDK kits?
6. What are your plans for supporting the Java™ 2 Enterprise Edition (J2EE)?
7. What are your plans for supporting Java Web Start?

2.0 Downloading, installing, and accessing JDK and SDK & documentation

1. (a) How do I download the Java software?
   (b) How do I install the software?
   (c) Are there mirror sites for European and Asian users?
2. What documentation is available? In what formats? How can I get it? And where can I find a list of 'known problems'?

3.0 Database access, networking & browsers

1. How do I get Remote Method Invocation (RMI) to work across the network?
2. I'm having trouble getting my applet to run in the Netscape Navigator®. Should I report this problem to HP?

4.0 Third party applications, Java tools & other utilities

1. Will Sun's HotJava™ Browser run on the Tru64 UNIX and VMS implementation of the SDK, and if so how do I install it?

5.0 Getting information, staying in touch & finding software support

1. How can I stay informed of the latest software releases?
2. How can I get information on your software products?
3. Where do I find software support for the SDK releases?

1.0 Getting started, current releases available & future development

Q1.1a: What software releases for the Java™ Platform are currently available?

Please note: For 5.0, Sun Microsystems' has reverted to the terminology JDK and JRE. The Java software from HP prior to version 5.0 is called SDK and RTE.

A: HP offers software with the very latest Java™ technology. Our Software Development Kit (SDK) and Run Time Environment (RTE) releases are available for Tru64™ UNIX®, and OpenVMS Alpha. For a complete list of available releases for these platforms, please see our software download page.

Note: HP's End of Life (EOL) processes and schedules for Java releases is based on Sun's EOL processes and schedules. We strongly encourage developers to migrate to the latest software releases. To understand if a release has begun EOL, refer to the index page for that release version.

Q1.1b: On what platforms is the JDK and SDK and related development software available?

Tru64™ UNIX® The SDK release for Tru64 UNIX is available to download from this Web site, beginning with version 4.0F. The SDK kit from HP is not available on our UNIX prior to version 4.0F. For details, please see our software download page. Technical documentation for a given release contains details regarding operating system version and other requirements. To view the documentation for our SDK and other software, see our software documentation page. To view questions and answers about our software for Tru64 UNIX, see the Tru64 UNIX faq.

OpenVMS Alpha: The SDK kits for OpenVMS Alpha V7.2-2 (and higher) are available to download from this Web site. The JDK 5.0 kits are available for OpenVMS Alpha Version 7.3-2 and higher. For details, please see our software download page. Technical documentation for a given release contains details regarding operating system version and other requirements. To view the documentation for our JDK, SDK, and other software, see our software documentation page. To view questions and answers about our software for OpenVMS Alpha, see the OpenVMS Alpha faq.

OpenVMS I64: The JDK and SDK kits for OpenVMS I64 Version 8.2-1 (and higher) are available to download from this Web site. For details, please see our software download page. Technical documentation for a given release contains details regarding operating system version and other requirements. To view the documentation for our JDK software, see our software documentation page.

OpenVMS VAX: You can not run our Java applications on OpenVMS VAX. You can run SDK applications on any operating system platform that implements the Virtual Machine. The Virtual Machine is included in both the SDK for OpenVMS Alpha and in the Netscape Navigator® for OpenVMS Alpha. However, the Virtual Machine won't be available on OpenVMS VAX. Why? The Virtual Machine requires an implementation of the IEEE math standard within the operating system. This IEEE standard is not part of the OpenVMS VAX architecture. In our attempts to emulate this IEEE standard on OpenVMS VAX, we encountered architectural restrictions that hindered our ability to deliver a conformant Virtual Machine implementation required by Sun. Further attempts to work around these architectural restrictions on OpenVMS VAX resulted in Java applications running with unacceptable performance.

Q1.3: Is there any way I can determine if my Java application will run on the 64-bit Alpha platform?

A: Yes. You can access an AlphaServer remotely through HP's new technology test drive an Alpha program. This program enables you to test your Java applications on Tru64 UNIX and OpenVMS Alpha on systems configured with the necessary SDK. Visit the HP test drive Web site for details.

Q1.4: What are your plans for supporting Java 3D API?

A: We currently have no plans to license or implement the Java 3D API. However, we will continue to re-evaluate our engineering plans in the event that customer requirements indicate a change to our business strategy. Stay tuned to this Web site for future announcements.

Q1.5: Would you explain the version-naming convention used for your SDK kits? In this example, when typing the UNIX command, java -version, SDK v 1.4.2-2 displays as follows:

java version "1.4.2-2"

A: The number following the hyphen indicates an Update release - in this case number "2". It does NOT indicate that this is a beta release. Beta releases are indicated by including the word "beta" as part of the version name; for example, "1.4.2-beta". This version naming convention (hyphen#) is necessary because we have had to re-release kits to fix Sun's or other problems. This numbering scheme makes it much easier to determine exactly which kit you are using.

Also note that an Update release contains the full SDK release based on Sun's Java 2 SDK along with the latest features and bug fixes.

Q1.6: What are your plans for supporting the Java™ 2 Enterprise Edition (J2EE)?

A: The Java™ 2 Enterprise Edition (J2EE) is a set of components and APIs that are related to Enterprise applications. This capability is licensed separately from the Java™ 2 Standard Edition (J2SE). HP licenses the J2SE for its Alpha platforms, the terms under which we provide our SDK and RTE kits. HP does not license the J2EE for the Alpha platform, and does not have any plans to license it. The J2EE capability is provided by middleware vendors, such as our HP partners BEA, Oracle, Iona, etc. For more information on these vendors, please see the 'deployment' section on our 'Java technology on Alpha' homepage.

Q1.7: What are your plans for supporting Java™ Web Start?

A: Java™ Web Start is a new application deployment technology that allows you to launch Java applications with a single click from your web browser. Java Web Start is included as part of the SDK v 1.4.

2.0 Downloading, installing, and accessing JDK and SDK & documentation

Q2.1a: How do I download the Java software?

A: You can access our releases from our software download page. Choose the version of the Java software kit you want, and proceed from there.

Q2.1b: How do I install the software?

A: For installation instructions, refer to the technical documentation that is provided with the kit and on this Web site.

Q2.1c: Are there mirror sites for European and Asian Users?

A: No. Our customers can reach the HP home page at http://thenew.hp.com/country/us/eng/welcome.html or http://www.hp.com/.

However, FTP sites are available in the U.S. and Europe for our customers to easily download our software for the Java Platform. Since we are experiencing good connectivity in Asia Pacific, there are currently no plans to add an FTP site there.

Note: if you can not access our FTP sites, there is an HTTP option on the U.S. server; replace fttp://ftp with http://ftp.

Q2.2: What documentation is available? In what formats? How can I get it? And where can I find a list of 'known problems'?

A: Software documentation is packaged as part of each SDK kit, and is available in HTML format. The software documentation can be viewed by pointing your browser to the directory/file on the system where the SDK kit is installed as the following examples show:

for Tru64 UNIX:

/usr/opt/java131/docs/index.html

for OpenVMS Alpha:
SYS$COMMON:[SYSHLP.JAVA]INDEX.HTML	(SDK v 1.1.n)
SYS$COMMON:[JAVA$122.DOCS]INDEX.HTML	(SDK v 1.2.2)
SYS$COMMON:[JAVA$130.DOCS]INDEX.HTML	(SDK v 1.3.0)

Documentation is also on-line and available from our software documentation page. For a list of 'known problems', refer to the release notes.

3.0 Database access, networking & browsers

Q3.1: How do I get Remote Method Invocation (RMI) to work across the network?

A: RMI will work across the network if the following is true:

The server machine needs to have available: the interface class, the server class, and the skeleton class. The client machine needs to have available the interface class, the client class, and the server or the stub class. If the stub or server class is not present on the client machine, the server machine must have a web server or some kind of simple HTTP server running to send the stub class to the client. Sun's RMI tutorial for our SDK version 1.3.n contains a URL for a simple class server. Go to the on-line software documentation page. Refer to the documentation 'index' page to find a pointer to the Sun 'Tutorial'.

On the server machine, first start the RMI registry. It is critical that your classpath contain only the SDK classes at this point. Do not put "." in the classpath. And do not run the registry from a directory containing any classes that will need to be transported to clients. If the class is in the RMI registry process’s classpath, the registry will not encode the URL, and remote clients won’t know from where to download the object’s class.

The RMI server class files must be placed in a directory where the RMI server and the web server can find them. Specify this area when invoking the RMI server program by setting the codebase property as shown below. The trailing '/' on the URL specification is required.

java -Djava.rmi.server.codebase=http://host/dir/ classname

The following example is UNIX-specific but can be generalized if you are using another Alpha platform. The associated java source code is located after the example, below.

Perform steps 1 through 5 while logged into the system on which the RMI server will run, and step 6 while logged into the system on which the client will run. Start with the following files in some work directory:

myInterface.java myClient.java myServer.java

(interface java source) (client java source) (server java source)

 

 

1. In the work directory, java compile (javac) the java code.

cd  ~smith/work1
javac myInterface.java
javac myClient.java
javac myServer.java

Expected output:

myInterface.class
myClient.class
myServer.class

2. In the work directory, RMI compile (rmic) the server class to produce the skeleton and stub classes.

rmic myServer

Expected output:

myServer_Skel.class
myServer_Stub.class

3. Change to the work directory that does not contain any files related to RMI. Make sure that the classpath does not contain the reference to the area where the RMI classes are stored. You may set it to the location of the classes needed by the SDK and other Java applications. Start the RMI registry. In this example, '&' is used to run it in the background. Also, a port (4444) is specified to override the default port 1099. The client and server code must have knowledge of the port if the default is not used (see the Naming.lookup call in myClient.java and the Naming.rebind call in myServer.java).

cd  ~smith/work2
setenv CLASSPATH <system-classes.zip>
rmiregistry 4444 &

4. Start the RMI server. It does not matter what your working directory is at this point. In this example, it is assumed that there is an HTTP server running and that a user whose home directory is ~smith contains a subdirectory called public_html on node mysrv.zko.dec.com. It is also assumed that the server, interface, and skeleton classes are in this subdirectory (This example shows all class files being copied. However, myClient.class does not need to be included).

cp  ~smith/work1/*.class   ~smith/public_html
setenv  CLASSPATH  ~/public_html
java  -Djava.rmi.server.codebase=http://mysrv.zko.dec.com/~smith/  myServer &

5. Copy myInterface.class and myClient.class to the remote client system (the directory is not important). The stub class does not have to be copied to the client system in this example because the server system has a web server that will be able to send the stub class to the client. In this example, we assume that myInterface.class and myClient.class were copied to the ~jones/work1 directory of the system where the client program will be invoked.

6. Invoke the client program while logged into the client system. The client and interface classes must be on your classpath. In this example, the only parameter the client class takes is the node name of the server system:

setenv  CLASSPATH   ~jones/work1:$CLASSPATH
java  myClient  mysrv.zko.dec.com

-------------------
Java Source Code

myInterface.java

public interface myInterface extends java.rmi.Remote {
   String runCmd( String inputCmd ) throws java.rmi.RemoteException;
}

myClient.java (Note: Naming.lookup returns the remote object for the URL)

import java.io.*;
import java.net.*;
import java.rmi.*;
import java.rmi.registry.*;

/**
* This program connects to a server at a specified host and port.
* It reads text from the console and sends it to the server.
* It reads text from the server and sends it to the console.
**/

public class myClient {
 static private myInterface server;

 public static void main(String[] args) throws RemoteException,
                                                 IOException {
  try {

   // Check the number of arguments.
  // The RMI server host name is required.
      if (args.length != 1)
       throw new IllegalArgumentException("Wrong number of arguments");

   // Parse the host specifications
   String host = args[0];
   // Connect to remote host
   if (System.getSecurityManager() == null) {
       System.setSecurityManager(new RMISecurityManager());
   }
   server = null;
   try {
       System.out.println( "Attempting to connect to server." );
       server =
       (myInterface) Naming.lookup("rmi://"+host+":4444/CLIserver");
       System.out.println( "Server obj created. " );
       System.out.println
          ("Client writes this sentence on Client screen.");
       System.out.println
          ("(Client calls Server) " + server.runCmd("UNIX"));
   }
   catch (Exception e) {
       System.out.println( e );
   }
  }
  catch (Exception e) {
       System.out.println( e );
  }
 }
}

myServer.java (Note: Naming.rebind rebinds the name to a new object, replacing any existing
                                  binding)

import java.rmi.*;
import java.io.*;
import java.rmi.server.*;
import java.rmi.server.UnicastRemoteObject;

public class myServer extends UnicastRemoteObject implements myInterface {

   public myServer() throws java.rmi.RemoteException {
      super();
   }

   public String runCmd( String inputCmd ) {
      // We'll actually execute the command here at this point.

      System.out.println( "(Server writes) Client sent string: " +
                            inputCmd + " :to Server screen." );
      return "Server writes this sentence on Client screen.";
   }

   public static void main( String args[] ) {

       if (System.getSecurityManager() == null) {
         System.out.println( "Starting a new security manager." );
         System.setSecurityManager(new RMISecurityManager());
       }
       else {
         System.out.println( "A security Manager already exists." );
       }

       try {
         myServer obj = new myServer();
         Naming.rebind( "//mysrv:4444/CLIserver", obj );
         System.out.println( "Server codebase is: " +
                    System.getProperty( "java.rmi.server.codebase" ) );
         System.out.println( "Server policy file is: " +
                    System.getProperty( "java.security.policy" ) );
         System.out.println( "CLIserver is now bound in registry." );
       }
       catch (Exception e) {
         System.out.println( "CLIserver error: " + e.getMessage() );
         e.printStackTrace();
      }
   }
}

Q3.2: I'm having trouble getting my applet to run in the Netscape Navigator. Should I report this problem to HP?

A: No. The support in the Netscape Navigator is implemented by Netscape in a JVM built into the browser. Therefore, problems with applet execution in the Netscape Navigator should be reported to Netscape.

However, we suggest that you try our Plug-in. Our Plug-in allows you to run Java applets and JavaBeans™ components using HP's latest Run Time Environment (RTE), as an alternative to using Netscape's Virtual Machine. Visit our software download page to download a copy of the Plug-in, now included as part of the SDK v 1.3.1 and higher releases.

4.0 Third party applications, Java tools & other utilities

Q4.1: Will Sun's HotJava™ Browser run on the Tru64 UNIX and VMS implementation of the SDK, and if so how do I install it?

A: Yes. Sun's HotJava Browser is 100% Java and will run on the Tru64 UNIX and VMS implementation of our SDK v 1.1. HotJava does not support SDK v 1.2.2 or later. To install:

• Follow the download instructions for either Solaris Installation or Windows Installation. These pointers can be found on the Sun page
  http://java.sun.com/products/hotjava/3.0/.

For UNIX:

• When the download is complete, you will have a file named "hjb3_0-solsparc-jre.bin". Installation instructions are provided at the bottom of the same page.

This version has not yet been tested on VMS.

5.0 Getting information, staying in touch & finding software support

Q5.1: How can I stay informed of the latest software releases?

A: If you would like to stay informed, the best way is to visit our Web site:

'Java technology Software - OpenVMS and Tru64™ UNIX®'
(http://h18012.www1.hp.com/java/alpha/index.html)

Q5.2: How can I get information about your software products?

A: If you have a question about the JDK and SDK and other software, you can send us email at java-info@hp.com. And if you experience any problems with our web site, you can notify our webmaster by sending feedback or via email at java-webmaster@hp.com. We will respond to you as quickly as we can.

Q5.3: Where do I find software support for the SDK releases?

A: If you do not find what you are looking for in our faqs and need to contact us, please follow the instructions on our software support page.