Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of nbeyer@gmail.com designates
 209.85.216.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=rbe5gvrxYs9/mdVIPlB/267LNMixX5qZwIQIxX/7njv1Ti3JDBGViOFZfnmuXBC3t0
         7YlvPK5aeuXEhu84rNd8QhNT5VqvSiyLJ8vGaG5NnWzbgAUL/Ln/um8CRo3AcuWtua3P
         Iz4s/mkS11LgWX4Az0Wf7HglfW4Mku09yadDc=
MIME-Version: 1.0
In-Reply-To: <4AD59715.2000500@gmail.com>
References: <20091011031344.389E823888DA@eris.apache.org>
	 <4AD31751.3000704@gmail.com>
	 <3b3f27c60910121918l2cdcec80kefea53c3350795f@mail.gmail.com>
	 <a43fbc6a0910131159k47fed4cv6956096066f33e0@mail.gmail.com>
	 <4AD59715.2000500@gmail.com>
Date: Wed, 14 Oct 2009 21:34:17 -0500
Message-ID: <3b3f27c60910141934i26ea5a07u9a9279d54cfaf571@mail.gmail.com>
Subject: Re: svn commit: r824006 - in
 /harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/net:
	DatagramPacket.java DatagramSocket.java
From: Nathan Beyer <nbeyer@gmail.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 14, 2009 at 4:17 AM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> On 13/Oct/2009 19:59, Jesse Wilson wrote:
>> On Mon, Oct 12, 2009 at 7:18 PM, Nathan Beyer <nbeyer@gmail.com> wrote:
>>
>>> Honestly, the synchronization probably isn't appropriate on any of the
>>> accessor/mutators - the granularity isn't correct. The locking
>>> probably needs to encompass the entire method on DatagramSocket while
>>> working on a particular DatagramPacket. Realistically, you don't want
>>> the packet to change while processing.
>>>
>>
>> A test shows that the RI uses synchronized. The following program doesn'=
t
>> complete:
>>
>> =C2=A0 public static void main(String[] args) throws Exception {
>> =C2=A0 =C2=A0 byte[] data =3D new byte[] { 1, 2, 3, 4, 5 };
>> =C2=A0 =C2=A0 final DatagramPacket datagramPacket =3D new DatagramPacket=
(data,
>> data.length);
>>
>> =C2=A0 =C2=A0 ExecutorService executorService =3D Executors.newFixedThre=
adPool(1);
>>
>> =C2=A0 =C2=A0 synchronized (datagramPacket) {
>> =C2=A0 =C2=A0 =C2=A0 Future<byte[]> future =3D executorService.submit(ne=
w Callable<byte[]>()
>> {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 public byte[] call() throws Exception {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return datagramPacket.getData();
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>> =C2=A0 =C2=A0 =C2=A0 });
>>
>> =C2=A0 =C2=A0 =C2=A0 byte[] fromAnotherThread =3D future.get();
>> =C2=A0 =C2=A0 =C2=A0 System.out.println(Arrays.toString(fromAnotherThrea=
d));
>> =C2=A0 =C2=A0 }
>> =C2=A0 }
>>
>>
>> Unfortunately, the concurrency support is shallow and not useful. Despit=
e
>> the fact that the RI has synchronized statements, it fails to defensivel=
y
>> copy the data array:
>>
>> =C2=A0 public static void main(String[] args) throws Exception {
>> =C2=A0 =C2=A0 byte[] data =3D new byte[] { 1, 2, 3, 4, 5 };
>> =C2=A0 =C2=A0 final DatagramPacket datagramPacket =3D new DatagramPacket=
(data,
>> data.length);
>> =C2=A0 =C2=A0 System.out.println("arrays are defensively copied? " + (da=
ta !=3D
>> datagramPacket.getData()));
>> =C2=A0 }
>>
>>
>> As a consequence, one thread could mutate the data array while another
>> thread is consuming it.
>>
>> Regardless, it looks like synchronized and no defensive copying is the k=
ey
>> to compatibility with the RI.
>
> Thanks Jesse,
>
> I can't imagine that any application would rely on the methods being
> synchronized (as opposed to the fields being consistent), but I agree
> that we should leave it alone for compatibility sake.
>
> Unfortunately there are quite a few places where the RI implementation
> leaves a bit to be desired -- which always makes it tempting to build a
> better Java :-)

In some circles, synchronized is just an implementation detail and not
a definition of the interface. I think that may be on the SCJP test.
We could consider that unless the synchronization characteristics are
defined by the documentation, then don't have to abide by the same
implementation details.

-Nathan

>
> Regards,
> Tim
>