Toba does not support dynamic loading; all needed classes must be
linked into the executable file.
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 and
return any class referenced directly or indirectly by the class
containing the initial entry point.
The Java awt and applet libraries have not been implemented.
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.