Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

On 14/03/2012 2:49 PM, Eamonn McManus wrote: Why don't we have public T[] toArray(T[] a) ? This would prevent from the cast r[i] = (T)it.next(); It's too late to change the method signature now. Sorry about my english, I meant why don't we have had ... In other words, has there been a reason

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

>>> Why don't we have >>> public T[] toArray(T[] a) ? >>> This would prevent from the cast >>> r[i] = (T)it.next(); >> >> It's too late to change the method signature now. > > Sorry about my english, I meant why don't we have had ... > In other words, has there been a reason that it was not like t

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Thanks for your comments, I have different opinions. About performance, I would like to say "this part of code is not in a path which causes performance problem". In fact it should rarely execute, so there is no need to catch this little optimization, and readability is more important. With the if

Re: CR 7148271 REGESSION with PNG Image loading

INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR + inflateUndermine() is the answer from zlib author. -Sherman On 3/13/2012 5:06 PM, Ulf Zibis wrote: Am 13.03.2012 20:03, schrieb Xueming Shen: While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt

Re: CR 7148271 REGESSION with PNG Image loading

Am 13.03.2012 20:03, schrieb Xueming Shen: While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approach is to by default the j.u.zip.Inflater/PNGImageReader rejec

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 13.03.2012 07:58, schrieb Sean Chou: Hi Ulf and David, I modified the patch and added the testcase, it's now : http://cr.openjdk.java.net/~zhouyx/7121314/webrev.02/ . Ulf's compact version is used, it looks beautiful; T

hg: jdk8/tl/jdk: 7150368: javac should include basic ability to generate native headers

Changeset: 361480e36b44 Author:jjg Date: 2012-03-13 15:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/361480e36b44 7150368: javac should include basic ability to generate native headers Reviewed-by: mcimadamore, darcy, ohrstrom ! make/docs/CORE_PKGS.gmk

hg: jdk8/tl/langtools: 7150368: javac should include basic ability to generate native headers

Changeset: b14d9583ce92 Author:jjg Date: 2012-03-13 15:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b14d9583ce92 7150368: javac should include basic ability to generate native headers Reviewed-by: mcimadamore, darcy, ohrstrom ! src/share/classes/com/sun/tools/java

Re: CR 7148271 REGESSION with PNG Image loading

On 3/13/2012 1:09 PM, Alan Bateman wrote: On 13/03/2012 19:03, Xueming Shen wrote: While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approach is to by de

RE: RFR 7065380 : Allow Collections.sort to sort Collections.singletonList() result

> Well it's not a bug it is a RFE. :) But I agree that the example is a > little flawed in that generate() would not reasonably be able to > generate mutable lists in some cases and immutable lists in others. > I find the restriction on empty/singleton lists unnecessary, but not > sure it is

Re: CR 7148271 REGESSION with PNG Image loading

On 13/03/2012 19:03, Xueming Shen wrote: While this indeed is a "regression", the question is do we really want this behavior (allow those corrupt zip/png files without throwing exception) to be the default behavior? A possible approach is to by default the j.u.zip.Inflater/PNGImageReader rej

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 10.03.2012 13:52, schrieb David Holmes: On 10/03/2012 12:02 PM, Ulf Zibis wrote: Why don't we have public T[] toArray(T[] a) ? This would prevent from the cast r[i] = (T)it.next(); It's too late to change the method signature now. Sorry about my english, I meant why don't we have had ...

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Am 10.03.2012 13:42, schrieb David Holmes: On 9/03/2012 11:39 PM, Ulf Zibis wrote: Regarding your Infrastructure: It is stated, that jtreg is able to process standard JUnit testcases, so IMHO there is no need to recode similar infrastructure. I simply copied am existing test: AbstractCollectio

CR 7148271 REGESSION with PNG Image loading

Hi zlib 1.2.0.[4|5] and later have more "rigorous" distance-too-far boundary checks than previous versions. The PNG image file used in this case appears to be one of those "corrupted" files that have incorrect "distance" value in its compressed image data. This "invalid distance value" is expose

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

This looks good to me. Mike On Mar 12 2012, at 23:58 , Sean Chou wrote: > Hi Ulf and David, > >I modified the patch and added the testcase, it's now : > http://cr.openjdk.java.net/~zhouyx/7121314/webrev.02/. > >Ulf's compact version is used, it looks beautiful; however I replaced >

hg: jdk8/tl/jdk: 2 new changesets

Changeset: e0bf958097e2 Author:chegar Date: 2012-03-13 09:33 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0bf958097e2 7152796: TEST_BUG: java/net/Socks/SocksV4Test.java does not terminate Reviewed-by: alanb ! test/java/net/Socks/SocksServer.java ! test/java/net/Socks/Sock

hg: jdk8/tl/jdk: 7149608: Default TZ detection fails on linux when symbolic links to non default location used.

Changeset: 6bbafa8404eb Author:coffeys Date: 2012-03-13 11:01 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6bbafa8404eb 7149608: Default TZ detection fails on linux when symbolic links to non default location used. Reviewed-by: alanb, okutsu ! src/solaris/native/java/util

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

I'll push changes as are Alan. You've a good point on how we should handle EINTR for such system calls. I think it's something that's relevant to more than just this file and have filed bug 7153347 to follow that. regards, Sean. On 13/03/2012 09:54, Alan Bateman wrote: On 13/03/2012 09:38, S

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

On 13/03/2012 09:38, Seán Coffey wrote: Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ Looks okay to me. For bonus points, open, fstat and read should be restarted if interrupted (EINTR). -Alan.

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Looks good to me. Masayoshi On 3/13/2012 6:38 PM, Seán Coffey wrote: Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ regards, Sean. On 13/03/2012 05:59, Masayoshi Okutsu wrote: fd needs to be closed when fstat or malloc failed? Thanks

Re: RFR : 7149608 (tz): Default TZ detection fails on linux when symbolic links to non default location used.

Update made. Hopefully the last iteration ;) http://cr.openjdk.java.net/~coffeys/webrev.7149608.jdk8.4/ regards, Sean. On 13/03/2012 05:59, Masayoshi Okutsu wrote: fd needs to be closed when fstat or malloc failed? Thanks, Masayoshi On 3/13/2012 12:22 AM, Alan Bateman wrote: On 12/03/2012 1

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Still looks okay to me. David On 13/03/2012 4:58 PM, Sean Chou wrote: Hi Ulf and David, I modified the patch and added the testcase, it's now : http://cr.openjdk.java.net/~zhouyx/7121314/webrev.02/. Ulf's compact version is used, it looks beautiful; however I replaced the Math.m

Re: Request for review : 7121314 : Behavior mismatch between AbstractCollection.toArray(T[] ) and its spec

Hi Ulf and David, I modified the patch and added the testcase, it's now : http://cr.openjdk.java.net/~zhouyx/7121314/webrev.02/. Ulf's compact version is used, it looks beautiful; however I replaced the Math.min part with if statement because if statement is more intuitive and I don't