lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Psaltis" <apsal...@ideapivot.com>
Subject RE: API Inconsistency
Date Mon, 04 May 2009 09:57:56 GMT
My question was about the public vs protected, not the synchronized. In the
end it is my error for not checking the 2.3.1 java source, which does match
the .net 2.3.1 source.

-----Original Message-----
From: Eran Sevi [mailto:eransevi@gmail.com] 
Sent: Monday, May 04, 2009 3:07 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: API Inconsistency

The locking is done in .NET inside the method by using the " lock(this) "
operation surrounding all the method implementation.
This is exactly equivalent to "synchronized" at the method level in java.
As long as all the methods that have synchronized in Java are implemented
using lock(this) in .NET then it's the same.

Eran.


On Sun, May 3, 2009 at 2:57 PM, Andrew Psaltis
<apsaltis@ideapivot.com>wrote:

> While looking at the latest MEAP edition of Lucene in Action and trying to
> port Listing 10.2 from the Java to .NET, I noticed an inconsistency in the
> DecRef and IncRef API of the IndexReader. The java version have the
> following signature:
>
>
>
> public synchronized void incRef()
>
> public synchronized void decRef()
>
>
>
> However, the .NET version (latest source fron SVN as of Thursday
> -4/30/2009)
> has the following signatures:
>
>
>
> protected internal virtual void  IncRef()
>
> protected internal virtual void  DecRef()
>
>
>
>
>
> Is this an acceptable deviation?
>
>
>
> Thanks,
>
> Andrew
>
>
>
>
>
>


Mime
View raw message