Alan Hudson wrote:
> Paul Sandoz wrote:
>
>> Alan Hudson wrote:
>>
>>> I notice that all the methods on AttributesHolder.java are final. Is
>>> there a reason to restrict usage in this way? I don't need to
>>> override them currently but I'm not sure why they are all final.
>>>
>>
>> Final methods are just more efficient. This class is currently meant
>> for internal use. I have been thinking that we might need to move to
>> the public API area so that algorithm data can be added. Then the
>> methods do not necessarily need to be final.
>>
> Have you verified this recently.
I did some tests a while back and final made a measured difference, not
a large one but nothing to be sniffed at :-)
> It used to be the case definately.
> But I think recent JVM's inline methods when its smart to do it.
I think i used 1.4.2, but 5.0 might be different.
> At
> least Sun's hotspot seems todo. I just hate seeing so many final
> methods which later may bite us.
>
I understand. That is why i have attempted to separate the
implementation from the APIs. In that respect we have control over the
implementation and can change what we like as it is a private contract.
The encoder and parsers are to a degree quite focused in what they do
and any methods that overide may mess up the encoding/decoding process.
But then again my experience on larger Java projects is limited...
For normal practice i would not recommend using final in this way!
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109