dev@fi.java.net

Re: Encoding algorithms

From: Santiago Pericas-Geertsen <Santiago.Pericasgeertsen_at_Sun.COM>
Date: Thu, 10 Feb 2005 09:30:35 -0500

On Feb 10, 2005, at 9:16 AM, Paul Sandoz wrote:

> Santiago Pericas-Geertsen wrote:
>> On Feb 9, 2005, at 11:47 AM, Paul Sandoz wrote:
>>> Alan Hudson wrote:
>>>
>>>>> I think i already need to make one modification to the
>>>>> encodeToBytes method. It is not possible to obtain how many bytes
>>>>> have been written.
>>>>
>>>> Does this method follow standard java rules of not reallocating of
>>>> the array is big enough?
>>>
>>>
>>> Yes.
>> If it does not reallocate the array, why can't it return the number
>> of bytes written as an int?
>>
>
> Reallocation would occur if the input array is not large enough.

  Alan's question above has a "not" in it. I guess I was confused.

>>>> Instead of a wrapper class, how about a getNumberBytesWritten to
>>>> get the last number of bytes?
>>>>
>>>
>>> But then it would not necessarily be thread safe.
>> If by thread safe you mean sharing the same instance across threads,
>> this is an implementation issue, I'm not sure how this relates to the
>> interface. I.e., even without this method you can still have an
>> implementation that is not thread safe. In fact, I think requiring
>> thread safety in EncodingAlgorithmImpl's is probably not a good idea,
>> it is usually better to do synchronization externally.
>
> Agreed.
>
>
>> I believe you're concern is ensuring that, if thread safety is
>> required, then the encoding and the getter methods can be
>> synchronized in such a way that they return consistent results, which
>> I believe is doable using the concurrency API (instead of the more
>> limited block synchronization mechanism).
>
> My concern is that such a method imposes a concurrency requirement on
> all implementations of the interface.

  Only if you require implementations to be thread safe. Since you don't
like this either, you can just state that as part of the definition of
the API. I think it is OK to do that.

> For such a 'getter' method i think it would be better to avoid that if
> possible.

  I agree, I'm not sure I like it, I just didn't quite understand the
reason why this was rejected.

-- Santiago