Issue 1732: Changes to Java interface mapping (java-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This issue is based off of discussion with engineers at Sun. The recent portability submission introduced changes to the mapping for Java interfaces. This change was to generate both a signature interface and an operations interface. The signature interface is defined to extend the operations interface. While the need for both interfaces is clear, it is not clear if the relationship between the two interfaces is necessary. The change requires additional classes to be downloaded for the remote stub case and could potentially impact performance. Resolution: closed issue Revised Text: Actions taken: July 24, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Fri, 24 Jul 1998 01:25:32 -0700 From: George Scott To: java-rtf@omg.org CC: issues@omg.org Subject: Changes to Java interface mapping This issue is based off of discussion with engineers at Sun. The recent portability submission introduced changes to the mapping for Java interfaces. This change was to generate both a signature interface and an operations interface. The signature interface is defined to extend the operations interface. While the need for both interfaces is clear, it is not clear if the relationship between the two interfaces is necessary. The change requires additional classes to be downloaded for the remote stub case and could potentially impact performance. Further evaluation needs to be performed to determine if the mapping can be made more compatible with the original mapping. In other words, remove the relationship between the operations interface and the signature interface. George Return-Path: Sender: "George Scott" Date: Mon, 27 Jul 1998 21:04:14 -0700 From: "George M. Scott" Organization: Inprise Corporation To: java-rtf@omg.org CC: jeffm@inprise.com, akv@eng.sun.com, dheisser@eng.sun.com Subject: Re: Changes to Java interface mapping References: <35B844FC.E8EC9333@inprise.com> George Scott wrote: > > This issue is based off of discussion with engineers at Sun. > > The recent portability submission introduced changes to the > mapping for Java interfaces. This change was to generate both > a signature interface and an operations interface. The signature > interface is defined to extend the operations interface. While > the need for both interfaces is clear, it is not clear if the > relationship between the two interfaces is necessary. The change > requires additional classes to be downloaded for the remote stub > case and could potentially impact performance. > > Further evaluation needs to be performed to determine if the > mapping can be made more compatible with the original mapping. > In other words, remove the relationship between the operations > interface and the signature interface. We have completed our evaluation of this issue and have determined that we should keep the recently adopted mapping which has the signature interface extending the operations interface. We propose this issue be closed with no change (sorry Jeff I couldn't find the issue number). Here are some of the benefits of the new mapping: 1. Reduced amount of duplicate code generation. In the original Java mapping skeletons extended the generated interface, so there was no duplicate code generated for the abstract methods declarations. In the POA, servants cannot be CORBA objects, so the servant cannot extend the generated interface. This means one has to redefine the same set of abstract methods for the POA skeleton. Also, as part of the POA spec we specified a tie mechanism which requires an interface for delegation. Rather than have three sets of the same abstract methods for the same IDL interface we generate only one which is used by the stub, POA skeleton, and POA tie classes. 2. Provides a common inteface to view servants and stubs. The mapping allows programmers to view servants and stubs through one common interface. We feel that end users and ORB vendors can take advantage of this feature. For example, it is now possible for a user to use the new POA tie mechanism and "tie" a servant to a stub of the same interface type. 3. Binary/source compatible with old mapping. The new mapping is binary and source compatible with the previous mapping, so there should be no migration issues (we wouldn't have made the change otherwise ;-)). The one valid argument I have heard against the recent change is that applets will now have to download an additional class. From some analysis we performed we estimate the additional class only adds 200-300 bytes overhead depending on the inheritance hierarchy and length of class names. Considering that most applets usually only handle <5 interfaces We are taking about a 1k overhead. By placing all of the class files in a compressed JAR file this overhead should shrink drastically to just a few hundred bytes. Also, if we were to go back to the old mapping style, where the signature interface does not extend the operations interface the server footprint would increase. This is because there would be two interfaces containing the same abstract method declarations. These classes are essentially the same size and can be quite large for complex interfaces like the IR. Again as before compression can be used to help with disk utilization, but there are still memory utilization issues. Essentially the overhead for the current mapping is an O(1) overhead for each IDL interface. The overhead for the old mapping is O(n) for each IDL interface where n is the number of methods. So we will take the constant space over linear space mapping. The other issue is whether to optimize for applets or for normal clients/servers. It is our position that the server side should take precedence. This is where we see Java and many of our customers heading. In particular, use of servlets and other server-side web programming models seems to be winning out over applets in a number of cases due to applet security issues and variations in browser VM implementations. George