Re: [vfs] final usage

[Mario Ivankovits <im...@apache.org>]

Rami Ojares wrote:

>Why does vfs use everywhere possible final modifier?
>Is this some kind of performance optimization or some
>design issue?
>  
>
Here i find a (IMHO) good summary about the various "final"s
http://renaud.waldura.com/doc/java/final-keyword.shtml

There is a performance aspect when using "final" often - the jvm can 
aggressive optimize (whatever that means), but IMHO this was not the 
(only) indention of the original authors.

As i see the OO design of VFS they used it as one component.

*) final parameters for methods ensures that - within the method - no 
one changes the reference, this is not relevant for the caller, but as a 
developer you can be sure the meaning of the parameter wont change.
(I hope i could express this with my english ;-)
*) final class members ensures also that no methods changes this value - 
again a great helper for the developer who would like to use the value, 
he do not have to understand the class in its very last detail. E.g. 
find a place where this value changes - it isnt changeable.
Also this is a great helper for yourself - as you can ensure no other 
developer (including yourself ;-)) can change this value by mistake and 
make the whole class stopping from work.
*) final classes ensures that no one can derive from them and e.g. pass 
a faked object to the system (security)

I also used final for those aspects before i come to VFS - i found it 
very usefull.

-- 
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [vfs] final usage

[Emmanuel Bourg <eb...@micropole-univers.com>]

Mario Ivankovits wrote:

> But using the "final" keyword of OO design is a good practice.

Certainly when it makes sense, but using it for almost every method 
parameter is certainly not a good practice. I tend to rely on the unit 
tests to ensure a parameter hasn't been modified in a way that generates 
a bug rather than declaring everything final.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [vfs] final usage

[Mario Ivankovits <im...@apache.org>]

Emmanuel Bourg wrote:

> Mario Ivankovits wrote:
>
>> There is a performance aspect when using "final" often - the jvm can 
>> aggressive optimize (whatever that means), but IMHO this was not the 
>> (only) indention of the original authors.
>
> I have yet to see a convincing benchmark proving the performance 
> argument, the last time I checked I wasn't able to notice a difference 
> over 1000000 method calls on virtual and final methods.

Using the "whatever that means" addition i wanted to express that i do 
not relly think there is a performance gain - and i never used it for 
this case - e.g. the parameter passing is only a minimum a program-flow 
does. And maybe the hotspot compiler already inlines some sort of 
methods if called e.g. in an loop.


But using the "final" keyword of OO design is a good practice.

-- 
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [vfs] final usage

[Emmanuel Bourg <eb...@micropole-univers.com>]

Mario Ivankovits wrote:

> There is a performance aspect when using "final" often - the jvm can 
> aggressive optimize (whatever that means), but IMHO this was not the 
> (only) indention of the original authors.

I have yet to see a convincing benchmark proving the performance 
argument, the last time I checked I wasn't able to notice a difference 
over 1000000 method calls on virtual and final methods.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org