Updates
[ Home ] [ Up ] [ Acknowledgements ] [ Corrections ] [ Updates ] [ About the Authors ] [ Colophon ]

 

Updates to Programming with Java IDL

Notes on Solaris Java IDL 1.1 FCS Release

Sun released Java IDL 1.1 FCS after this book's text was finalized. While this release is very similar to the Early Access release used to develop the code examples in the text, there are some things worth noting. The notes in this section should not be considered corrections to errors in the book text, but rather as updates which conform the IDL and Java code to usages that are more naturally aligned with the design of IDL and the IDL to Java mapping themselves.

Pages 194-195: The second paragraph on page 195 describes the use of inout parameters as a workaround for a bug in the EA release. This workaround is no longer necessary with the Solaris Java IDL 1.1 FCS release, and thus this paragraph should be considered deleted for purposes of working with the FCS release and other conforming implementations of the OMG's IDL to Java Mapping.

Therefore, on page 194, the QuoteReceiver parameters for both the FilteredQuoteFeed::addQuoteReceiver and FilteredQuoteFeed::disconnectQuoteReceiver methods should be declared as in parameters rather than inout parameters. This requires some small changes in the Java implementations for these interfaces as well, which are explained in further notes in this section.

Page 208: The twelfth and thirteenth printed lines of code on page 208, which read:

    feed.addQuoteReceiver(packet,
                          new QuoteReceiverHolder(quoteRecvImpl));
should be replaced with:
    feed.addQuoteReceiver(packet, quoteRecvImpl);
Page 209: The first line of page 209, which reads:
                    new QuoteReceiverHolder(qrecv));
should be replaced with:
                    qrecv);
Page 220: The fourth executable line from the bottom of page 220, which reads
    sourceChannel.register(new ReceiverHolder(fd));
should now read
    sourceChannel.register(fd);
Page 227: The signature of the addQuoteReceiver method should be:
    public synchronized addQuoteReceiver(AuthPacket tok, recv)
        throws NPS.BadFilter, Auth.AuthFailure
and the line:
        QuoteReceiver recv = holder.value;
in that method is unnecessary.

Page 228: The signature of the disconnectQuoteReceiver method should be:

    public synchronized void disconnectQuoteReceiver(AuthPacket tok, QuoteReceiver recv)
        throws Auth.AuthFailure
and the line
        QuoteReceiver recv = holder.value;
in the disconnectQuoteReceiver method is no longer necessary.
 

Page 236: The Legacy::Feed interface has two methods, register and unregister that have a Receiver rec parameter declared as inout to accomodate the EA release callback bug. These parameters should be declared as in parameters for the FCS release. Here is the modified IDL for the Feed interface:

  interface Feed {
    boolean register(in Receiver rec);
    boolean unregister(in Receiver rec);
  };

Thus, the FeedImpl.register method signature should be:

      public synchronized boolean register(Receiver rec)
and the first executable statement of the register method is no longer need and should be deleted:
        Receiver rec = holder.value;
Similarly, the new signature for the FeedImpl.unregister method should be:
      public synchronized boolean register(Receiver rec)
and the first executable statement of the unregister method is no longer need and should be deleted:
        Receiver rec = holder.value;
Page 237: The nameserv program from the EA release has been renamed tnameserv in the FCS release.

Notes on Java IDL in the Java 2 (JDK 1.2) Release

There is one just weird thing that needs changing the in Java IDL-specific code in order for NPS to work with the Java IDL packages included with Java 2 (JDK 1.2): some code dealing with properties that, so far as we can tell, shouldn't have caused a problem, needs to be removed. Here are the specifics:

Pages 199 and 206: The first line of the CommManager constructor is changed to:

        public CommManager(){

Page 199 and 206: The line from

        // Save applet reference

through the bottom of page 199 are all commented out or removed. The corresponding lines are removed on page 206.

Page 204: This means, of course, that we have to change the call to the constructor as well, in the last line of the StockTracker.init() method:

        commMgr = new CommManager();

Notes on Java IDL in the Java 2 (JDK 1.3) Release

RMI-IIOP: A New ORB

In JDK 1.3, the Java IDL ORB has been replaced with a new ORB known as the RMI-IIOP ORB. This new ORB, as its name implies, supports the use of RMI clients and servers communicating over IIOP instead of Sun's proprietary JRMP protocol.  The new ORB is largely upward compatible with the Java IDL ORB. Sun documentation refers to JavaIDL and RMI-IIOP as if they were separate, but under the covers, the ORB that supports both features is the same. The new ORB, or some variant of it, is also used in the J2EE Reference Implementation.

The existence of RMI over IIOP was driven by a desire for interoperation between RMI and CORBA, and has the important market effect of allowing CORBA to be used as the primary distribution mechanism within and between Java-based application servers, in particular Enterprise Java Bean containers.

For Java developers who are primarily interested in using CORBA as the basis for object distribution, RMI over IIOP per se is of scant interest. It offers the possibility of interoperability between RMI and CORBA object implementations, however, in practice the IDL and implementation contortions required to accomplish this make the capability of little value except as a checklist feature.

However, in order to support RMI over IIOP, the new ORB provides support for a number of CORBA 2.3 features, the most interesting being the Objects By Value specification ("OBV") and the Java to IDL Mapping specification. OBV in particular extends the semantic range of CORBA by allowing objects and not just primitive types or constructed types (such as structs) to be passed by value. Even more interesting to the Java CORBA developer, the RMI-IIOP ORB supports the generation of portable skeletons and the associated delegation (or tie) model, in addition to the inheritance model supported by Java IDL.

While the new features of the RMI-IIOP ORB are not covered by the Programming with Java IDL book or by this web site, other sources cover RMI-IIOP.

The primary sources are:

Here are two articles describing RMI-IIOP:

Updating Programming in Java IDL for JDK 1.3 and the RMI-IIOP ORB

Application code written for the Java IDL ORB is largely upward compatible with the RMI-IIOP ORB. The NPS example, for example required no Java code changes.

idlj: A new Java to IDL Compiler

The most important difference is that the largely unsupported, platform-dependent, and C-preprocessor-dependent idltojava IDL to Java compiler has been replaced with the idlj IDL to Java compiler. idlj is entirely written in Java and needs no external preprocessor, and is thus platform-independent. idlj is included with the JDK 1.3 release; no separate download or Java Developers' Connection membership is necessary.

idlj supports some different command line options and option syntax. Relevant to the book examples, -fversion has been replaced with -version. The new functionality exits after the version information is printed, and so can not be used when actually compiling code. The idltojava -j option that specifies the directory in which to place generated Java code has been changed to idlj -td.

Changes to Book Text:

Chapter 5 is based on the Java IDL ORB, which has been replaced. While the APIs to the new ORB are largely the same, there are some minor differences and there is much additional functionality available. While readers of Programming with Java IDL should be aware that this situation exists, however, the vast bulk of this chapter is still accurate and relevant.

Pages 93, 95, and 97: The text refers to the idltojava IDL to Java compiler. In RMI-IIOP and JDK 1.3, the idlj IDL to Java compiler is used instead.

Appendix A: This entire Appendix is based on an outdated version of the Java Language Mapping chapter of the CORBA specifications. The RMI-IIOP ORB is based on a version more like the CORBA 2.3 version of the Java Language Mapping.

Notes on Java IDL in the JDK 1.4 Beta Release

The ORB in JDK 1.4 is an updated version of JDK 1.3's RMI-IIOP ORB. There are two differences worth noting that pertain to the material covered in Programming with Java IDL.

First, the ImplBase paradigm for skeletons is deprecated as of CORBA 2.3. Therefore, in order to make idlj generate ImplBase-style skeletons, the -oldImplBase flag must be used.

Second, even though it is still possible to use the tnameserv transient implementation of the CosNaming service, the newer orbd-based persistent implementation seems better and less likely to be deprecated. So, when updating the book code to work with JDK 1.4, orbd is used. Using orbd requires that CORBA clients and servers specify -ORBInitialPort and -ORBInitialHost parameters to obtain the list of initial object references; the default for these values is undocumented, so they are now specified at runtime.