IDL to Java Compiler Features

The ORB supports writing object interfaces using both IDL as well as Java RMI. When you write your object interfaces using IDL, you need to generated Java language bindings from it using the IDL to Java compiler (idl2java).

Note: See the reference section for the idl2java man page.

Supported Stub/Skeleton Types

The idl2java compiler is rich in functionality and supports several stub/skeleton types.

Object Adapter DII/DSI based stubs/skels Stream
based stubs/skels Delegation based
skeleton Inheritance based
skeleton Local stubs Smart stubs Portable

simple transient objects Yes Yes Yes Yes Yes Yes Yes

Portable Object Adapter
(POA) Yes Yes Yes Yes Yes Yes Yes

Multicast Object Adapter No Yes Yes Yes Yes Yes No

Support for multiple Object Adapters

The ORB has two object adapters that support IDL - the simple transient object Adapter, and the Portable Object Adapter. The compiler by default generates bindings for the simple transient object Adapter. To generate bindings for POA, use the -poa compiler flag.

Stream based Marshalling and Dynamic Stubs/Skeletons

Two flavors of marshalling are supported - dynamic, and stream based. The dynamic stubs/skeletons use DII/DSI and Anys for method invocation, while the stream based marshalling stubs/skeletons do the marshalling directly to the IIOP streams. The stream based marshalling stubs/skeletons are typically much faster that the dynamic ones and is the compiler default. The dynamic stubs are supported (using the -dynamic compiler flag) in case you want to generate bindings for another ORB that does not support the interfaces required by the stream based stubs/skeletons.

Inheritance and Delegation based Skeletons

The compiler generates both inheritance based skeletons as well as delegation based skeletons, called the TIE skeleton, that can be used to delegate the invocation from the TIE to the object implementations. When using, the TIE based skeletons, the object implementation is not required to extend any class. This is useful because Java only allows single implementation inheritance and it may not be convenient or possible for the object implementation to give up the single inheritance slot. If you do not plan to use delegation based skeletons, then you can avoid generating them by specifying -notie compiler option.

Local Stubs

The stubs by default are generated so that they are enabled for local invocation. If the object is running in the same VM and using the same ORB instance, then marshalling is bypassed and the invocation goes through the Object Adapter (for example POA) machinary and then gets delivered to the servant. The parameters are passed by reference. The local enablement of stubs can be suppressed using -nolocal flag on the compiler.
Smart Stubs

If -smartstubs flag is specified, then a couple of additional methods - setStubClass, and getStubClass, are generated on the Helper classes for all the generated IDL interfaces. These methods can be used to set and get the Java class of the smart stub. When a smart stub is set in the helper, and the object is narrowed to this interface, the Helper creates an instance of the smart stub instead of the default stub. The smart stub is required to extend the default stub.

Miscellaneous Features

Builtin subset of ANSI C pre-processor

idl2java implements a subset of the ANSI C pre-processor functionality. The subset includes processing of #ifdef, #ifndef, #else, #endif, simple #define, #undef, #line, #pragma, and #include. It does not support token pasting and macro expansion.

If macro expansion is necessary, the IDL file(s) can always be pre-processed with an external pre-processor before using idl2java.

Support for compilation of generated Java code

idl2java can directly call the Java compiler to compile the generated code reducing the number of development steps. This is enabled by specifying the -compile compiler flag.

Javadoc style comments

The compiler support Java style formal comments (/** ... */) in the IDL source. When interfaces are generated for IDL constructs, the corresponding formal comments are copied from the IDL file to the generated files.

Generating code for included IDL files

The compiler by default does not generate code for included IDL files. Use the -genincluded compiler flag, you can make it generate code for the included IDL files as well.

Pragma Support

The compiler supports the following #pragmas:
Specify a repository ID prefix.
   #pragma prefix "requested_prefix_name"
Specify the default package prefix for the generated code. This pragma can only be specified at the file scope, and it applies to the entire IDL file. This pragma is deprecated; please see the -pkgprefix command line argument to the idl2java compiler.
   #pragma javaPackage "package"
Specify the complete repository ID.
   #pragma ID <name> "<id>"
Specify the repository ID version.
   #pragma version <name> <major>.<minor>

Acknowledgements

idl2java uses JavaCC, the Java Compiler Compiler from Sun MicroSystems, for generating the IDL parser.

Object Adapter	DII/DSI based stubs/skels	Stream based stubs/skels	Delegation based skeleton	Inheritance based skeleton	Local stubs	Smart stubs	Portable
simple transient objects	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Portable Object Adapter (POA)	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Multicast Object Adapter	No	Yes	Yes	Yes	Yes	Yes	No