Re: java.util.Properties -- make it thread-safe?

[Mark Wielaard]

Hi,

On Fri, 2002-02-15 at 14:50, Artur Biesiadowski wrote:
> Mark Wielaard wrote:
> 
> > Do newer versions of javadoc really no longer mention wether a method is
> > synchronized? That would be not good.
> 
> This seems obvious for me. In other case people would actually look at 
> javadoc modifiers to see if method is synchronized, instead of checking 
> the description (only place where it can be written).

When javadoc puts a synchronized in the javadoc you can be sure that the
thread will need to acquire the lock for that object. It is not strange
to expect the programmer to rely on that fact to document the locking
behaviour of the method. I rely on that when I write documentation, I do
not describe that this method will need to acquire a lock on 'this' when
I made the method synchronized.

> Compare two methods
> 
> public synchronized int hashCode()
> {
>     int hash = 0;
>     for ( int i =0; i < size; i++ )
>       hash ^= array[i];
>     return hash;
> }
> 
> 
> public int hashCode()
> {
>     int hash = 0;
>     synchronized(this)
>     {
>        for ( int i =0; i < size; i++ )
>       hash ^= array[i];
>     }
>     return hash;
> }
>
> Do they differ enough to make difference in javadoc ?

Both should document that a lock is acquired yes.
But in the first case the automatically generated documentation can add
this information. In the second case it cannot. (But maybe it would be
could to issue an warning.)

> This example if of course trivial, but sometimes computations which can 
> be done safely outside synchronization block can be quite expensive. Do 
> you want to take away possibility to optimize it by enforcing people to 
> stick to synchronizing entire method, because it is done such in spec ? 
> Instead of synchronizing only parts which are really needed ?

That is subtle. If they use the same lock the observable behaviour might
be the same. But if the method acquires the lock, drops it for a short
while and then reacquires it then you might get very subtle race
conditions when using that code with multiple threads.

> I was surprised that they EVER documented it in javadoc - but it was 
> probably thinko from early days and only when they wanted to modify 
> something they started to think again.

I do see your point, but I am afraid that with this change in behaviour
we will lose a lot of documented (implicit) locking behaviour since
people normally do not document that the method is synchronized.

Cheers,

Mark