Java IDL FAQ
This is a document that attempts to answer many of the questions
you may have about using Java IDL technology.
Errors
Features
Compatibility/Interoperability
General
Errors
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 class path.
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 CORBA Compatibility
Information - J2SE 5.0.
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.
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:
-
COMM_FAILURE/201. vmcid: SUN minor code:
201 literally means "CONNECT_FAILURE". This may be caused by a
java.net.SocketException, usually one of
BindException, ConnectException, or
NoRouteToHostException.
Some things to verify are:
-
Is a naming service running? If not, start the ORBD naming
service as described in the orbd man page (Solaris, Linux, or
Mac OS X or Windows).
-
Are the -ORBInitialHost and
-ORBInitialPort values being set correctly for the
naming service? If you are uncertain about what the settings should
be, read the orbd man page (Solaris, Linux, or
Mac OS X or Windows).
-
Are the client and server applications aware of the port number
(and machine name, if applicable) where the Naming Service is
running? Read the orbd man page (Solaris, Linux, or
Mac OS X or Windows)
for more information on how to do this.
-
COMM_FAILURE/208. vmcid: SUN minor code:
208 literally means "CONNECTION ABORT", which generally means
the connection has been dropped.
-
COMM_FAILURE/209. vmcid: SUN minor code:
209 literally means "CREATE_LISTENER_FAILED": Unable to
create the listener thread on the specific port. Either the post is
taken or there was an error creating the daemon thread. This
generally indicates that the port on which you are trying to run
the naming service is in use by another process. If you are running
on Solaris, you could discover whether or not something is running
on this port using the following terminal prompt command:
netstat | grep port_number
-
OBJECT_NOT_EXIST/204. vmcid: SUN minor
code: 204 literally means "SERVANT_NOT_FOUND". It is only
thrown in one place:
corba.INSSubcontract.getINSReference.
-
MARSHAL/217. vmcid: SUN minor code:
217 means that your client tried to send either a
wchar or wstring in GIOP 1.0, which is
not legal in the spec.
-
MARSHAL/202. vmcid: SUN minor code:
202 means that the code is attempting to marshal an object
that derives from org.omg.CORBA.Object, but that
particular instance has never been connected to an ORB. When using
the POA, you need to register the object with the POA first. If you
need more information on how to register an object with the POA,
refer to Portable Object Adapter (POA) or
the Getting Started with Java™ IDL
tutorial.
-
BAD_PARAM/201. vmcid: SUN minor code:
201 literally means "NULL_PARAM". This exception often occurs
because a Java null was given to a write
method such as write_string,
write_octet_array, etc. You cannot return a Java
null as the result of a Java method.
-
org.omg.CORBA.INTERNAL. vmcid: SUN minor
code: 208 means Unable to determine local hostname using
InetAddress.getLocalHost().getHostName().
The ORB uses
InetAddress.getLocalHost().getHostName() to create a
reference to the name service for looking for and/or binding
references. It also uses
InetAddress.getLocalHost().getHostName() on the server
side to create remote object references (i.e., IORs) that contain
the name/port of the server (rather than a dotted-decimal/port
pair).
To avoid the call to getHostName, you can set the
following properties (refer to the orbd man page [Solaris, Linux, or
Mac OS X or Windows]
if you are not sure how to do this):
-
Set com.sun.CORBA.ORBServerHost to the DNS name or
dotted-decimal address of the server if the ORB is acting as a
server.
-
Set com.sun.CORBA.ORBInitialHost to the DNS name or
dotted-decimal address of the name server.
NOTE: These properties are proprietary and are subject
to deletion or change.
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, 4482166.
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.
If the naming service fails to startup on Linux, include the
following lines in the /etc/hosts file:
<Local Host IP Address> localhost
<Local Host IP Address> <HostName>
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 Java SE 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 Java IDL: The "Hello World" Example
on Two Machines.
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 Official Specifications for CORBA support in J2SE
5.0.
Compatibility/Interoperability
With which CORBA
specifications does J2SE 5.0 comply?
See Official Specifications for CORBA
support in J2SE 5.0.
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",
"<com.other_company.package.ORB>" );
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 Java ID: Interoperable Naming Service
Example) 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: Enterprise
JavaBeans™ Components and CORBA Clients: A Developer's
Guide.
How do I connect to a 3rd-party Naming Service from Sun's
ORB?
The recommended way is to use the Java
IDL: Interoperable Naming Service (INS) Example, if this option
is supported by the 3rd-party Naming Service.
To use the Sun ORB with another vendor's Naming Service,
- Start the 3rd-party name server on Host <H> and Port.
<P>
- 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:
- Verify that the 3rd-party Name Service supports INS.
- Verify that the host and port information is accurate.
- Verify that the 3rd-party Name Service has been started
successfully.
- Verify that the 3rd-party Name Service supports GIOP 1.2. If
not, refer to the Name Server's documentation for the correct the
GIOP version, and modify the corbaloc: URL
accordingly.
- Determine if the 3rd-party Name Service has a different object
key it uses to contact NameService. If so, refer to the
Name Server's documentation.
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: Enterprise
JavaBeans™ Components and CORBA Clients: A Developer's
Guide.
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
Should I use Java
IDL or Java RMI-IIOP technology?
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 technology 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 Java in exactly the same way
as other languages like C++ or COBOL.
Java Remote Method Invocation
over Internet Inter-ORB Protocol ("RMI-IIOP") technology is for
Java programmers who want to program to the Java Remote Method
Invocation ("Java RMI") interfaces, but use IIOP as the underlying
transport. 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™) technology, since the EJB remote
object model is based on Java RMI technology.
Where can I download the idltojava
compiler?
The idltojava compiler is no longer available for download. We
highly recommend that you use the latest version of the IDL-to-Java
compiler, idlj.
To get the latest version of the IDL-to-Java compiler, download
the latest version of the
Java™ Platform, Standard Edition (Java SE). When Java SE
is installed, idlj will be located in the bin
directory.
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:
- Java IDL - If you have been developing CORBA applications using
IDL for some time, you will probably want to stay in this
environment. Create the interfaces using IDL, and define the client
and server applications using the Java programming language to take
advantage of its portability, its highly productive implementation
environment, and its very robust platform.
- RMI-JRMP - If all of your applications are written in the Java
programming language, you will probably want to use Java RMI
technology to enable communication between Java objects on
different virtual machines and different physical machines. Using
Java RMI without its IIOP option leverages its strengths of code
portability, security, and garbage collection.
- Java RMI-IIOP - If you are writing most of your new
applications using the Java programming language, but need to
maintain legacy applications written in other programming languages
as well, you will probably want to use Java RMI with its IIOP
compiler option.
For more information on product limitations, read Limitations.
The most recent versions of standard tag allocation files can be
found at the OMG Web site: http://www.omg.org/.
