ILU for Java, Frequently Asked or Hard Questions
Does ILU for Java run on system X
ILU for Java has been used with
- jdk1.1.x in [0..7] reference implementation on Solaris 2.5 using green or native threads where available.
- jdk1.1.x in [6..7] production release on Solaris 2.5.
- jdk1.1.x in [0..7] on NT4.
- jdk1.1.4, jdk1.1.6 on SGI
- a few odd version of 1.2beta and early release systems; no more supported
- jdk1.2 on Solaris 2.5 and NT4
- Microsoft SDK 2.0 and SDK 3.1 on NT4
- Symantec Visual Cafe for Java 1.5 on NT4
- Inprise JBuilder 2 on NT4
- Linux Redhat5.1; jdk1.1.7 on RH Linux 5.2
- jdk1.0.2 is no more supported by ILU
ILU for Java runs on a large number of Java VM's. However due to the native methods ILU itself can't boast Java's "write once debug anywhere". On the good side however: ILU clients see the same ILU api from different systems and are therefore "write once run (almost) anywhere" by themselves.
Does ILU for Java support applets
The short answer is no. However this is not quite correct and there is a much longer answer.
ILU for Java had been successfully run from within Hotjava, Netscape-4 and Java Plugin. However there are 3 basic problems:
1) ILU uses native methods. Therefore it can't be downloaded through the net but must be local or signed or an extension etc.
2) ILU does not support unloading of types. Therefore even stubs are "permanent" and have to be mutually trusted. Malicious stubs cause no kernel security risk, but cause a denial of service risk, and, a security risk to other applications of the same ILU types
3) It has only been tested quite superficially.
In practice this means that you might be able to use ILU in an applet but you need to put ILU together with all needed stubs into an extension (and make sure that the stubs do not conflict with stubs from another applet)
How CORBA compatible is ILU for Java
CORBA compatibility on the wire
yes. Totally as long as you stay in the (rather large) common subset.
CORBA source code compatibility
To a large extent. There is a large intersection between CORBA and ILU. If so desired an application can be written to stay in the common subset. example
Internal compatibility
ILU is not completely binary CORBA compatible: While this release (2.0alpha14) supports ILU and a standard ORB in the same address space, ILU and the standard ORB must not share stubs.
Feature compatibility
ILU does NOT have DII, DSI.
How RMI compatible is ILU for Java
Most ILU for Java stubs are serializable and could be transmitted through RMI.
ILU for Java has a package which supports passing arbitrary serializable Java
objects through ILU.
(ILU has a RMI compatible wire protocol. This feature is however more usefull to talk to RMI from other programing languages)
Does ILU for Java support ILU's multiple languages in one address space?
Theoretically yes. In reality NO.
To use multiple languages in the same address space the languages need a compatible thread model. In case you get a language with a thread model compatible to Java you have unsurmountable security issues. You don't want to deal with that.
Why does ILU for Java use native methods?
It wants to take advantage of the shared ILU kernel. It automatically handles each new protocol or transport. Its applications are completeley compatible with ILU applications in other languages. We wouldn't start a new ORB this way, but we have no regrets.
Why isn't ILU for Java using JNI?
Thats history. Both ILU and JNI have been improved and ILU2.0alpha14 works fine with JNI 1.2. However the JNI interface is somewhat indirect and using other native interfaces might be more efficient when available.
Will ILU for Java run on Hotspot?
Who knows? The ILU group has no access to prior information. We believe we have done everything necessary. Supporting Hotspot was the main reason to bother about JNI.
How efficient is ILU for Java?
We haven't even measured it yet. We always leave the debugging options enabled but believe that in Java the overhead for debugging is considerable.
We do not believe ILU for Java to be specially speedy in itself, however the question for speed is not a simple question of raw execution speed. If speed is influenced by real network considerations, it might very much depend on which internal protocols are used. E.g. W3NG is faster then SUNRPC. SUNRPC is faster then IIOP.
When you compare speeds, little differences might make big changes: Certain orbs for example use stubs in applications but DII in applets.
Where can I download ILU for Java?
Look at the generic ILU page.
(Internal to Xerox PARC only: look here)
Where are examples for ILU for Java?
Look in the ILU examples directory.
For ILU for Java the examples worth looking at most are the tutorial example, the hello-world example, and, the testjavaobv example. (The pickle example also has some java code)
Try the ILU for Java with SunIdl - Example
Whats the date for the next release?
We have a long tradition of never making a prediction for release dates. We are ready when we are ready.
I'm upgrading to ilu2.0alpha14 and there are lots of compile time errors
It first looks daunting, but this is quite easy to fix as there are usually only two causes for errors.
- System exceptions can no more be subclassed because the CORBA system exceptions are declared "final". This can be fixed with a global replace. The package prefix for system exceptions needs to be changed but the exception names are the same.
- The compiler complains about my files having to be declared abstract because they don't implement about 6 different CORBA methods. This can be fixed in a number of different ways, the easiest way is to extend the base class xerox.ilu.IluObjectBase which contains an implementation for those methods.
These problems could not be avoided because ilu2.0alpha14 uses the standard CORBA packages.
My program fails, how do I debug it?
See the manual and the class xerox.ilu.IluDebug for flags to trace particular features.
The easiest way to set a trace is to set the ILU_DEBUG environment variable to MOST.
My program throws an org.omg.CORBA.INV_OBJREF exception
ILU cannot find the object you are trying to access. This can happen for all possible legitimate reasons. However experience shows that the following two reasons are more likely then network failures:
- The true object has been garbage collected. There are lots of fancy ways to prevent garbage collection, the choice may be almost overwhelming. You need to choose only one.
- Your exporting an object with SUNRPC. Your trying to accesss it with IIOP. You can fix this with environment variables, by setting the default on ILU build-time, or explicitely in your program.
ILU ILU for Java
