synchronized/wait/notify on AnyRef

just curious: why you think that was a mistake in java?

Am 11.02.2009 um 14:42 schrieb Nils Kilden-Pedersen:

> One of the many mistakes of Java, IMO, was to make every object a
> monitor, i.e. the ability to be used in a synchronized block and
> with wait/notify methods. Scala seems to have repeated this, by
> providing synchronized/wait/notify methods on AnyRef.
>
> Why wasn't this put in a trait instead?
>
> Nils

I would say Java compatibility and to a certain degree consistency.  All Scala objects on the JVM ultimately derive from java.lang.Object, which for better or for worse has the capabilities.  I'm sure the compiler could to tricks to hide them, but it seems like it would be far more trouble than it's worth.

On Wed, Feb 11, 2009 at 8:42 AM, Nils Kilden-Pedersen <nilskp@gmail.com> wrote:

One of the many mistakes of Java, IMO, was to make every object a monitor, i.e. the ability to be used in a synchronized block and with wait/notify methods. Scala seems to have repeated this, by providing synchronized/wait/notify methods on AnyRef.

Why wasn't this put in a trait instead?

Nils

--
http://erikengbrecht.blogspot.com/

On Wed, Feb 11, 2009 at 7:50 AM, Sciss <contact@sciss.de> wrote:

just curious: why you think that was a mistake in java?

Because not every object has this need.

On 2/11/09, Nils Kilden-Pedersen wrote:
> One of the many mistakes of Java, IMO, was to make every object a monitor,
> i.e. the ability to be used in a synchronized block and with wait/notify
> methods. Scala seems to have repeated this, by providing
> synchronized/wait/notify methods on AnyRef.
>
> Why wasn't this put in a trait instead?

Well, because scala.AnyRef == java.lang.Object, so those methods are
supported by all AnyRefs rather than provided by a trait.

In decreasing order of importance

1) It lets developers who don't understand concurrency convince themselves
that they do.
2) It is incredibly easy to get locks on the wrong object, resulting in
subtle and intermittent bugs
3) It inherently breaks encapsulation.
4) It prevents any Java object from being truly functional.
5) It increases the size of just about every object by requiring a pointer
to a monitor pool (and yes, there are environments where that sort of thing
really matters).

While it probably won't be (for Java compatibility reasons), I would love to
see synchronized/wait/notify moved to a trait.

Sciss-3 wrote:
>
> just curious: why you think that was a mistake in java?
>
> Am 11.02.2009 um 14:42 schrieb Nils Kilden-Pedersen:
>
>> One of the many mistakes of Java, IMO, was to make every object a
>> monitor, i.e. the ability to be used in a synchronized block and
>> with wait/notify methods. Scala seems to have repeated this, by
>> providing synchronized/wait/notify methods on AnyRef.
>>
>> Why wasn't this put in a trait instead?
>>
>> Nils
>
>
>

Because you should carefully control what objects you lock on, otherwise you're likely to cause deadlock.  A Lock type instead of Object having this would be good.

It's best not to do pessimistic locking, but if you do, do it on objects you don't give out references to.

As for Scala repeating it, not doing so would be difficult wouldn't it, as Object is the root of the class hierarchy on the JVM.  You're free to implement lock(lock: Lock)(whileLocked: => Unit) and ignore the Java drainbammage.

2009/2/11 Sciss <contact@sciss.de>

just curious: why you think that was a mistake in java?

Am 11.02.2009 um 14:42 schrieb Nils Kilden-Pedersen:

One of the many mistakes of Java, IMO, was to make every object a monitor, i.e. the ability to be used in a synchronized block and with wait/notify methods. Scala seems to have repeated this, by providing synchronized/wait/notify methods on AnyRef.

Why wasn't this put in a trait instead?

Nils