Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (athena.apache.org: 195.212.17.162 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
Message-Id: <201005200919.o4K9J8iZ025141@d12av01.megacenter.de.ibm.com>
In-reply-to: <4BF4F9A4.6050201@gmail.com>
References: <201005142248.o4EMmGXL008475@d06av02.portsmouth.uk.ibm.com>
 <4BF3B231.301@googlemail.com>
 <AANLkTik5EecoDjlEGaNfIcH_y8dikK9lsSyEUK49YEGx@mail.gmail.com>
 <4BF4EC09.3090407@gmail.com>
 <201005200846.o4K8kYKw030351@d06av04.portsmouth.uk.ibm.com>
 <4BF4F9A4.6050201@gmail.com>
Comments: In-reply-to Regis <xu.regis@gmail.com>
   message dated "Thu, 20 May 2010 16:58:12 +0800."
From: Mark Hindess <mark.hindess@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [general] Code Freeze for Milestone 5.0M14 and 6.0M2
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 May 2010 10:19:08 +0100


In message <4BF4F9A4.6050201@gmail.com>, Regis writes:
>
> On 2010-05-20 16:46, Mark Hindess wrote:
> >
> > In message<4BF4EC09.3090407@gmail.com>, Regis writes:
> >>
> >> On 2010-05-19 20:45, Catherine Hope wrote:
> >>> I also see these 2 tests failing in the same way.  It seems to be
> >>> caused by Regis' commit 944119 "SocketChannelImpl.SocketAdapter's
> >>> remote address should be updated after channel connected" on
> >>> 14/05/2010.  It could be that the tests are invalid though -
> >>> the first one is checking that the SocketAddress returned by
> >>> getRemoteAddress() is a different object to the one that was passed
> >>> to connect(), though as SocketAddress is immutable would this cause
> >>> a problem?
> >>>
> >>
> >> The test case expect behaviors to be exactly same with RI, but I don't
> >> think it's a big deal, I intend to delete this assert.
> >>
> >> for - testSocket_NonBlock_BasicStatusAfterConnect, isConnected()
> >> should check first, following patch can fix it. And again, the test
> >> failed at same line as BasicStatusAfterConnect.
> >>
> >> Following patch can fix these failures, I'd like to commit it if
> >> second committer agree this.
> >
> > -1
> >
> > I am +1 for the patch to SocketChannelImpl.java because this fixes
> > behaviour.
> >
> > However, I am -1 for the patch to SocketChannelTest.java because we
> > don't fix broken tests during code freeze.
> 
> All right, how about this (create new InetSocketAddress instance everytime):

-1

Fix the behaviour for testSocket_NonBlock_BasicStatusAfterConnect.

Do not make any changes for the other failure - i.e. leave it failing -
and remove it after the code freeze.

-Mark.