Developer kit FAQ

A set of frequently-asked questions.

The frequently asked questions (FAQs) listed here provide brief answers to many common questions about IBM's implementation of the Java Programming Environment. We also recommend the Javasoft FAQs.

Help! How do I get the code? What do I need?

• For Windows platforms, refer to the IBM Development Package for Eclipse.
   
  
• For AIX developer kit 1.3.1 GA, AIX 4.2.1 or later, you'll need 100 MB of free disk space, and at least 64 MB of RAM.
   
  
• For Linux platforms, you'll need an Intel-compatible processor (486 or better; Pentium or better recommended); 9 MB of disk space to download, 30 MB to uncompress; 32 MB RAM; and a display that is suitable for X-Window usage (see those distributions that have been tested).
   
  
• For OS/390: Java for OS/390 runs under the version of OS/390's UNIX Services (also known as OS/390 OpenEdition) which is included in OS/390 Release 1 or above. You also need TCP/IP (with the X-Window System feature if you intend to use the windowing support).
   
  

What does "unable to initialize threads" mean?

It usually means either that your classes.zip file is in the wrong place, or that it is not correctly pointed to by your CLASSPATH setting. (Or both!)

Where are the JDBC drivers?

JDBC drivers for Java applications and applets, for several platforms, are now distributed as a part of our DB2 Product Family. For DB2/400 data you can use the Toolbox for Java.

JavaSoft keeps a helpful list of JDBC drivers for many other platforms/vendors. And here are their useful notes about the JDBC Database access API (and downloadable sets of class files).

Why don't I need to unzip classes.zip?

Java was designed around long file names, and most of the system class files (such as InputStream.class) cannot be named under the earlier FAT 8.3 naming system. So, to be able to run the Java virtual machine on a FAT file system, all the system class files are zipped into a single file (classes.zip) and then loaded directly from that. On an HPFS machine, you can unzip this file, but there's no reason to.

What's causing "Class not found" messages?

First, how did you port the (seemingly missing) class files to your target machine? You need to transfer them in binary mode. When Java goes to find a class, it will look for a file with the name of the class, suffixed with .class. If it finds the file, it will then check the contents. If the file's contents have become corrupted, Java will report a "Class not found" error.

Second, are these (seemingly missing) classes a member of a package? If they are, Java will expect to find them in a directory of the same name as the package, with CLASSPATH pointing to the root of this package hierarchy.

Can I get around the apparent need for 256 colors?

Your system must be capable of displaying at least 256 colors to run applets or windowed Java apps. Console applications (such as the javac compiler) are not affected by this limit. (All JDKs based on Sun's code have this restriction.)

In other words, I'm afraid the answer is mostly "No" -- sorry! You will not be able to run windowed apps, but you'll be able to compile and develop them.

Can you tell me about the status of object serialization?

The serialization functions are all now available.

Why am I experiencing hangs with the Socket/InetAddress classes?

When trying to resolve an InetAddress, like so:

Socket s = new Socket("my.host.com");

or

InetAddress a = InetAddress.getByName("my.host.com");

your program may hang. This is due to a DNS reverse name lookup problem. You will have to ask your local DNS administrators to fix their DNS!

What is a Just-In-Time compiler?

A Just-In-Time compiler (or JIT for short) compiles Java bytecode to native machine code at runtime. So, when you execute your Java classes via a command like this:

    java Foo

instead of the Java interpreter (java) interpreting the bytecodes in Foo.class, the JIT (built into the interpreter) compiles the bytecodes to native instructions so that the operating system can execute these instructions without the performance degradation usually experienced with bytecode interpretation. The result is a boost in performance.

How do I build AIX shared libraries?

As you may have discovered, building shared libraries for Java native methods is not simple under AIX! The Java Native Interface (JNI) simplifies things slightly, but there are still some AIX-specific details you should be aware of, such as use of the xlc_r compiler variant. This example illustrates the process on AIX. For general documentation on JNI, see JavaSoft's JNI pages.

To understand how it works, we'll look at Test.java, the Java code for calling the native method:

public class Test
{
  int my_int_var;

  public Test()
  {
    my_int_var = 777;
  }

  public static void main(String argv[])
  {
    System.out.println("(Java code) JNI example");
    System.loadLibrary("test");
    Test t = new Test();
    double y = t.myNative(42,"Hi Duke!");
    System.out.println("(Java code) return value = "+y);
    System.out.println("(Java code) my_int_var = "+t.my_int_var);
  }

  public native double myNative(int number, String text);
}

#include <stdio.h>

#include "Test.h"


JNIEXPORT jdouble JNICALL Java_Test_myNative
  (JNIEnv *env, jobject obj, jint number, jstring text)
{
  jclass clazz;
  jfieldID fid;

  /* convert Java string to C string */

  const char *buf = (*env)->GetStringUTFChars(env, text, 0);

  printf("(C code) number = %ld\n", number);
  printf("(c code) text = %s\n", buf);

  /* tell Java we've finished with the string */
  (*env)->ReleaseStringUTFChars(env, text, buf);

  /* access my_int_var from the Java class */
  clazz = (*env)->GetObjectClass(env, obj);
  fid = (*env)->GetFieldID(env, clazz, "my_int_var", "I");
  printf("(C code) my_int_var == %d\n", (*env)->GetIntField(env, obj, fid));
  printf("(C code) setting my_int_var to 999\n");
  (*env)->SetIntField(env, obj, fid, 999);

  return 9.7;
}

Java_Test_myNative

JAVA_HOME=/usr/lpp/J1.1

libtest.so: Test.o
	rm -f libtest.so
	ld -o libtest.so Test.o -bnoentry -bM:SRE -bE:Test.exp \
           -blibpath:/lib:/usr/lib -lc_r \
           -L${JAVA_HOME}/lib/aix/native_threads -ljava

Test.class: Test.java
	${JAVA_HOME}/bin/javac Test.java
	${JAVA_HOME}/bin/javah -jni Test

Test.o: Test.c Test.class
	xlc_r -c -I. -I${JAVA_HOME}/include -I${JAVA_HOME}/include/aix \
              -o Test.o Test.c

clean:
	rm -f *.class *.o Test.h libtest.so

To build the example, save the above files into the same directory. You'll need to change the definition of JAVA_HOME in the makefile if your Java installation is somewhere other than /usr/lpp/J1.1. Now, simply type make and the Java file should be compiled, the header file Test.h generated, and then the C native method compiled and linked to create the shared library, libtest.so.

To run the example, first make sure that the right version of Java is in your PATH variable, before any previous versions. Then simply run java Test. Examine the output from this, along with the source code files, to see how everything works.

Why am I getting compilation errors when building AIX shared libraries?

As you may have discovered, building shared libraries for Java native methods is not simple under AIX! You must use the xlc_r compiler variant and the ld linker to create shared libraries suitable for hosting Java native methods. We have used Sun's "Hello World" native method example to show how to do this.

First of all, here is the makefile:

libhello.so: HelloWorld.o HelloWorldImp.o
        ld -bE:HelloWorld.exp -bM:SRE -bnoentry HelloWorld.o HelloWorldImp.o -lc_r -o libhello.so

HelloWorld.h: HelloWorld.class
        javah HelloWorld

HelloWorld.c: HelloWorld.class
        javah -stubs HelloWorld

HelloWorld.o: HelloWorld.c HelloWorld.class
        xlc_r -c -I${JAVA_HOME}/include -I${JAVA_HOME}/include/aix HelloWorld.c

HelloWorldImp.o: HelloWorldImp.c HelloWorld.class
        xlc_r -c -I${JAVA_HOME}/include -I${JAVA_HOME}/include/aix HelloWorldImp.c

HelloWorld.class: HelloWorld.java
        javac HelloWorld.java
        javah HelloWorld
        javah -stubs HelloWorld

Note the use of xlc_r for compilation and the strange set of options for ld!

HelloWorldImp.c looks like this:

#include <StubPreamble.h>
#include "HelloWorld.h"
#include <stdio.h>

void HelloWorld_displayHelloWorld(struct HHelloWorld *this) {
    printf("Hello World!\n");
    return;
}

HelloWorld.java looks like this:

class HelloWorld {
    public native void displayHelloWorld();

    static {
        System.loadLibrary("hello");
    }
}

class Main {
    public static void main(String args[]) {
        HelloWorld Hello = new HelloWorld();
        Hello.displayHelloWorld();
    }
}

HelloWorld.exp looks like this:

HelloWorld_displayHelloWorld
Java_HelloWorld_displayHelloWorld_stub

Where do I look for answers to questions about Java on z/OS and OS/390?

Please start with the "Hints and Tips" page on the Java section of the z/OS and OS/390 Web site.

Do you have an offering for J2ME applications?

Yes. Our WebSphere Micro Environment contains a production-ready Runtime Environment, tested and certified to meet J2ME specifications as laid out by the Java Community Process™. The WebSphere Micro Environment site provides more information and a free trial download.