Toba does not support true dynamic loading; all needed classes must be
precompiled into the executable or a Toba package.
The class java.lang.ClassLoader is not implemented,
and java.lang.Class.getClassLoader() always returns null.
However, the method java.lang.Class.forName() can find
any class referenced directly or indirectly from the main
class, and under Solaris, Irix and Linux, it can find any
class precompiled into the executable or a Toba package.
Toba gives different values for some system properties than the Sun
implementation.
For example, the
os.name and os.version properties give the values
returned by the uname system call.
Toba does not validate class files; it assumes that all class files are properly formatted, contain legal instructions, and obey the specification in all other respects. Malformed class files may produce unpredictable results.
Toba does not claim to guard against deliberate deception, so it does not check accesses between different classes. It assumes that the checking performed by javac is sufficient.
Toba does not implement a security manager.
The native code interface is incompatible with that of the Sun implementation. (It is actually simpler, and it allows native functions to be overloaded.)
The result of stack overflow, such as from infinite recursion, is typically a segmentation fault instead of a Java exception. Errors in any native code can also cause segmentation faults or other symptoms. All other errors result in catchable exceptions.
No debugging facilities are implemented. The breakpoint instruction is ignored, and stack traces are not available.
The Linux implementation
The Irix implementation
NaN, Inf and -0 differently
than the JDK in the Float.toString and
Double.toString methods.
The Windows NT implementation
java.lang.Class.forName().
-0 differently than the JDK in the
Float.toString and Double.toString methods.
Runtime.freeMemory and Runtime.totalMemory
methods.