hg: jdk8/tl/jdk: 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException

Changeset: 918d9ac17740 Author:ascarpino Date: 2013-05-30 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/918d9ac17740 6750584: Cipher.wrap/unwrap methods should define UnsupportedOperationException Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java ! src/

hg: jdk8/tl/jdk: 8013069: javax.crypto tests fail with new PBE algorithm names

Changeset: 6cb09d3cd309 Author:valeriep Date: 2013-05-29 20:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cb09d3cd309 8013069: javax.crypto tests fail with new PBE algorithm names Summary: Shouldn't auto-generate default parameters for MAC objects. Reviewed-by: vinnie !

hg: jdk8/tl/jdk: 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called

Changeset: 8402ef8fabde Author:ascarpino Date: 2013-05-30 22:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8402ef8fabde 7160837: DigestOutputStream does not turn off digest calculation when "close()" is called Reviewed-by: mullan, xuelei ! src/share/classes/java/securit

hg: jdk8/tl/jdk: 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement

Changeset: 6407106f1b1c Author:xuelei Date: 2013-05-30 22:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6407106f1b1c 8014618: Need to strip leading zeros in TlsPremasterSecret of DHKeyAgreement Reviewed-by: xuelei Contributed-by: Pasi Eronen ! src/share/classes/com/sun/

Re: RFR :7088419 : (L) Use x86 Hardware CRC32 Instruction with java.util.zip.CRC32 and java.util.zip.Adler32

Not sure where this stands, given that Vladimir K has a grand plan to turn the assembly language into an intrinsic (this is not how I would normally approach it) but there is another webrev with the unnecessary import removed: http://cr.openjdk.java.net/~drchase/7088419/webrev.04/ On 2013-05-27

Re: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

Looks good to me. On Thu, May 30, 2013 at 2:18 PM, Brian Burkhalter < brian.burkhal...@oracle.com> wrote: > Hi Martin, > > The changes you suggested below have been made and the webrev updated at > > http://cr.openjdk.java.net/~bpb/7032154/ > > All pertinent JTREG and JCK tests have been re-run

RFR: 8014854 (was Re: RFR: 8012665: CharSequence.chars, CharSequence.codePoints)

The 8014854 changes look good to me after Paul and Henry's suggested improvements. Mike On May 24 2013, at 06:39 , Alan Bateman wrote: > On 29/04/2013 17:51, Henry Jen wrote: >> On 04/26/2013 06:21 AM, Alan Bateman wrote: >>> : >>> I looked through the webrev and it looks okay as a first versio

RFR: 8015686 : (XS) {Int|Long}SummaryStatistics toString() throws IllegalFormatConversionException

Hello all; A very small review for a change which was fixed in the lambda repo (JDK-8012691) but escaped into TL: http://cr.openjdk.java.net/~mduigou/JDK-8015686/0/webrev/ Mike

Re: RFR (S) CR 8014966: Add the proper Javadoc to @Contended

Hi Aleksey; Прогресс! (One of the few Russian words I know thanks to the ISS) Since the statements are grouped by fields and classes, move this to the classes paragraph: "A contention + * group tag has no meaning in a class level {@code @Contended} annotation, + * and is ignored." Describing

hg: jdk8/tl/jdk: 8015271: Conversion table for EUC-KR is incorrect

Changeset: b588955b7e5b Author:sherman Date: 2013-05-30 14:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b588955b7e5b 8015271: Conversion table for EUC-KR is incorrect Summary: to add the requested postal code mark character u+327e Reviewed-by: alanb ! make/tools/Charset

Re: Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh

Hi Erik, This looks good, historically the #!shell was inserted after the CopyRight, because it was thought that the automated CR updaters might get confused. I am cc'ing Dave K, just so that he is aware of this. Thanks Kumar Hello, Please review this simple patch which fixes an issue wi

Re: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

Hi Martin, The changes you suggested below have been made and the webrev updated at http://cr.openjdk.java.net/~bpb/7032154/ All pertinent JTREG and JCK tests have been re-run successfully. Thanks! Brian On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: > The code is awesome. My thorough

Re: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

Hi Iris, On May 30, 2013, at 11:15 AM, Iris Clark wrote: > This looks fantastic. Thanks for reviewing this. > The changes in Formatter look fine to me. > > I also took a quick look at FormattedFloatingDecimal and am thrilled. I > think you changes have also addressed this bug: > > 5057835

Review request for JDK-8014834 : shell tests don't begin with #!/bin/sh

Hello, Please review this simple patch which fixes an issue with several of the shell script tests, namely that they do not start with #!/bin/sh The webrev is here: http://cr.openjdk.java.net/~emc/8014834/ The bug is here: http://bugs.sun.com/view_bug.do?bug_id=8014834 Thanks, Eric

Re: RFR JDK-8015271: Conversion table for EUC-KR is incorrect

On 05/30/2013 05:31 AM, Alan Bateman wrote: On 29/05/2013 18:07, Xueming Shen wrote: Hi, Here is proposal to add one mapping entry into the mapping table for EUC-KR to add the "newly" added KS X 1001:2002 code point 2-71 (EUC_KR:0xA2E8 Unicode: U+0x327E) Info regarding this code point http://

Re: RFR 8005704: Update ConcurrentHashMap to v8

On May 29 2013, at 06:11 , Doug Lea wrote: > On 05/28/13 15:07, Mike Duigou wrote: >> Hi Chris & Doug; > >> - I don't see the advantage to exposing the ConcurrentHashMap.KeySetView type >> particularly for newKeySet(). Why not return Set? The additional methods >> don't seem to offer much that's

RE: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

Hi, Brian. This looks fantastic. The changes in Formatter look fine to me. I also took a quick look at FormattedFloatingDecimal and am thrilled. I think you changes have also addressed this bug: 5057835- FormattedFloatingDecimal: massive code duplication in J2SE http://bugs.sun.com/view_bu

Re: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp.

On 5/30/2013 9:22 AM, Chris Hegarty wrote: Looks fine to me Daniel, I see you have three copies of Objects.java, is it possible to put it in a common place accessible to all? Or maybe this causes other issues. JAXP consists of multiple components. The Xerces and Xalan components specificall

Re: RFR (jaxp): review backport to jdk7u-dev of 8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently

Hi Daniel, This looks good. Thanks again for the extra effort to keep JDK7 updated. -Joe On 5/30/2013 1:59 AM, Daniel Fuchs wrote: Hi, This is a request for review to backport the changes for: to jdk7u-dev. The changeset for jdk7u-dev only sli

Re: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp.

Looks fine to me Daniel, I see you have three copies of Objects.java, is it possible to put it in a common place accessible to all? Or maybe this causes other issues. -Chris. On 05/30/2013 11:37 AM, Daniel Fuchs wrote: Hi, This is a request for review of the backport of

Re: PING! - RFR 7032154: Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

On May 29, 2013, at 11:32 PM, Martin Buchholz wrote: > On Wed, May 29, 2013 at 5:20 PM, Brian > Burkhalter wrote: > On May 29, 2013, at 4:57 PM, Martin Buchholz wrote: >> >> Use third person in the first sentence of a javadoc - e.g. >> s/Retrieve/Retrieves/. >> >> --- >> >> Don't use the den

Re: RFR JDK-8003245

[cc'ing security-dev since this change is in their area] John, http://cr.openjdk.java.net/~jzavgren/8003245/webrev.01/ The changes in your above webrev look fine to me. I can sponsor this for you, unless someone from the security area wants to, or even additional reviews. -Chris. On 03/27

Re: RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp.

Thanks Daniel! The backport looks good. This would help keep the code in sync between JKD7 and JDK8, which makes it easier for future backports. Joe On 5/30/2013 3:37 AM, Daniel Fuchs wrote: Hi, This is a request for review of the backport of

hg: jdk8/tl/jdk: 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst()

Changeset: b4742d038100 Author:psandoz Date: 2013-05-28 15:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4742d038100 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst() Reviewed-by: alanb, chegar ! src/share/classes/java/util/stream/DoubleStream.java ! src

hg: jdk8/tl/jdk: 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder

Changeset: 156ee44cd456 Author:psandoz Date: 2013-05-30 16:08 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ee44cd456 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder Summary: Also fixes documentation on StreamBuilder.OfDouble Reviewed-by: alanb, chegar, md

Re: RFR (S) CR 8014966: Add the proper Javadoc to @Contended

Hi David, I understand that but there may exist some set of contention groups that could be co-located (share a cache line) without causing additional interference but the Annotation does not have a mechanism to express that. Given the restriction on inheritance of @Contended, it is not even p

Re: RFR JDK-8015271: Conversion table for EUC-KR is incorrect

On 29/05/2013 18:07, Xueming Shen wrote: Hi, Here is proposal to add one mapping entry into the mapping table for EUC-KR to add the "newly" added KS X 1001:2002 code point 2-71 (EUC_KR:0xA2E8 Unicode: U+0x327E) Info regarding this code point http://www.unicode.org/L2/L2004/04267-n2815.pdf H

hg: jdk8/tl/jdk: 8015627: test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails in agentvm mode

Changeset: dc22b7241a70 Author:jbachorik Date: 2013-05-30 13:58 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc22b7241a70 8015627: test/com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.java fails in agentvm mode Reviewed-by: alanb, chegar ! test/

FW: PhantomReference: why not cleared by GC when enqueued?

Mark, You are listed as an author of java.lang.ref classes. So you must know more than others. Could you shed light on this? Thank you, Dmytro From: dmytro_she...@hotmail.com To: hotspot-gc-...@openjdk.java.net; core-libs-dev@openjdk.java.net Subject: PhantomReference: why not cleared by GC whe

hg: jdk8/tl/jdk: 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c

Changeset: 6df9b071b04d Author:jzavgren Date: 2013-05-30 12:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6df9b071b04d 8015299: Memory leak in jdk/src/solaris/bin/java_md_solinux.c Reviewed-by: martin, dholmes, chegar, ksrini ! src/solaris/bin/java_md_solinux.c

RFR (jaxp): Backport to jdk7u-dev of 8013900: More warnings compiling jaxp.

Hi, This is a request for review of the backport of to jdk7u-dev. The changeset for jdk7u-dev [1] had to be altered on one count compared to the changes pushed in jdk8 [2]: Since jaxp needs to be compiled using the bootstrap compiler, it was not

RFR (jaxp): review backport to jdk7u-dev of 8008738 - Issue in com.sun.org.apache.xml.internal.serializer.Encodings causes some JCK tests to fail intermittently

Hi, This is a request for review to backport the changes for: to jdk7u-dev. The changeset for jdk7u-dev only slightly differs from that for jdk 8, on these two counts: 1. JAXP needs to be compiled with the bootstrap JDK - which means that JAXP

Re: RFR (S) CR 8014966: Add the proper Javadoc to @Contended

Hi Roger, On 05/29/2013 10:48 PM, roger riggs wrote: > Thanks for the references. Currently, you are correct, I don't need it. Now I am envious! > Has it been considered that highly contended field should not be allocated > in the object itself anyway but in some pool or structure better suited

Re: RFR (S) CR 8014966: Add the proper Javadoc to @Contended

On 05/30/2013 12:49 PM, Aleksey Shipilev wrote: > On 05/29/2013 10:48 PM, roger riggs wrote: >> Has it been considered that highly contended field should not be allocated >> in the object itself anyway but in some pool or structure better suited >> to its access characteristics? A read-only indire

Re: RFR (S) CR 8014966: Add the proper Javadoc to @Contended

On 05/29/2013 11:29 PM, Martin Buchholz wrote: > Looks good enough to me for a non-public API. I expect more contentious > arguments if this is ever made public, since the problems remain very > tricky. Yes, that's why we want to keep it internal for now. I'd like to hear the final "yes" from D

Re: RFR (S) CR 8014966: Add the proper Javadoc to @Contended

Roger, I think you may be misunderstanding the purpose of the contention groups. They are, as the docs state, for defining a set of fields that need isolation from other sets of fields. They are not for defining set of fields which would benefit from co-location. David On 30/05/2013 4:48 AM

Re: 8015470: (ann) IncompleteAnnotationException does not need to call toString

Hi Otavio, On 29/05/2013 9:03 PM, Otávio Gonçalves de Santana wrote: Thank you everyone. I searched classes with this situation and I find these classes: * sun.tools.java.MemberDefinition * sun.rmi.rmic.Main * sun.tools.jconsole.inspector.Utils * com.sun.jndi.toolkit.dir.SearchFilter

Re: Fw: Generics in enums

On 05/30/2013 09:26 AM, Remi Forax wrote: On 05/30/2013 09:06 AM, Victor Polischuk wrote: Good day Joe, Thank you for your prompt reply. If I understood you correctly, it is not the solution which can help me distinguish enum elements by type parameters. I would like to have restrictions on t

Re: Fw: Generics in enums

On 05/30/2013 09:06 AM, Victor Polischuk wrote: Good day Joe, Thank you for your prompt reply. If I understood you correctly, it is not the solution which can help me distinguish enum elements by type parameters. I would like to have restrictions on types which can be passed to a enum instance

Re[2]: Fw: Generics in enums

Good day Joe, Thank you for your prompt reply. If I understood you correctly, it is not the solution which can help me distinguish enum elements by type parameters. I would like to have restrictions on types which can be passed to a enum instance methods and reduce numbers of casts or "instance