Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Why "lock" functionality is introduced for all the objects? Date: Wed, 29 Jun 2011 19:15:12 +0200 Lines: 29 Message-ID: <9714t7Fu2nU1@mid.individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 3Sm+AZqezwE9SOZedk2axgT+zgkRScxdoI8qsmQ4cakXR3OHw= Cancel-Lock: sha1:SEWzGMfy+XpKKq89Cyjyej9XCXs= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5777 On 28.06.2011 19:33, Stefan Ram wrote: > http://www.trevorpounds.com/blog/?p=351 I have doubts about the viability of the alternatives suggested in that article. I commented I don't think the interface is a proper solution. Reason is that you can pass in a lockless instance of class Foo which implements this interface anywhere where Object is allowed. This means that you must check at runtime whether the instance is lockable or not. That might introduce significant overhead for applications which frequently synchronize. A better way I can think of off the top of my head would be a superclass of Object, but that would break in various other ways (e.g. because suddenly Object.class.getSuperclass() would return a non null value which breaks the existing contract). This leaves us with data-only type. But this would dramatically change the type system, namely you need two different types of references. This might not be a big deal for the compiler but it may make GC much more complex because now there is no longer a uniform object type on the heap. GC is complex enough in modern JVMs so this could be a significant burden. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/