On 08/12/2011 15:21, Mike Duigou wrote:
Was the SnychronousQueue test recently added or did something else change to
cause the failure?
This failure has not happened yet, but is will when I push the warning
changes for j.u.c ( with some minor impl changes ).
SynchronousQueue.iterator()
Thanks David and Doug,
So we should be ready to integrate this change, right? NO, not yet!
There is a failing regression test, java.util.Collections.EmptyIterator.
This test does a reference comparison ( '==' ) on the iterator returned
from an empty SynchronousQueue and the iterator returned
Chris,
On 7/12/2011 10:09 PM, Chris Hegarty wrote:
Thanks David and Doug,
So we should be ready to integrate this change, right? NO, not yet!
There is a failing regression test, java.util.Collections.EmptyIterator.
This test does a reference comparison ( '==' ) on the iterator returned
from
On 06/12/11 08:01, Rémi Forax wrote:
On 12/06/2011 08:07 AM, David Holmes wrote:
On 6/12/2011 12:14 PM, David Holmes wrote:
On 6/12/2011 11:45 AM, Rémi Forax wrote:
On 12/06/2011 02:12 AM, David Holmes wrote:
Is the reason for constructs like this:
HashEntryK,V[] tab = (HashEntryK,V[])new
On 12/ 6/11 01:12 AM, David Holmes wrote:
Chris, Doug,
A few nits see below.
Cheers,
David
-
As a matter of style can we ensure annotations are on separate lines. I
find this:
@SuppressWarnings(unchecked) E x = (E) items[takeIndex];
hard to read. (I hate seeing local variable
On 12/06/2011 01:28 PM, Chris Hegarty wrote:
On 12/ 6/11 01:12 AM, David Holmes wrote:
Chris, Doug,
A few nits see below.
Cheers,
David
-
As a matter of style can we ensure annotations are on separate lines. I
find this:
@SuppressWarnings(unchecked) E x = (E) items[takeIndex];
hard to
Cleanup warnings in the j.u.c. package.
This is a sync up with the warning fixes in Doug's CVS. There are also a
few style cleanups, import fixes, trivial local variable renaming,
typos, etc. But nothing too surprising!
http://cr.openjdk.java.net/~chegar/7118066/webrev.00/webrev/
-Chris.
On 05/12/11 15:36, Chris Hegarty wrote:
Cleanup warnings in the j.u.c. package.
This is a sync up with the warning fixes in Doug's CVS. There are also
a few style cleanups, import fixes, trivial local variable renaming,
typos, etc. But nothing too surprising!
On 12/05/11 12:54, Maurizio Cimadamore wrote:
http://cr.openjdk.java.net/~chegar/7118066/webrev.00/webrev/
-Chris.
P.S. I have already reviewed this, and the contribution is of course from Doug.
Nice work! Some comments below:
Thanks for looking at this!
In both cases, reducing warnings
Chris, Doug,
A few nits see below.
Cheers,
David
-
As a matter of style can we ensure annotations are on separate lines. I
find this:
@SuppressWarnings(unchecked) E x = (E) items[takeIndex];
hard to read. (I hate seeing local variable annotations in the first
place - way too much
On 12/06/2011 02:12 AM, David Holmes wrote:
Chris, Doug,
A few nits see below.
Cheers,
David
-
As a matter of style can we ensure annotations are on separate lines.
I find this:
@SuppressWarnings(unchecked) E x = (E) items[takeIndex];
hard to read. (I hate seeing local variable
On 6/12/2011 11:45 AM, Rémi Forax wrote:
On 12/06/2011 02:12 AM, David Holmes wrote:
Is the reason for constructs like this:
HashEntryK,V[] tab = (HashEntryK,V[])new HashEntry?,?[cap];
that we can't utilize diamond? Otherwise it would nicely reduce to:
HashEntryK,V[] tab = new
On 6/12/2011 12:14 PM, David Holmes wrote:
On 6/12/2011 11:45 AM, Rémi Forax wrote:
On 12/06/2011 02:12 AM, David Holmes wrote:
Is the reason for constructs like this:
HashEntryK,V[] tab = (HashEntryK,V[])new HashEntry?,?[cap];
that we can't utilize diamond? Otherwise it would nicely reduce
13 matches
Mail list logo
