RFR JDK-8155616: java/util/zip/TestLocalTime.java fails intermittently with storing mtime failed

Hi Amy, I finally got to the bottom of this failure. It appears the timestamps that trigger the failure are those that (1) < 1980 and (2) within the daylight saving time gap, which means the local date-time is actually not valid, for example 1968-04-28/2:51:25, this ldt should be adjusted to 3:

RE: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

> -Original Message- > From: Amy Lu [mailto:amy...@oracle.com] > Sent: Monday, July 18, 2016 5:42 PM > To: Frank Yuan; 'core-libs-dev' > Subject: Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit > tests > > On 7/18/16 5:32 PM, Frank Yuan wrote: > > Btw, I moved internalt

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

+1 to Martin and Remi. The call to registerMethodsToFilter is very old, way out of date, and accomplishes nothing useful today. Modular access checks for reflective method calls is our main line of defense, if the security manager is turned off. There are other things we might try in the future

Re: Change of the toString implementation for annotations

Hello Rafael, On 7/18/2016 5:43 PM, Rafael Winterhalter wrote: Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property. When calling toString on an annotation: @interface Foo { Class value(); } instantiated as @Fo

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Recent discussion here: http://markmail.org/search/?q=core-libs-dev%20ConcurrentHashMap%20jdk.internal.misc.unsafe#query:core-libs-dev%20ConcurrentHashMap%20jdk.internal.misc.unsafe+page:1+mid:iviymmlotcuasv6t+state:results There are too many places where reflective code can get its hands on a jd

Re: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

Hi Brian, As as grammatical comment, I might start with "The {@code java.prefs} module defines ...", but otherwise, the change looks fine. Thanks, -Joe On 7/18/2016 5:45 PM, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161402

Re: RFR: 8158295 Add a multi-release jar validation mechanism to jar tool

>> Please review the following: >> >> webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/ >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8158295 >> >> >> This changeset ad

JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161402 Patch: [1] Thanks, Brian [1] diff --- a/src/java.prefs/share/classes/module-info.java +++ b/src/java.prefs/share/classes/module-info.java @@ -23,6 +23,10 @@ * questions. */ +/** + * java.prefs de

Change of the toString implementation for annotations

Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property. When calling toString on an annotation: @interface Foo { Class value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as: @Foo(class Bar)

Re: JDK 9 RFR of JDK-8161567: Mark java/util/concurrent/forkjoin/FJExceptionTableLeak.java as intermittently failing

Okay, we're all agreed. Amy can demote this test, and I'll try to think hard about how to improve the test, with my newfound insight. On Mon, Jul 18, 2016 at 5:00 PM, Joseph D. Darcy wrote: > Hello, > > While the underlying issues are being investigated, I think it is > worthwhile to tag the te

Re: JDK 9 RFR of JDK-8161567: Mark java/util/concurrent/forkjoin/FJExceptionTableLeak.java as intermittently failing

Hello, While the underlying issues are being investigated, I think it is worthwhile to tag the test as intermittently failing to aid those having to QA any if its failures. Cheers, -Joe On 7/18/2016 4:56 PM, David Holmes wrote: Hi Martin, On 19/07/2016 12:38 AM, Martin Buchholz wrote: Li

Re: JDK 9 RFR of JDK-8161567: Mark java/util/concurrent/forkjoin/FJExceptionTableLeak.java as intermittently failing

Hi Martin, On 19/07/2016 12:38 AM, Martin Buchholz wrote: Like I always say, I'm unhappy with the increased memory requirements. Java programs that used to run in 4m now need more than 8m. Hotspot should be fixed! I've updated the comments in https://bugs.openjdk.java.net/browse/JDK-8151158

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

>> It’s used in two places, moving it to jarPackages won’t work, I think. I >> also put a check in to see if it’s a multi-release jar. > I meant to move the method down to where jarPackages is located. I would > probably adjust the comment too but we can do that once your changes are in > jdk9/

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

On 18/07/2016 19:06, Steve Drach wrote: It’s used in two places, moving it to jarPackages won’t work, I think. I also put a check in to see if it’s a multi-release jar. I meant to move the method down to where jarPackages is located. I would probably adjust the comment too but we can do that

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

>> Please review this change to JarFile that reverts JarFile::stream and >> JarFile::entries to JDK 8 behavior. The code is identical to that in JDK 8 >> except line 504 in JarEntryIterator that now uses a different constructor to >> create a JarFileEntry. I also added some implementation note

Re: RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

Hi Svetlana, Thanks for working on these bugs. The change is correct. It would be better to say: "Returns the month of this calendar", in both the returns tag and the description (not number of month). While we are in this class, it would be good to at least fix the missing @returns tags in

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Hi Paul, - Mail original - > De: "Paul Sandoz" > À: "Core-Libs-Dev" > Envoyé: Lundi 18 Juillet 2016 18:06:44 > Objet: 8161129 Unsafe::getUnsafe should allow the platform class loader to > access it > > Hi, > > Please review the patch below. > [...] > I also took the opportunity

Re: JDK 9 RFR of JDK-8161500: Use getTypeName and StringJoiner in core reflection toString methods

Hi Claes, On 7/15/2016 4:55 PM, Claes Redestad wrote: Looks OK, although I find: StringJoiner sj = StringJoiner(delimiter, before, after); ... sb.append(sj.toString()); to be a messier read than: sb.append(before); StringJoiner sj = new StringJoiner(delimiter); ... sb.append(sj.toString())

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

On 18/07/2016 17:33, Peter Levart wrote: Hi Paul, Just curious, what was the purpose of hiding a public method in a public class in an exported package from reflection? I'm talking about sun.misc.Unsafe::getUnsafe ... Regards, Peter As I recall, it was an effort in JDK 6 (and prior to OpenJ

Re: 8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Hi Paul, Just curious, what was the purpose of hiding a public method in a public class in an exported package from reflection? I'm talking about sun.misc.Unsafe::getUnsafe ... Regards, Peter On 07/18/2016 06:06 PM, Paul Sandoz wrote: Hi, Please review the patch below. Since Jigsaw encaps

Re: [9] RFR: 8159214: jlink --include-locales problems

+1 > On Jul 18, 2016, at 12:54 PM, Naoto Sato wrote: > > Ping. > > On 7/14/16 5:42 AM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8159214 >> >> The fix is located at: >> >> http://cr.openjdk.java.net/~naoto/

8161129 Unsafe::getUnsafe should allow the platform class loader to access it

Hi, Please review the patch below. Since Jigsaw encapsulates jdk.internal.misc.Unsafe there is no need to perform any runtime checks such as: - hiding the getUnsafe method from reflection; and - checking the class loader of the calling class for invocation of getUnsafe. This more cleanly enabl

Re: [9] RFR: 8159214: jlink --include-locales problems

Ping. On 7/14/16 5:42 AM, Naoto Sato wrote: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8159214 The fix is located at: http://cr.openjdk.java.net/~naoto/8159214/webrev.04/ Naoto

RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

Hello all, please review this javadoc fix for javax.xml.datatype.XMLGregorianCalendar.getMonth() Webrev: http://cr.openjdk.java.net/~snikandrova/8021787/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8021787 Thank you,

Re: RFR(XXXXXXXS): 8161034 Incorrect GPL header in jdk/src/java.base/windows/native/libjava/jni_util_md.c

Thanks for the review Alan! Fred On 18/07/2016 10:39, Alan Bateman wrote: On 18/07/2016 14:48, frederic parain wrote: Hello, src/java.base/windows/native/libjava/jni_util_md.c file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing

Re: RFR(XXXXXXXS): 8161034 Incorrect GPL header in jdk/src/java.base/windows/native/libjava/jni_util_md.c

On 18/07/2016 14:48, frederic parain wrote: Hello, src/java.base/windows/native/libjava/jni_util_md.c file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition:

Re: JDK 9 RFR of JDK-8161567: Mark java/util/concurrent/forkjoin/FJExceptionTableLeak.java as intermittently failing

Like I always say, I'm unhappy with the increased memory requirements. Java programs that used to run in 4m now need more than 8m. Hotspot should be fixed! If this is dependent on the particular GC, maybe there's a way to require not having that gc. I see: ./java/lang/management/MemoryMXBean/Lo

RFR(XXXXXXXS): 8161034 Incorrect GPL header in jdk/src/java.base/windows/native/libjava/jni_util_md.c

Hello, src/java.base/windows/native/libjava/jni_util_md.c file contains incorrect GPL header which fails make/scripts/lic_check.sh script check. Failure is caused by missing comma after modification years. Please, help to review its addition: http://cr.openjdk.java.net/~fparain/8161034/w

Re: RFR(S): 8161212: Test times out: java/lang/invoke/LoopCombinatorLongSignatureTest.java

Hi Claes, thank you. Of course you're right about the -run option; I've replaced this with a -D interface and pushed that version. Best, Michael > Am 18.07.2016 um 12:57 schrieb Claes Redestad : > > Hi, > > On 2016-07-13 15:12, Michael Haupt wrote: >> Dear all, >> >> please review this fix.

Re: RFR(S): 8161212: Test times out: java/lang/invoke/LoopCombinatorLongSignatureTest.java

Hi, On 2016-07-13 15:12, Michael Haupt wrote: Dear all, please review this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8161212 Webrev: http://cr.openjdk.java.net/~mhaupt/8161212/webrev.00/ fix looks OK, but I'm genuinely curious about best practice when it comes to pass arguments to j

Re: RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

On 7/18/16 5:32 PM, Frank Yuan wrote: Btw, I moved internaltest into unittest because it's unnecessary to separate them. Maybe you'd like to regenerate the webrev with hg move for those files? Thanks, Amy

RFR (JAXP) JDK-8067170: Enable security manager on JAXP unit tests

Hi Would you like to review http://cr.openjdk.java.net/~fyuan/8067170/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8067170 In this change, I enabled security manager for JAXP unit tests with improving the implementation approach and fixing some defects. Now jaxp tests use TestNG a

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

> On 15 Jul 2016, at 23:17, Steve Drach wrote: > > Hi, > > Please review this change to JarFile that reverts JarFile::stream and > JarFile::entries to JDK 8 behavior. The code is identical to that in JDK 8 > except line 504 in JarEntryIterator that now uses a different constructor to > crea