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.
I am proposing that the functionality should be designed to mirror the
List.toArray method:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/List.html#toArray(java.lang.Object[])
"a - the array into which the elements of this list are to be stored, if
it is big enough; otherwise, a new array of the same runtime type is
allocated for this purpose."
except of course without the casting required.
However, a problem arises when the return byte array is the same
instance as the input byte array since it is also necessary to know
howmany bytes have been written.
>>> 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. For such a 'getter' method i think
it would be better to avoid that if possible.
For example there is no need to retain state for the built-in algorithms
as they are all rather simple.
It would be a lot easier if Java had the ability to return more than one
value :-)
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109