Re: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Hi David, On 2019/7/22 下午2:55, David Holmes wrote: Did you use -N when generating the webrev? You shouldn't in this case. Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate webrev.02. Updated: http://cr.openjdk.java.net/~jiefu/8225648/webrev.03/ webrev.03 was generated by `ksh

Re: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

On 22/07/2019 5:14 pm, Jie Fu wrote: Hi David, On 2019/7/22 下午2:55, David Holmes wrote: Did you use -N when generating the webrev? You shouldn't in this case. Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate webrev.02. Updated: http://cr.openjdk.java.net/~jiefu/8225648/webr

Re: Fwd: Re: RFR: 8225648:[TESTBUG] java/lang/annotation/loaderLeak/Main.java fails with -Xcomp

Thank you so much, David. On 2019/7/22 下午3:26, David Holmes wrote: On 22/07/2019 5:14 pm, Jie Fu wrote: Hi David, On 2019/7/22 下午2:55, David Holmes wrote: Did you use -N when generating the webrev? You shouldn't in this case. Yes, I had used `ksh webrev.ksh -u jiefu -N -r 55752` to generate

Re: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642

Hi Mandy, On Fri, 2019-07-19 at 10:32 -0700, Mandy Chung wrote: > I still think separating container-specific APIs in its own class will > prevent running similar kind of issue in the future. Take 03: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/ This now reverts Platform.

java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ?

Hello , maybe someone with more OSX dev knowledge could comment on this . If I understand it correctly , the OSX Core Foundation Ownership Policy : https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html#//apple_ref/doc/uid/2

Re: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642

On 22/07/2019 10:12, Severin Gehwolf wrote: : Take 03: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/ This now reverts Platform.java changes to the version prior JDK- 8227642, introduces a Container class with one constant, CONTAINER_ENGINE, and renames the jdk.test.docker.c

Re: RFR: 8228434: jdk/net/Sockets/Test.java fails after JDK-8227642

On Mon, 2019-07-22 at 12:06 +0100, Alan Bateman wrote: > On 22/07/2019 10:12, Severin Gehwolf wrote: > > : > > Take 03: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/ > > > > This now reverts Platform.java changes to the version prior JDK- > > 8227642, introduces a Contain

[13] RFR: 8228450: unicode.md and icu.md text should be pre-formatted

Hi, Please review this doc only fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8228450 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8228450/webrev.00/ This is simply to supply triple back ticks (```) in the .md files so that the text will not

Re: [13] RFR: 8228450: unicode.md and icu.md text should be pre-formatted

Looks fine On 7/22/19 10:54 AM, naoto.s...@oracle.com wrote: Hi, Please review this doc only fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8228450 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8228450/webrev.00/ This is simply to supply tripl

Re: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter

> On Jul 20, 2019, at 12:44 AM, Alan Bateman wrote: > > On 19/07/2019 15:58, Brian Burkhalter wrote: >> >> Given the compatibility issues it might be best to modify the specifications >> of the Filter*Stream subclass constructors to allow a null underlying stream >> parameter, thereby overri

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

> On Jul 20, 2019, at 9:15 AM, Alan Bateman wrote: > > On 18/07/2019 16:32, Brian Burkhalter wrote: >> Resuming this topic, what is the general view on the three possible paths: >> >> 1. Override write(byte[]) at the risk of incompatibility. >> 2. Instead add writeBytes(byte[]) as in ByteArray

RFR: 8228397: Missing license copyright header in some resource properties files

Hi all, Please review this change. We found the license copyright header are missing in some resource properties files, some of them are very old and no hg log since code forest consolidation. In this change, I added the license copyright header in the English and its localized resource files

Re: 8228392: java.io.Filter{In,Out}put stream constructors should allow null stream parameter

> On Jul 22, 2019, at 11:13 AM, Brian Burkhalter > wrote: > > >> On Jul 20, 2019, at 12:44 AM, Alan Bateman wrote: >> >> On 19/07/2019 15:58, Brian Burkhalter wrote: >>> >>> Given the compatibility issues it might be best to modify the >>> specifications of the Filter*Stream subclass cons

RE: RFR: 8228397: Missing license copyright header in some resource properties files

Hi, Leo. Thanks for adding legal notices (copyright and license) to these resource .property files. For the files in src/demo/share/jfc/*.properties, is there any reason why the legal notices should not be in a separate comment block? Right now, it appears that you've prepended the legal noti

8202469 / 8202473: Correct type annotation resolution for class type variables

Hello, I created a patch and test cases for two bugs (JDK-8202469 and JDK-8202473) that I have reported a while ago: https://gist.github.com/raphw/c5d6222b990573aaeaf4571aad3a7fa3 This is my first direct contribution and I hope I am following the protocol correctly. I ran all tier1 tests after ap

Re: RFR: 8228397: Missing license copyright header in some resource properties files

Hi Leo, Thanks for adding the copyright and license header.  The patch looks okay assuming you will separate the legal notices from the existing comment block in JFC properties files. Mandy On 7/22/19 9:23 AM, li.ji...@oracle.com wrote: Hi all, Please review this change. We found the lice

Re: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ?

Hi Matthias, Thanks for catching them. Yes, I believe they should be released appropriately. Naoto On 7/22/19 4:01 AM, Baesken, Matthias wrote: Hello , maybe someone with more OSX dev knowledge could comment on this . If I understand it correctly , the OSX Core Foundation Ownership P

Re: RFR: 8228397: Missing license copyright header in some resource properties files

+1 Naoto On 7/22/19 12:55 PM, Mandy Chung wrote: Hi Leo, Thanks for adding the copyright and license header.  The patch looks okay assuming you will separate the legal notices from the existing comment block in JFC properties files. Mandy On 7/22/19 9:23 AM, li.ji...@oracle.com wrote: Hi

8202471: Resolves generic receiver type for types with generic signatures

Hello, I have created a patch such that getReceiverType() returns a parameterized type if the receiver type declaration is itself generic. Currently, the receiver type is always a type representation of Class such that annotations on the type variables or the receiver type's owner type cannot be r

Re: Review Request: JDK-8219774: Reexamine the initialization of LangReflectAccess shared secret at AccessibleObject::

On 7/20/19 8:08 AM, Alan Bateman wrote: On 19/07/2019 17:20, Mandy Chung wrote: This was a follow up to the observation during the code review of JDK-82193798. Webrev:    http://cr.openjdk.java.net/~mchung/jdk14/8219774/webrev.01/ This cleanup looks good to me. A minor nit is that ReflectAc

Re: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause

[Dropping 2d-dev mailing list from the discussion as desktop is no longer affected.] > On Jul 22, 2019, at 8:15 AM, Brian Burkhalter > wrote: > >> On Jul 20, 2019, at 9:15 AM, Alan Bateman > > wrote: >> >> On 18/07/2019 16:32, Brian Burkhalter wrote: >>> Resumi

Re: 8202471: Resolves generic receiver type for types with generic signatures

Hi Rafael, A couple of comments on process here ... On 23/07/2019 6:48 am, Rafael Winterhalter wrote: Hello, I have created a patch such that getReceiverType() returns a parameterized type if the receiver type declaration is itself generic. Currently, the receiver type is always a type represe

Re: 8202471: Resolves generic receiver type for types with generic signatures

Thanks, I'll send an inline version this evening. I have written a couple of reproducers for these issues. Should I add them to jtreg and also send them as an inline patch? I'll submit the CSR tonight, too. Thanks for the pointers! Best regards, Rafael David Holmes schrieb am Di., 23. Juli 2019

Re: 8202471: Resolves generic receiver type for types with generic signatures

On 23/07/2019 3:08 pm, Rafael Winterhalter wrote: Thanks, I'll send an inline version this evening. I have written a couple of reproducers for these issues. Should I add them to jtreg and also send them as an inline patch? Yes, please do. Thanks, David I'll submit the CSR tonight, too. Tha

Re: java_props_macosx.c : CFLocaleCopyCurrent() needs CFRelease ?

Thanks for your input ! I opened https://bugs.openjdk.java.net/browse/JDK-8228501 for this issue, will provide a patch . Best regards, Matthias > Date: Mon, 22 Jul 2019 12:56:50 -0700 > From: naoto.s...@oracle.com > To: core-libs-dev@openjdk.java.net > Subject: Re: java_props_macosx.c : CFLo