Java

JavaTM IDL FAQ

This is a document that attempts to answer many of the questions you may have about using JavaTM IDL technology. We will continue to update this document with your questions as we receive them. If you do not find your question answered here, please check the user-supported forum for Java IDL technology, which is available at http://forums.java.sun.com.

Errors

Features

Compatibility/Interoperability

General


Errors

Why do I get this message when I try to run HelloServer: "Exception in thread "main" java.lang.NoClassDefFoundError: HelloServer/java"
The most common reason for this error when running HelloServer (and also HelloClient) from the Java IDL tutorial is that HelloServer is not in the classpath. For more information on setting the classpath variable, see Setting the classpath.

The second most common reason occurs when a space is added between quotation marks in the following line of code: 

NameComponent nc = new NameComponent("Hello", "");

There should be no spaces between the quotation marks. Without spaces, this value is passed as a null. With a space between the quotations, a space character is passed.

My existing programs aren't running using this release. Are there any compatibility issues that could affect this?

Information on compatibility between J2SE 1.4.x and J2SE 5.0 can be found in the compatibility document.

Why can't I connect using IOR's from a Linux server when the IOR contains 127.0.0.0 as the host address?

On Red Hat Linux installations InetAddress.getLocalHost() may return an InetAddress corresponding to the loopback address (127.0.0.1). This arises because the default installation creates an association in /etc/hosts between the hostname of the machine and the loopback address. To ensure that InetAddress.getLocalHost() returns the actual host address, update the /etc/hosts file or the name service configuration file (/etc/nsswitch.conf) to query dns or nis before searching hosts.

What does this minor code mean?

The most recent versions of the standard (OMG) minor code exceptions can be found on the OMG Web site at http://www.omg.org/.

Some of the most common Sun minor code exceptions are the following:

If none of these suggestions work for you, or if you encounter a different Sun minor code exception, try to Java IDL user-supported forum at http://forums.java.sun.com. When submitting a request to the forum, please include the following information:

Can I add multiple classpaths when starting a server using servertool?

The longer version of this question was as follows:

My server code needs multiple JAR files in the classpath. When I register my server using the servertool, and try to specify the classpath, I get the syntax of the register command. I assume my command line is exceeding the limit.

How do I specify a really long classpath while registering the server in the servertool?

The servertool does accept multiple JAR files, however, there is currently a bug with the length of the command line buffer in servertool. Read more about the servertool wrapper bug (bug 4482166) at http://developer.java.sun.com/developer/bugParade/bugs/4482166.html.

The workaround is to call the ServerTool class to start the server, rather than starting the server from within servertool, such as: 

${JAVA_HOME}/bin/java com.sun.corba.se.internal.Activation.ServerTool 
-ORBInitialPort ${ORB_INITIAL_PORT} -cmd register -server 
sample.MyServer -classpath jar1:jar2:jar3 -applicationName sample

Please note that the name of the servertool class may change in future releases.

What do I do when the naming service (tnameserv, orbd) fails to run on the Linux platform?

If the naming service fails to startup on Linux, include the following lines in the /etc/hosts file:

where <Local Host IP Address> is the IP address where the naming service (tnameserv, orbd) is started.


Features

What is the thread model supported by the CORBA implementation in this release?

The Java CORBA ORB shipped in J2SE is multi-threaded. On the server side, we have a thread pool such that each incoming request is handled by a separate thread. If all the pool's threads are in use when a new request comes in, a new thread is created and added to the pool. The thread is returned to the pool after the request is finished.
The Java CORBA ORB is threaded to allow scalability and concurrent request processing. The SINGLE_THREAD option for the POA threading policy is not supported.
The threading model for the Java CORBA ORB is implicit: the user does not set the thread policy for the ORB. There are no external, user-level APIs exposed for controlling the threading model or the number of threads.

Does Java IDL contain notification/event services? an Interface Repository?

No, it does not. If you need one of these services, you can implement one, you can purchase one off the shelf, or you can search for one freely available to start things off with. You can plug-in 3rd party services such as these to the ORB using INS technology.

How can I run the Hello World example on two machines?

You need to use the -ORBInitialHost <Host Name where Name Service is Launched> option when starting the client and/or server (whichever is not running on the same machine as the name server). This way the client and server know where to find the Name Service. An example can be found at http://java.sun.com/j2se/1.5.0/docs/guide/idl/tutorial/jidl2machines.html.

Is Java IDL technology compliant with CORBA specifications?

For compliance information for CORBA technology shipped with J2SE 5.0, read the CORBA compliance statement at http://java.sun.com/j2se/1.5.0/docs/guide/idl/compliance.html.

Compatibility/Interoperability

How can I specify a different ORB?

To use an ORB other than the Java CORBA ORB in your application, you can set the org.omg.CORBA.ORBClass property to the ORB of your choice. For example, use code as shown in the example to explicitly set the ORB to the ORB-implementation you would prefer to use: 

public class MyApp {

    public static void main( String args[] ) {
        Properties properties = System.getProperties();
        properties.put( "org.omg.CORBA.ORBClass",
            "" );
        
        try {
             ORB orb = ORB.init( args, properties);
             
             ...

Check the vendor's documentation for information on setting properties specific to their ORB implementation.

How can I test whether my JDK ORB Client can communicate with another company's ORB implementation?

This ORB has been tested as part of the J2EE certification process, however, it has not been tested with all vendor's standalone CORBA ORBs.

If INS is supported in the other vendor's service, then, try this. Convert the Interoperable Object References (see IOR discussion in INS tutorial) on the other vendor's ORB server to a string using the ORB.object_to_string() method using INS. Write that string to a file.

Do you have any examples that use a CORBA client and an EJB server application?

A developer guide that includes an example application with a C++ client and an Enterprise JavaBeans component can be found on the Web site at: http://java.sun.com/j2se/1.5.0/docs/guide/rmi-iiop/interop.html.

How do I connect to a 3rd-party Naming Service from Sun's ORB?

The recommended way is to use the Interoperable Naming Service (INS), if this option is supported by the 3rd-party Naming Service.

To use the Sun ORB with another vendor's Naming Service,

  1. Start the 3rd-party name server on Host and Port.

  2. Pass the following argument to ORB.init(): 
            -ORBInitRef NameService=corbaloc:iiop:1.2@:/NameService

When you do orb.resolve_initial_references( "NameService" ), you should be able to connect to 3rd-party Name Service. If you are still not able to connect, try these troubleshooting hints:

Can I use the Java IDL ORB with a C++ CORBA server? (interoperability)

The Java IDL ORB is an ORB completely written using Java technology. The idlj compiler generates code that follows the conventions defined in the IDL to Java Language Mapping Specification. The Java ORB does not provide a compiler that generates code in any languages other than the Java platform. If you want to test interoperability between the Java ORB and an ORB written in another language (such as C++), you will need to find an ORB written in that language and a compiler that conforms to the specific language mapping. Language mapping specifications are available from the Object Management Group Web site at http://www.omg.org/. A user who wants to use the Java platform on one side and C++ on the other will only share the IDL. You will have to use your C++ ORB's tools to generate the stubs and skeletons for use with the C++ ORB, but you don't have to change the IDL at all. To find a vendor that provides a CORBA ORB and a language mapping compiler in the language you are working with, search the Web for "C++ CORBA ORB", or equivalent.

A developer guide that includes an example application with a C++ client and an Enterprise JavaBeans component can be found on the Web site at: http://java.sun.com/j2se/1.5.0/docs/guide/rmi-iiop/interop.html.

Although it is true that ORBs written in different languages should be able to talk to each other, we haven't tested the interoperability of the Java ORB with other vendor's ORBs.


General

Where can I download the idltojava compiler?

We highly recommend that you use the latest version of the IDL-to-Java compiler, idlj for all new code. If you still need to use idltojava for legacy applications, you can download the idltojava compiler for JDK 1.2 from http://developer.java.sun.com/developer/earlyAccess/jdk12/idltojava.html.

To get the latest version of the IDL-to-Java compiler, download the latest version of JavaTM 2 Platform, Standard Edition (J2SETM). When J2SE is installed, idlj will be located in the bin directory.

Other troubleshooting information related to idltojava is located in the Java IDL FAQ for J2SE v.1.3.

What are my options for developing CORBA applications using Java technology?

CORBA technology as part of the Java 2 platform consists of an Object Request Broker (ORB) written in the Java language (with a small bit of native code), the RMI programming model, and the IDL programming model.
The "magic" that gives us the cross-language, cross-vendor interoperability is the Internet InterORB Protocol, or IIOP. IIOP can be a transport protocol for distributed applications written in either IDL or Java RMI. IIOP allows distributed objects to conform to OMG's CORBA specification.
When using the IDL programming model, the interface is everything! It defines the points of entry that can be called from a remote process, such as the types of arguments the called procedure will accept, or the value/output parameter of information returned. Using IDL, the programmer can make the entry points and datatypes that pass between communicating processes act like a standard language.
CORBA is a language-neutral system in which the argument values or return values are limited to what can be represented in the involved implementation languages. In CORBA, object orientation is limited only to objects that can be passed by reference (the object code itself cannot be passed from machine-to-machine) or are predefined in the overall framework. Passed and returned types must be those declared in the interface.
With RMI, the IDL and the implementation language are the same thing, so you don't have to worry about mapping from one to the other. Language-level objects (the code itself) can be passed from one process to the next. Values can be returned by their actual type, not the declared type. Or, you can compile the interfaces to generate IIOP-compliant stubs and skeletons to talk to objects written on other machines in other CORBA-compliant languages.

What is the difference between Java IDL and Java RMI-IIOP?

This is a fundamental question and it's important to understand the distinction between these two ways of integrating the Java programming language with CORBA.
Java IDL is for CORBA programmers who want to program in the Java programming language based on interfaces defined in CORBA Interface Definition Language (IDL). This is "business as usual" CORBA programming, supporting the Java language in exactly the same way as other languages like C++ or COBOL.
Java RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) is for developers who want to use the Java programming language to program to the Java RMI interfaces, but use IIOP as the underlying transport. Java RMI-IIOP provides interoperability with other CORBA objects implemented in various languages - but only if all the remote interfaces are originally defined as Java RMI interfaces. It is of particular interest to programmers using Enterprise JavaBeans (EJB), since the remote object model for EJB's is RMI-based.
There are several scenarios that will define how you will want to create distributed CORBA applications. Here are some of them:

What are the limitations when using Java IDL and/or Java RMI-IIOP?

For more information on product limitations, read Limitations.

What are the standard tags for ...?

The most recent versions of standard tag allocation files can be found at the OMG Web site: http://www.omg.org/.


Copyright © 2000-2004 Sun Microsystems, Inc. All Rights Reserved.

 Sun
Java Software