ILU for Java with the SunIdl - Example

This is for jdk1.1
In jdk1.2 CosNaming is a core class and either needs to be renamed, or, ILU needs to be on the boot class path

In jdk1.2 we recommend stubbing CosNaming with a prefix like xorg.omg so that our stubs do not conflict with the non-ilu stubs in the core classes.
You will need to change the import lines in the application to match our re-named stubs.
Don't forget to also change the -Dilu.load=org.omg... properties into -Dilu.load=xorg.omg or whatever prefix you were using.
And of course change the -classpath in the command lines to whatever is appropriate for your Java release.

This example shows Sun's JavaIdl hello-world program with ILU for Java.

The purpose of this example is to demonstrated ILU for Java's source compatibility with other orbs. In this simple example program we will succeeed totally: Our example uses Sun's original source code. This is great, but there is a price to pay: we don't dare redistributing Sun software, the user has to aquire the source code from Sun's JavaIdl directly.

In particular, the following source files are needed

hello.idl
helloClient.java
helloServer.java

Not a single line of source code for this example is provided by the ILU distribution. (Well, change the import of org.omg.CosNaming in JDK1.2) Given my lack of skills in writing "make-files" I can not write "make-files" dealing with non-existing sources; here are the steps necessary to run this example.

java-stubber hello.idl
javac -d classes -classpath ./classes:$ILUHOME/lib/ilu.jar:$JAVAHOME/lib/classes.zip `cat jstubber.files` helloServer.java helloClient.java

you will also need the CosNaming service.

Ok, so how can that example be executed with ILU if not a line of source code is under ILU control? The following properties allow running the program within ILU for Java.

1) the -Dilu.load=... argument tells ILU for Java to load extra classes. We will use this to load the CosNaming service and the application specific stubs.
2) the -DNameService=... argument tells the orb what object to use to bootstrap the orb. (A CosNaming object)
3) the -Dorg.omg.CORBA.ORBClass=xerox.ilu.IluORB property tells the standard orb delegation to use the Ilu orb. This is of course only necessary if the standard orb delegation shells don't use Ilu by default (like the one in the jdk1.2 core).

Specific instructions:
Start the name service first, then remember the ior for the initial object. (This example shows how to start Ilu's NameService. However you could as well use any other NameService because they are compatible on the wire).

../../etc/CosNaming/ILUCosNaming -ior

To start the server side use

java -classpath ./classes:$ILUHOME/lib/ilu.jar:$JAVAHOME/lib/classes.zip -Dorg.omg.CORBA.ORBClass=xerox.ilu.IluORB -Dilu.load=org.omg.CosNaming._allJavaStubs:HelloApp._allJavaStubs -DNameService=IOR:put-the-ior-here helloServer

and to start the client side use

java -classpath ./classes:$ILUHOME/lib/ilu.jar:$JAVAHOME/lib/classes.zip -Dorg.omg.CORBA.ORBClass=xerox.ilu.IluORB -Dilu.load=org.omg.CosNaming._allJavaStubs:HelloApp._allJavaStubs -DNameService=IOR:put-the-ior-here helloClient

Thats all...

What about helloApplet.java ?

It has been tried and did work, using our limited list of supported browsers; recommended are appletviewer or hotjava. There is no special applet dependency. The two problems are that ILU for Java doesn't deal with unloading registered types, and, ILU for Java needs native methods and must be on the browsers class path. About applets

What about the second simplest example program in JavaIDL?

That example uses Sun specific, not CORBA compatible code. We do not attempt to make ILU for Java compatible with Sun private CORBA extensions.

ILU ILU for Java FAQ