Hi Mike, David,
I reported this as a bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7121314 .
On Wed, Dec 14, 2011 at 1:03 PM, Mike Duigou wrote:
> I agree that most people probably won't check whether the array returned
> is the array they provided. It is possible that they incor
Sean, Ulf,
I retract all my previous comments - they were completely wrong.
AbstractCollection.toArray _does_ address concurrent modification:
"This implementation returns an array containing all the elements
returned by this collection's iterator in the same order, stored in
consecutive ele
I agree that most people probably won't check whether the array returned is the
array they provided. It is possible that they incorrectly assume it is. ie.
Collection collection;
...
Integer[] foo = new Integer[collection.size()]; // of sufficient size for all
elements
// at this point collectio
Yeah, that is the reason I think a declaimer about "not designed for
concurrent
operation. " in the spec would be a proper choice.
On Tue, Dec 13, 2011 at 10:20 PM, Ulf Zibis wrote:
> IMO in 99.8 % this check would be superfluous overhead.
> For those, who want 100 %, they can check and copy i
Thanks Fred.
I don't think maintaining the style of existing code needs to extend to
all aspects of that code but is more about general layout, spacing and
naming. So adding unnecessary casts to malloc, or declaring all
variables at the start of the method are not things that need to be
repea
On 14:45 Tue 13 Dec , Neil Richards wrote:
> On Tue, 2011-12-13 at 14:42 +, Neil Richards wrote:
> > On Tue, 2011-12-13 at 10:36 +0800, Sean Chou wrote:
> > > On Mon, Dec 12, 2011 at 7:33 PM, Neil Richards
> > > wrote:
> > > On Tue, 2011-12-06 at 11:14 +0800, Sean Chou wrote:
> > >
Changeset: c647ebb3c4f7
Author:naoto
Date: 2011-12-13 15:41 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c647ebb3c4f7
4808233: "Locale" not thread-safe
Reviewed-by: okutsu
! src/share/classes/java/util/Locale.java
Changeset: 4e4fed1d02f9
Author:jjg
Date: 2011-12-13 14:33 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4e4fed1d02f9
7121164: renamed files not committed
Reviewed-by: ksrini
- src/share/classes/com/sun/tools/javac/main/JavacOption.java
+ src/share/classes/com/sun/tool
Changeset: 3809292620c9
Author:jjg
Date: 2011-12-13 11:21 -0800
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3809292620c9
7120736: refactor javac option handling
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/javac/api/JavacTool.java
! src/share/classes/com/sun
On 12/10/11 7:46 AM, Sebastian Sickelmann wrote:
> Am 09.12.2011 17:07, schrieb Sean Mullan:
>> On 12/6/11 3:48 PM, Sebastian Sickelmann wrote:
>>> Am 05.12.2011 19:06, schrieb Sean Mullan:
On 12/2/11 11:02 AM, Sean Mullan wrote:
>> [0] Solution 1
>> http://dl.dropbox.com/u/436926
Charles,
thanks for the notification. I was scratching my head trying to
figure out why I was seeing the old code and not the new. Being new to
Mercurial and after some digging, I realized I was using 'up' the way I
used it in Subversion (pull from the repo and update the local copy),
th
On Tue, 2011-12-13 at 14:42 +, Neil Richards wrote:
> On Tue, 2011-12-13 at 10:36 +0800, Sean Chou wrote:
> > On Mon, Dec 12, 2011 at 7:33 PM, Neil Richards
> > wrote:
> > On Tue, 2011-12-06 at 11:14 +0800, Sean Chou wrote:
> > > Hi,
> > >
> > >
> > >
On Tue, 2011-12-13 at 10:36 +0800, Sean Chou wrote:
> On Mon, Dec 12, 2011 at 7:33 PM, Neil Richards
> wrote:
> On Tue, 2011-12-06 at 11:14 +0800, Sean Chou wrote:
> > Hi,
> >
> >
> >I'm not sure what to do for it next, shall I create a bug
> for
Hi David,
Thanks for the review.
Changes have been applied to this new webrev:
http://cr.openjdk.java.net/~fparain/7104647/webrev.jdk.05/
My answers are in-lined below.
Fred
On 12/13/11 07:49 AM, David Holmes wrote:
Hi Fred,
A couple of minor comments on the JDK side:
HotSpotDiagnosticMXBe
IMO in 99.8 % this check would be superfluous overhead.
For those, who want 100 %, they can check and copy in their code.
-Ulf
Am 13.12.2011 14:30, schrieb Sean Chou:
Sorry for the confuse. By "ok", I mean "compare the size of array which is
going to be
returned and the size of the specified ar
Hi Serguei,
Thanks for the review.
I've applied the changes and the new webrev is here:
http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.05/
Regards,
Fred
On 12/13/11 10:43 AM, serguei.spit...@oracle.com wrote:
Hi Frederik,
Your fix is already in a good shape!
src/share/vm/service
Hi Dan,
Thank you for the review.
The new webrev is here:
http://cr.openjdk.java.net/~fparain/7104647/webrev.hotspot.05/
And my answers are in-lined below.
On 12/12/11 09:08 PM, Daniel D. Daugherty wrote:
src/share/vm/services/attachListener.cpp
The new include should be in alpha-order (betwe
Sorry for the confuse. By "ok", I mean "compare the size of array which is
going to be
returned and the size of the specified array, and copy the elements
into the specified
array if it is larger and return the specified array."
Nothing is causing problem for now, I just found a mismatch. I think
Am 13.12.2011 12:18, schrieb Sean Chou:
Hi ,
Is it possible to change the spec ? I found it is defined in
java.utils.Collection
interface. It would be easy for AbstractCollection to state that it is not
designed
for concurrent operations, and its subclass should take care of them.
+1 -U
On 13/12/2011 9:18 PM, Sean Chou wrote:
Hi ,
Is it possible to change the spec ? I found it is defined in
java.utils.Collection interface. It would be easy for
AbstractCollection to state that it is not designed for concurrent
operations, and its subclass should take care of them.
Such a discl
On 13/12/2011 8:16 PM, Ulf Zibis wrote:
Am 13.12.2011 08:41, schrieb David Holmes:
Hi Sean,
On 13/12/2011 5:21 PM, Sean Chou wrote:
When I was reading the code of AbstractCollection.toArray(T[] ), I
found its behavior maybe different from the spec in multithread
environment. The spec says "If
Hi ,
Is it possible to change the spec ? I found it is defined in
java.utils.Collection
interface. It would be easy for AbstractCollection to state that it is not
designed
for concurrent operations, and its subclass should take care of them.
However, I think the simplest way may be modify
Am 13.12.2011 08:41, schrieb David Holmes:
Hi Sean,
On 13/12/2011 5:21 PM, Sean Chou wrote:
When I was reading the code of AbstractCollection.toArray(T[] ), I
found its behavior maybe different from the spec in multithread
environment. The spec says "If the collection fits in the specified
arra
23 matches
Mail list logo
