Issue 1142:  POA_Interface bug (java-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: Chapter 5.2.4
 class POA_<interface_name> is supposed to implement 
 <interface_name>Operations.
 
 However neither specification nor the example contain any  
 operations method.  The class also are not specified abstract.
 
 

Resolution: closed issue
Revised Text: 
Actions taken:
April 16, 1998: received issue
May 18, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <Christian_P_Jacobi.PARC@xerox.com>
X-NS-Transport-ID: 080037014071933138A6
Date: Wed, 15 Apr 1998 17:07:51 PDT
Sender: Christian_P_Jacobi.PARC@xerox.com
From: jacobi.PARC@Xerox.com
Subject: Portability IDL/Java, POA_Interface
To: java-rtf@omg.org
cc: jacobi.PARC@Xerox.com, ilu-core.PARC@Xerox.com
Reply-to: Christian_P_Jacobi.PARC@xerox.com

(about orbos/98-03-10)

BUGS

Chapter 5.2.4
class POA_<interface_name> is supposed to implement 
<interface_name>Operations.

However neither specification nor the example contain any  
operations method.  The class also are not specified abstract.



Return-Path: <gscott@visigenic.com>
Sender: "George M. Scott" <gscott@visigenic.com>
Date: Wed, 15 Apr 1998 17:34:46 -0700
From: "George M. Scott" <gscott@visigenic.com>
Organization: Borland International, Inc.
To: Christian_P_Jacobi.PARC@xerox.com
CC: java-rtf@omg.org, jacobi.PARC@Xerox.com, ilu-core.PARC@Xerox.com
Subject: Re: Portability IDL/Java, POA_Interface
References: <98Apr15.170831pdt."51955(2)"@alpha.xerox.com>

jacobi.PARC@Xerox.com wrote:

> (about orbos/98-03-10)
>
> BUGS
>
> Chapter 5.2.4
> class POA_<interface_name> is supposed to implement
> <interface_name>Operations.
>
> However neither specification nor the example contain any
> operations method.  The class also are not specified abstract.

Yes, these are both bugs.  The classes should be marked abstract.And
an ellipsis "..." should be included before the
closing curly
brace of each class definition.  The DSI-based code for these
method implementation is too complex to show here, IMHO.

> Chapter 9.8.1
> Says "Local stubs are defined to be direct base classes of remote
> stubs"
> Does it matter?  It is the opposite way as proposed in the drawing
> in
> chapter 6.4

That sentence should read

"Local stubs are defined to be direct sub-classes of remote stubs".
It
matters for portability.  I'm not sure if they need to be "direct" sub
classes,
but they need to at least be a sub-class.  ORBs need to be able to
rely
on this behavior.

> MORE FAR-FETCHED IDEA
>
> What if the Operations interface would not contain the inheritance
> relationship?  Wouldn't that be a step in the direction of being
able
> to implement independent interfaces with one class.  (To be
> functional this would need matching changes in the tie class)

I'm not sure I follow what you are saying, could you provide an
example.

Thanks.

George