Re: Possible Bugs - extended & one more bug

Dion Picco <[email protected]> Mon, 26 Sep 2005 12:19:17 -0230
Newsgroups gmane.comp.corba.orbacus
Organization IONA | Making Software Work Together TM
Message-ID <[email protected]>
Hi Erez,

On Sun, Sep 25, 2005 at 10:57:39PM +0300, Erez Hadad wrote:
> Hi,
> 
> (Using JOB-4.1.3/JDK1.4.2/Linux)
> I believe you have bugs in com.ooc.CORBA.InputStream: according to the 
> CORBA/Java specification, the org.omg.CORBA.portable.InputStream (which you 
> implement through com.ooc.CORBA.InputStream) should extend 
> java.io.InputStream and conform to its specification. However, I have noticed 
> the following two exceptions:
> 1. available() is not overridden, so it returns 0 even though there is data to 
> be read from the stream.
> A possible fix:
> public int available()
> throws IOException {
>   int avail = buf_.len_ - buf_.pos_;
>   return (avail >= 0 ? avail : 0);
> }
> 2. read() returns the byte value of the stream's internal buffer 
> (buf_.data_[pos++]), which is a byte value [-128, +127] rather than convert 
> it to an int value in the range of [0, 255] as the Java specification 
> requires. -1 should be returned only for an end-of-stream. Consequently, 
> trying to read the stream as a Java byte-stream would fail prematurely.
> A possible fix:
> replace
> return buf_.data_[buf_.pos_++];
> with
> return (0xff & buf_.data_[buf_.pos_++]);
> 3. The class com.ooc.CORBA.OutputStream contains a matching bug: the write() 
> method does not conform to the java.io.OutputStream.write() specification. It 
> is implemented as write_long() where it should only write a single byte - the 
> least significant byte.
> A possible fix:
> replace
> write_long(b);
> with
> write_octet((byte)b);
> 
> Please verify the bugs & fixes.
> 
> Regards,
> Erez Hadad

Yes, you are right on all three counts.  These issues conflict with the
interface defined in the java.io package.  The reason they don't
manifest themselves as bugs within Orbacus is that we simply don't use
them for marshaling/unmarshaling our messages.  I will rectify this for
the next release of Orbacus (4.3.1).  

I am curious as to why you have a need for these methods as well (simply
as a way to understand the needs and uses of our customers).
Normally our users are shielded from these classes as the jidl compiler
will generate the code that will handle the usage of the Input/Output
streams.  The only common case of a user dealing with such issues might
arise during the custom marshaling of a valuetype but this would occur
through the DataInputStream/DataOutputStream classes as well.

Thanks for the bug reports and insights.
Cheers.

-- 
Dion Picco, Software Engineer
IONA Technologies Inc.
Team Orbacus - Your CORBA Source
mailto:[email protected]
http://www.orbacus.com
_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html