From amaembo at gmail.com Mon Oct 1 03:40:52 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 1 Oct 2018 10:40:52 +0700 Subject: Convert old-style array declarations (was: Re: ByteArrayOutputStream should not have a new writeBytes method in Java) In-Reply-To: References: <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com> Message-ID: Hello! Ok, let's start with smaller thing which is java.desktop. Created a JBS issue and posted a patch here: http://mail.openjdk.java.net/pipermail/2d-dev/2018-October/009486.html Jonathan, > Although cleanup like this is nice, I'll give a word of warning that pervasive > changes like that can sometimes cause difficulties when there are lots of > changes in code which is undergoing different lines of development in different > branches or repos. If nothing else, I'd consider doing it on a per-component > or per-module basis. I'm not sure I have enough time to post 70+ reviews for every module and track all of them. My volunteering abilities are quite limited :-) I think I can manage up to 3-4 separate changesets including already posted java.desktop change. If you have suggestions on how to split this to several big parts, you are welcome (I don't know how "components" are mapped to modules, probably components are big enough?). Or probably we can cover only part of modules for now and wait for the next volunteer to pick up this. With best regards, Tagir Valeev. On Sat, Sep 29, 2018 at 5:41 AM Sergey Bylokhov wrote: > > I can review the changes in java.desktop, please use these email alias > awt-dev/2d-dev/swing-dev. > > On 28/09/2018 04:13, Alan Bateman wrote: > > As regards doing the entire source base then I think that would be good. > > Due to the complexity of testing, changes to the java.desktop module are > > pushed to jdk/client repo rather than jdk/jdk so if it's not too awkward > > then it might be helper if the patch for java.desktop were a separate > > change that gets pushed to jdk/client rather than jdk/jdk. > > > -- > Best regards, Sergey. From amaembo at gmail.com Mon Oct 1 05:03:20 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 1 Oct 2018 12:03:20 +0700 Subject: Optimized HashSet.toArray() Message-ID: Hello! I think that HashSet.toArray(), HashMap.keySet().toArray() and HashMap.values().toArray() methods are used often enough to deserve a dedicated optimized implementation. Here's the patch I propose which is based on KeySet#forEach and AbstractCollection#toArray implementations: http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/patch.txt I performed quick JMH test for HashSet.toArray(). The source code is here: http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/jmh/ToArray.java Result on JDK 11+28 is here: http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/jmh/jmh_toArray_11.txt Result on JDK 11+28 with patch applied is here http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/jmh/jmh_toArray_11_patched.txt Summary (non-patched): Benchmark (size) Score Error Units ToArray.toArray 0 6,327 ? 0,094 ns/op ToArray.toArray 1 55,040 ? 0,389 ns/op ToArray.toArray 10 112,903 ? 3,571 ns/op ToArray.toArray 1000 11281,875 ? 74,423 ns/op ToArray.toArray 100000 2795345,640 ? 57164,196 ns/op ToArray.toArray 10000000 443763064,267 ? 82551994,563 ns/op ToArray.toArrayPresized 0 8,244 ? 0,054 ns/op ToArray.toArrayPresized 1 57,094 ? 0,431 ns/op ToArray.toArrayPresized 10 105,456 ? 3,831 ns/op ToArray.toArrayPresized 1000 11935,895 ? 251,150 ns/op ToArray.toArrayPresized 100000 2771938,363 ? 42917,423 ns/op ToArray.toArrayPresized 10000000 421335484,317 ? 66222482,723 ns/op ToArray.toObjectArray 0 8,288 ? 0,060 ns/op ToArray.toObjectArray 1 49,415 ? 2,454 ns/op ToArray.toObjectArray 10 94,243 ? 2,346 ns/op ToArray.toObjectArray 1000 10061,125 ? 77,197 ns/op ToArray.toObjectArray 100000 2455011,037 ? 86539,734 ns/op ToArray.toObjectArray 10000000 416595706,650 ? 84619961,188 ns/op Summary (patched): Benchmark (size) Score Error Units ToArray.toArray 0 5,319 ? 0,050 ns/op ToArray.toArray 1 22,235 ? 0,365 ns/op ToArray.toArray 10 57,515 ? 0,687 ns/op ToArray.toArray 1000 6586,112 ? 71,258 ns/op ToArray.toArray 100000 1700754,903 ? 41289,676 ns/op ToArray.toArray 10000000 299815797,250 ? 37778823,759 ns/op ToArray.toArrayPresized 0 6,689 ? 0,042 ns/op ToArray.toArrayPresized 1 44,852 ? 0,813 ns/op ToArray.toArrayPresized 10 66,904 ? 0,748 ns/op ToArray.toArrayPresized 1000 7839,880 ? 75,954 ns/op ToArray.toArrayPresized 100000 1605381,429 ? 55070,143 ns/op ToArray.toArrayPresized 10000000 292954965,933 ? 45912224,761 ns/op ToArray.toObjectArray 0 6,608 ? 0,049 ns/op ToArray.toObjectArray 1 28,085 ? 0,326 ns/op ToArray.toObjectArray 10 58,170 ? 2,716 ns/op ToArray.toObjectArray 1000 5979,407 ? 55,930 ns/op ToArray.toObjectArray 100000 1420318,139 ? 27226,724 ns/op ToArray.toObjectArray 10000000 255417541,372 ? 33366555,142 ns/op As you can see, the patched version is always faster, sometimes 2x and even more. Also it doesn't allocate anything except the target array when necessary (current version allocates an iterator). If anybody is interested to sponsor this change, I can log a JBS issue and provide proper webrev for review. Do we need to add new unit-tests or these methods are covered enough by existing tests? With best regards, Tagir Valeev. From christoph.langer at sap.com Mon Oct 1 06:46:54 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 1 Oct 2018 06:46:54 +0000 Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files In-Reply-To: <5BAF0CD6.90803@oracle.com> References: <5BAF0CD6.90803@oracle.com> Message-ID: Hi Sherman, thanks for getting back and bringing up these points. > (1) There is a "masked" security concern regarding adding the > "ownership/permission" into the jar file. > > "Security concern: > > The current signed jar spec only protects the name and content of the jar > entries. If any extra info is added, its value will not be used in the > signing/verifying process. This means anyone can change these info in a > signed jar and the user has no way to check if the file is genuine." I didn't know that. However, as the default behavior does not change, these permission bits will not be propagated/used, unless the developer uses the API or the user of the jar tool enables the new option. One should probably add comments about this signing issue in the documentation then. Is there any way to augment jar signing to (conditionally?) include the external attributes field? > (2) Regarding the implementation whats the motivation of use the high byte > of the "external file > attributes" vs to use the info-zip as suggested in the report? I've not looked > into zip/unzip > implementation, which one is zip/unzip using? > > "A group known as INFO-zip has devised a number of different extensions > for ZIP for Unix. Their first and second extension attempts added > support for UID and GID but not permissions. The third Unix extension, > also known as the "ASi" or "un" extension, provides for file permissions > and symlinks also. These extensions have become de-facto standards, > and have not changed now since 1996." I'm not aware of a document of specification for the INFO-zip extensions regarding UID, GID and even permissions. Maybe you can share this with me. But I've checked InfoZip's Zip and UnZip sources at https://sourceforge.net/projects/infozip/files/ and found they're using the CENATX field ( >> 16) like my patch does. Best regards Christoph From takiguc at linux.vnet.ibm.com Mon Oct 1 07:56:21 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 01 Oct 2018 16:56:21 +0900 Subject: How can I solve Modularity related issue ? In-Reply-To: References: <8632f274-3567-6121-5a60-cf626f8d5c3c@oracle.com> Message-ID: <6e06a8a1c869b5e89342d8d767ce6a39@linux.vnet.ibm.com> Hello Alan and Mandy. I appreciate your explanation and action. Also I read Lance's mail. http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055780.html I verified Lance's patch, it worked... Many thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-09-29 09:35, Mandy Chung wrote: > On 9/28/18 1:59 AM, Alan Bateman wrote: >> On 28/09/2018 08:28, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> One of JDBC application with JavaDB did not work on JDK12. >>> Following exception happened: >>> ? java.sql.SQLException: No suitable driver found for >>> jdbc:derby:xxxxxx >>> >>> I assume, this issue related Modularity feature... >>> I could not solve this issue by myself. >> I suspect this is related to the de-privileging of the java.sql.rowset >> module in JDK 9. The java.sql.rowset module is mapped to the platform >> class loader whereas historically the types in this module were >> defined by the boot class loader. This is relevant because >> java.sql.rowset is making use of the java.sql.DriverManager (in the >> java.sql module) and DriverManager is caller sensitive so it sees the >> caller coming from java.sql.rowset. This is problematic because the >> JDBC driver is on the class path and is not visible to the caller's >> class loader. The visibility check has always been in JDBC and I >> suspect this usage in the JDBC Rowset implementation only worked by >> accident in the past because DriverManager used the TCCL when called >> from code defined to the bootstrap class loader. I'm sure Lance will >> jump in but all previous investigations into changing behavior going >> back 20+ has come to nothing due to compatibility concerns. >> > > It does look like related to the de-privileging of java.sql.rowset > module.? JDBC rowset implementation just happened to work in the past > as it was defined to the bootstrap class loader. > > I have created JBS issue for this: > ?? https://bugs.openjdk.java.net/browse/JDK-8211295 > > Mandy From lance.andersen at oracle.com Mon Oct 1 11:21:38 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 1 Oct 2018 07:21:38 -0400 Subject: How can I solve Modularity related issue ? In-Reply-To: <6e06a8a1c869b5e89342d8d767ce6a39@linux.vnet.ibm.com> References: <8632f274-3567-6121-5a60-cf626f8d5c3c@oracle.com> <6e06a8a1c869b5e89342d8d767ce6a39@linux.vnet.ibm.com> Message-ID: <15CEF705-0281-4E17-883A-9CF89F8E3778@oracle.com> I will be pushing the fix back later today Best Lance > On Oct 1, 2018, at 3:56 AM, Ichiroh Takiguchi wrote: > > Hello Alan and Mandy. > > I appreciate your explanation and action. > > Also I read Lance's mail. > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055780.html > > I verified Lance's patch, it worked... > > Many thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-09-29 09:35, Mandy Chung wrote: >> On 9/28/18 1:59 AM, Alan Bateman wrote: >>> On 28/09/2018 08:28, Ichiroh Takiguchi wrote: >>>> Hello. >>>> One of JDBC application with JavaDB did not work on JDK12. >>>> Following exception happened: >>>> java.sql.SQLException: No suitable driver found for jdbc:derby:xxxxxx >>>> I assume, this issue related Modularity feature... >>>> I could not solve this issue by myself. >>> I suspect this is related to the de-privileging of the java.sql.rowset module in JDK 9. The java.sql.rowset module is mapped to the platform class loader whereas historically the types in this module were defined by the boot class loader. This is relevant because java.sql.rowset is making use of the java.sql.DriverManager (in the java.sql module) and DriverManager is caller sensitive so it sees the caller coming from java.sql.rowset. This is problematic because the JDBC driver is on the class path and is not visible to the caller's class loader. The visibility check has always been in JDBC and I suspect this usage in the JDBC Rowset implementation only worked by accident in the past because DriverManager used the TCCL when called from code defined to the bootstrap class loader. I'm sure Lance will jump in but all previous investigations into changing behavior going back 20+ has come to nothing due to compatibility concerns. >> It does look like related to the de-privileging of java.sql.rowset >> module. JDBC rowset implementation just happened to work in the past >> as it was defined to the bootstrap class loader. >> I have created JBS issue for this: >> https://bugs.openjdk.java.net/browse/JDK-8211295 >> Mandy > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From pallavi.sonal at oracle.com Mon Oct 1 13:24:42 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Mon, 1 Oct 2018 06:24:42 -0700 (PDT) Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets In-Reply-To: <55f0a5e5-4d0b-e647-f581-ae0e1ca94c78@oracle.com> References: <38b8864c-e283-44f7-a962-aa65fb560b79@default> <871fb443-47c9-4860-815a-5d2064118fbb@default> <65120bb8-af2a-4144-a334-f1057c21fbf6@default> <0b15557a-a158-4f79-be93-d5a18ac950a2@default> <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com> <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default> <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com> <55f0a5e5-4d0b-e647-f581-ae0e1ca94c78@oracle.com> Message-ID: Hi Naoto, Here is the CSR for review : https://bugs.openjdk.java.net/browse/JDK-8211316 Thanks, Pallavi Sonal -----Original Message----- From: Naoto Sato Sent: Friday, September 28, 2018 9:38 PM To: Pallavi Sonal ; Roger Riggs ; core-libs-dev Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets Hi Pallavi, Please file a CSR for this, as this will change the behavior. Naoto On 9/28/18 8:53 AM, Pallavi Sonal wrote: > Thanks Roger. I will update it before the commit. > > -----Original Message----- > From: Roger Riggs > Sent: Friday, September 28, 2018 6:15 PM > To: Pallavi Sonal ; core-libs-dev > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should > handle offsets > > Hi Pallavi, > > Looks fine, > > But can you re-wrap the lines with the new links, they got longer than > 100 chars with the link. > > No new webrev is needed. > > Thanks, Roger > > > On 9/28/18 8:35 AM, Pallavi Sonal wrote: >> Thanks Roger and Stephen. Here is the updated webrev with the suggested changes: >> http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/ >> >> Thanks, >> Pallavi Sonal >> >> -----Original Message----- >> From: Roger Riggs >> Sent: Friday, September 28, 2018 12:51 AM >> To: core-libs-dev >> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should >> handle offsets >> >> Hi Pallavi, >> >> I'd suggest using @link for the reference (in both files). >> It will be easier for the reader to traverse and understand the pattern. >> >> DateTimeFormatterBuilder.java: line 836. >> The trailing "

" should be omitted so the readability of the source is maintained. >> >> Otherwise, looks good, >> >> Thanks, Roger >> >> >> >> On 09/27/2018 03:39 AM, Stephen Colebourne wrote: >>> In DateTimeFormatter you need to qualify the @code part to refer to >>> DateTimeFormatterBuilder. >>> Otherwise good. >>> thanks >>> Stephen >>> >>> >>> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal wrote: >>>> Thanks for the clarification. Here is the updated webrev for review : >>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ >>>> >>>> Thanks, >>>> Pallavi Sonal >>>> >>>> -----Original Message----- >>>> From: Stephen Colebourne >>>> Sent: Tuesday, September 25, 2018 4:39 PM >>>> To: core-libs-dev >>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>> should handle offsets >>>> >>>> I think it makes sense for both, although I was only considering >>>> appendInstant() when I wrote it. >>>> Stephen >>>> >>>> >>>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal wrote: >>>>> Hi Stephen, >>>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT as well ? >>>>> >>>>> -----Original Message----- >>>>> From: Stephen Colebourne >>>>> Sent: Sunday, September 23, 2018 12:36 PM >>>>> To: core-libs-dev >>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>> should handle offsets >>>>> >>>>> Thanks >>>>> >>>>> Can we change the docs to: >>>>> >>>>>

>>>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC. >>>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary. >>>>> >>>>> thanks >>>>> Stephen >>>>> >>>>> >>>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal wrote: >>>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review : >>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ >>>>>> >>>>>> Thanks, >>>>>> Pallavi Sonal. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Stephen Colebourne >>>>>> Sent: Thursday, September 20, 2018 6:38 PM >>>>>> To: core-libs-dev >>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>>> should handle offsets >>>>>> >>>>>> Thanks for the update. >>>>>> >>>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid. >>>>>> eg. a negative offset at MAX or a positive offset at MIN. >>>>>> >>>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed. >>>>>> >>>>>> thanks >>>>>> Stephen >>>>>> >>>>>> >>>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal wrote: >>>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs. >>>>>>> Here is the updated webrev for review : >>>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ >>>>>>> >>>>>>> Thanks, >>>>>>> Pallavi Sonal >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stephen Colebourne >>>>>>> Sent: Thursday, September 20, 2018 2:50 AM >>>>>>> To: core-libs-dev >>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>>>> should handle offsets >>>>>>> >>>>>>> Thanks for looking at this. >>>>>>> >>>>>>> The proposed fix does not tackle the bug fully. The bug is that >>>>>>> the spec says >>>>>>> >>>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..." >>>>>>> >>>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc. >>>>>>> >>>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId. >>>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that. >>>>>>> >>>>>>> Furthermore, although there are numerous valid ISO-8601 ways of >>>>>>> saying zero, this format uses dashes and colons in the date/time >>>>>>> part, so >>>>>>> ISO-8601 restricts the offset to only those formats that include colons. >>>>>>> >>>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext. >>>>>>> >>>>>>> thanks >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the changes to the following issue: >>>>>>>> >>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The proposed fix is located at: >>>>>>>> >>>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1]. With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Pallavi Sonal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >> -- >> Thanks, Roger >> > From Roger.Riggs at oracle.com Mon Oct 1 15:59:17 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 1 Oct 2018 11:59:17 -0400 Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets In-Reply-To: References: <38b8864c-e283-44f7-a962-aa65fb560b79@default> <871fb443-47c9-4860-815a-5d2064118fbb@default> <65120bb8-af2a-4144-a334-f1057c21fbf6@default> <0b15557a-a158-4f79-be93-d5a18ac950a2@default> <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com> <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default> <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com> <55f0a5e5-4d0b-e647-f581-ae0e1ca94c78@oracle.com> Message-ID: <8302e132-6322-6d68-dbdd-876c4969adc5@oracle.com> Hi, The checkbox for compatibility Kind Behavioral should be checked. (You may need to hit Edit to see it). A simple description of the compatibility risk may help clarify minimal. Something to the effect, that there is no change in formatting behavior and that parsing will now accept a numeric offset. Otherwise, looks fine. Thanks, Roger On 10/01/2018 09:24 AM, Pallavi Sonal wrote: > Hi Naoto, > Here is the CSR for review : > https://bugs.openjdk.java.net/browse/JDK-8211316 > > Thanks, > Pallavi Sonal > > -----Original Message----- > From: Naoto Sato > Sent: Friday, September 28, 2018 9:38 PM > To: Pallavi Sonal ; Roger Riggs ; core-libs-dev > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets > > Hi Pallavi, > > Please file a CSR for this, as this will change the behavior. > > Naoto > > On 9/28/18 8:53 AM, Pallavi Sonal wrote: >> Thanks Roger. I will update it before the commit. >> >> -----Original Message----- >> From: Roger Riggs >> Sent: Friday, September 28, 2018 6:15 PM >> To: Pallavi Sonal ; core-libs-dev >> >> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should >> handle offsets >> >> Hi Pallavi, >> >> Looks fine, >> >> But can you re-wrap the lines with the new links, they got longer than >> 100 chars with the link. >> >> No new webrev is needed. >> >> Thanks, Roger >> >> >> On 9/28/18 8:35 AM, Pallavi Sonal wrote: >>> Thanks Roger and Stephen. Here is the updated webrev with the suggested changes: >>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/ >>> >>> Thanks, >>> Pallavi Sonal >>> >>> -----Original Message----- >>> From: Roger Riggs >>> Sent: Friday, September 28, 2018 12:51 AM >>> To: core-libs-dev >>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should >>> handle offsets >>> >>> Hi Pallavi, >>> >>> I'd suggest using @link for the reference (in both files). >>> It will be easier for the reader to traverse and understand the pattern. >>> >>> DateTimeFormatterBuilder.java: line 836. >>> The trailing "

" should be omitted so the readability of the source is maintained. >>> >>> Otherwise, looks good, >>> >>> Thanks, Roger >>> >>> >>> >>> On 09/27/2018 03:39 AM, Stephen Colebourne wrote: >>>> In DateTimeFormatter you need to qualify the @code part to refer to >>>> DateTimeFormatterBuilder. >>>> Otherwise good. >>>> thanks >>>> Stephen >>>> >>>> >>>> On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal wrote: >>>>> Thanks for the clarification. Here is the updated webrev for review : >>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ >>>>> >>>>> Thanks, >>>>> Pallavi Sonal >>>>> >>>>> -----Original Message----- >>>>> From: Stephen Colebourne >>>>> Sent: Tuesday, September 25, 2018 4:39 PM >>>>> To: core-libs-dev >>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>> should handle offsets >>>>> >>>>> I think it makes sense for both, although I was only considering >>>>> appendInstant() when I wrote it. >>>>> Stephen >>>>> >>>>> >>>>> On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal wrote: >>>>>> Hi Stephen, >>>>>> Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT as well ? >>>>>> >>>>>> -----Original Message----- >>>>>> From: Stephen Colebourne >>>>>> Sent: Sunday, September 23, 2018 12:36 PM >>>>>> To: core-libs-dev >>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>>> should handle offsets >>>>>> >>>>>> Thanks >>>>>> >>>>>> Can we change the docs to: >>>>>> >>>>>>

>>>>>> When formatting, the instant will always be suffixed by 'Z' to indicate UTC. >>>>>> When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary. >>>>>> >>>>>> thanks >>>>>> Stephen >>>>>> >>>>>> >>>>>> On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal wrote: >>>>>>> Thank you Stephen for your inputs. Based on that, here is the updated webrev for review : >>>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ >>>>>>> >>>>>>> Thanks, >>>>>>> Pallavi Sonal. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stephen Colebourne >>>>>>> Sent: Thursday, September 20, 2018 6:38 PM >>>>>>> To: core-libs-dev >>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>>>> should handle offsets >>>>>>> >>>>>>> Thanks for the update. >>>>>>> >>>>>>> The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid. >>>>>>> eg. a negative offset at MAX or a positive offset at MIN. >>>>>>> >>>>>>> The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed. >>>>>>> >>>>>>> thanks >>>>>>> Stephen >>>>>>> >>>>>>> >>>>>>> On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal wrote: >>>>>>>> Thanks Roger , Naoto and Stephen for the review and valuable inputs. >>>>>>>> Here is the updated webrev for review : >>>>>>>> http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Pallavi Sonal >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Stephen Colebourne >>>>>>>> Sent: Thursday, September 20, 2018 2:50 AM >>>>>>>> To: core-libs-dev >>>>>>>> Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT >>>>>>>> should handle offsets >>>>>>>> >>>>>>>> Thanks for looking at this. >>>>>>>> >>>>>>>> The proposed fix does not tackle the bug fully. The bug is that >>>>>>>> the spec says >>>>>>>> >>>>>>>> "The format consists of: The ISO_OFFSET_DATE_TIME where ..." >>>>>>>> >>>>>>>> As such, the format must parse *any* offset, not just "Z" / "+00:00" etc. >>>>>>>> >>>>>>>> In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId. >>>>>>>> Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that. >>>>>>>> >>>>>>>> Furthermore, although there are numerous valid ISO-8601 ways of >>>>>>>> saying zero, this format uses dashes and colons in the date/time >>>>>>>> part, so >>>>>>>> ISO-8601 restricts the offset to only those formats that include colons. >>>>>>>> >>>>>>>> I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext. >>>>>>>> >>>>>>>> thanks >>>>>>>> Stephen >>>>>>>> >>>>>>>> >>>>>>>> On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the changes to the following issue: >>>>>>>>> >>>>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8166138 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The proposed fix is located at: >>>>>>>>> >>>>>>>>> Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1]. With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] https://en.wikipedia.org/wiki/ISO_8601 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Pallavi Sonal >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>> -- >>> Thanks, Roger >>> -- Thanks, Roger From pallavi.sonal at oracle.com Mon Oct 1 16:38:34 2018 From: pallavi.sonal at oracle.com (Pallavi Sonal) Date: Mon, 1 Oct 2018 09:38:34 -0700 (PDT) Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets In-Reply-To: <8302e132-6322-6d68-dbdd-876c4969adc5@oracle.com> References: <38b8864c-e283-44f7-a962-aa65fb560b79@default> <871fb443-47c9-4860-815a-5d2064118fbb@default> <65120bb8-af2a-4144-a334-f1057c21fbf6@default> <0b15557a-a158-4f79-be93-d5a18ac950a2@default> <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com> <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default> <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com> <55f0a5e5-4d0b-e647-f581-ae0e1ca94c78@oracle.com> <8302e132-6322-6d68-dbdd-876c4969adc5@oracle.com> Message-ID: Thanks Roger, made the suggested changes. ? Thanks, Pallavi Sonal ? From: Roger Riggs Sent: Monday, October 01, 2018 9:29 PM To: Pallavi Sonal ; Naoto Sato ; core-libs-dev Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Hi, The checkbox for compatibility Kind Behavioral should be checked. (You may need to hit Edit to see it). A simple description of the compatibility risk may help clarify minimal. Something to the effect, that there is no change in formatting behavior and that parsing will now accept a numeric offset. Otherwise, looks fine. Thanks, Roger On 10/01/2018 09:24 AM, Pallavi Sonal wrote: Hi Naoto, Here is the CSR for review : https://bugs.openjdk.java.net/browse/JDK-8211316 ? Thanks, Pallavi Sonal ? -----Original Message----- From: Naoto Sato Sent: Friday, September 28, 2018 9:38 PM To: Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com"; Roger Riggs HYPERLINK "mailto:roger.riggs at oracle.com"; core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Hi Pallavi, ? Please file a CSR for this, as this will change the behavior. ? Naoto ? On 9/28/18 8:53 AM, Pallavi Sonal wrote: Thanks Roger. I will update it before the commit. ? -----Original Message----- From: Roger Riggs Sent: Friday, September 28, 2018 6:15 PM To: Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com"; core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Hi Pallavi, ? Looks fine, ? But can you re-wrap the lines with the new links, they got longer than 100 chars with the link. ? No new webrev is needed. ? Thanks, Roger ? ? On 9/28/18 8:35 AM, Pallavi Sonal wrote: Thanks Roger and Stephen. Here is the updated webrev with the suggested changes: http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/ ? Thanks, Pallavi Sonal ? -----Original Message----- From: Roger Riggs Sent: Friday, September 28, 2018 12:51 AM To: core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Hi Pallavi, ? I'd suggest using @link for the reference (in both files). It will be easier for the reader to traverse and understand the pattern. ? DateTimeFormatterBuilder.java: line 836. The trailing "

" should be omitted so the readability of the source is maintained. ? Otherwise, looks good, ? Thanks, Roger ? ? ? On 09/27/2018 03:39 AM, Stephen Colebourne wrote: In DateTimeFormatter you need to qualify the @code part to refer to DateTimeFormatterBuilder. Otherwise good. thanks Stephen ? ? On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com" wrote: Thanks for the clarification. Here is the updated webrev for review : http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ ? Thanks, Pallavi Sonal ? -----Original Message----- From: Stephen Colebourne HYPERLINK "mailto:scolebourne at joda.org" Sent: Tuesday, September 25, 2018 4:39 PM To: core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? I think it makes sense for both, although I was only considering appendInstant() when I wrote it. Stephen ? ? On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com" wrote: Hi Stephen, Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT? as well ? ? -----Original Message----- From: Stephen Colebourne HYPERLINK "mailto:scolebourne at joda.org" Sent: Sunday, September 23, 2018 12:36 PM To: core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Thanks ? Can we change the docs to: ?

When formatting, the instant will always be suffixed by 'Z' to indicate UTC. When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary. ? thanks Stephen ? ? On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com" wrote: Thank you Stephen for your inputs. Based on that, here is the updated webrev for review : ???? http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ ? Thanks, Pallavi Sonal. ? -----Original Message----- From: Stephen Colebourne HYPERLINK "mailto:scolebourne at joda.org" Sent: Thursday, September 20, 2018 6:38 PM To: core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Thanks for the update. ? The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid. eg. a negative offset at MAX or a positive offset at MIN. ? The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed. ? thanks Stephen ? ? On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com" wrote: Thanks Roger , Naoto and Stephen for the review and valuable inputs. Here is the updated webrev for review : http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ ? Thanks, Pallavi Sonal ? -----Original Message----- From: Stephen Colebourne HYPERLINK "mailto:scolebourne at joda.org" Sent: Thursday, September 20, 2018 2:50 AM To: core-libs-dev HYPERLINK "mailto:core-libs-dev at openjdk.java.net" Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets ? Thanks for looking at this. ? The proposed fix does not tackle the bug fully. The bug is that the spec says ? "The format consists of: The ISO_OFFSET_DATE_TIME where ..." ? As such, the format must parse *any* offset, not just "Z" / "+00:00" etc. ? In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId. Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that. ? Furthermore, although there are numerous valid ISO-8601 ways of saying zero, this format uses dashes and colons in the date/time part, so ISO-8601 restricts the offset to only those formats that include colons. ? I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext. ? thanks Stephen ? ? On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal HYPERLINK "mailto:pallavi.sonal at oracle.com" wrote: Hi, ? Please review the changes to the following issue: ? Bug : https://bugs.openjdk.java.net/browse/JDK-8166138 ? ? ? The proposed fix is located at: ? Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/ ? ? ? As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].? With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed. ? ? ? [1] https://en.wikipedia.org/wiki/ISO_8601 ? ? ? Thanks, ? Pallavi Sonal ? ? ? ? -- Thanks, Roger ? ? -- Thanks, Roger From mandy.chung at oracle.com Mon Oct 1 17:09:07 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 Oct 2018 10:09:07 -0700 Subject: RFR 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl In-Reply-To: References: Message-ID: <1f243591-31cc-de91-d3e1-333f8532386e@oracle.com> On 9/29/18 1:59 PM, Lance Andersen wrote: > Attached is the webrev for the JDBC RowSet/DriverManager issue, https://bugs.openjdk.java.net/browse/JDK-8211295, that was raised on the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.html > > I have run the JDBC TestSuite against the Derby Embedded and Derby Network server; Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK java.sql and javax.sql tests. All pass with the fix > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8211295/webrev.00/ The change looks okay.??? DriverManager::drivers and a few other methods are caller-sensitive.? If they were called from java.sql.rowset, it won't work properly.?? I believe no such code path and so it's okay. We should try again to investigate removing @CallerSensitive from DriverManager in the future: ?? https://bugs.openjdk.java.net/browse/JDK-8154346 Mandy From naoto.sato at oracle.com Mon Oct 1 17:22:40 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 1 Oct 2018 10:22:40 -0700 Subject: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets In-Reply-To: References: <38b8864c-e283-44f7-a962-aa65fb560b79@default> <871fb443-47c9-4860-815a-5d2064118fbb@default> <65120bb8-af2a-4144-a334-f1057c21fbf6@default> <0b15557a-a158-4f79-be93-d5a18ac950a2@default> <575686a1-d037-e37b-5b22-c3ea3b5050ad@oracle.com> <0f9dab1a-21d6-42a0-832a-9a0a1649db34@default> <01c3a590-de01-4877-3ba7-b0958ae8459c@oracle.com> <55f0a5e5-4d0b-e647-f581-ae0e1ca94c78@oracle.com> <8302e132-6322-6d68-dbdd-876c4969adc5@oracle.com> Message-ID: +1. Added myself as a reviewer of the CSR. Thanks for working on this. Naoto On 10/1/18 9:38 AM, Pallavi Sonal wrote: > Thanks Roger, made the suggested changes. > > Thanks, > > Pallavi Sonal > > *From:*Roger Riggs > *Sent:* Monday, October 01, 2018 9:29 PM > *To:* Pallavi Sonal ; Naoto Sato > ; core-libs-dev > *Subject:* Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should > handle offsets > > Hi, > > The checkbox for compatibility Kind Behavioral should be checked. (You > may need to hit Edit to see it). > A simple description of the compatibility risk may help clarify minimal. > Something to the effect, that there is no change in formatting behavior > and that parsing will now accept a numeric offset. > > Otherwise, looks fine. > > Thanks, Roger > > On 10/01/2018 09:24 AM, Pallavi Sonal wrote: > > Hi Naoto, > > Here is the CSR for review : > > https://bugs.openjdk.java.net/browse/JDK-8211316 > > Thanks, > > Pallavi Sonal > > -----Original Message----- > > From: Naoto Sato > > Sent: Friday, September 28, 2018 9:38 PM > > To: Pallavi Sonal ; Roger Riggs ; core-libs-dev > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets > > Hi Pallavi, > > Please file a CSR for this, as this will change the behavior. > > Naoto > > On 9/28/18 8:53 AM, Pallavi Sonal wrote: > > Thanks Roger. I will update it before the commit. > > -----Original Message----- > > From: Roger Riggs > > Sent: Friday, September 28, 2018 6:15 PM > > To: Pallavi Sonal ; core-libs-dev > > > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should > > handle offsets > > Hi Pallavi, > > Looks fine, > > But can you re-wrap the lines with the new links, they got longer than > > 100 chars with the link. > > No new webrev is needed. > > Thanks, Roger > > On 9/28/18 8:35 AM, Pallavi Sonal wrote: > > Thanks Roger and Stephen. Here is the updated webrev with the suggested changes: > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.04/ > > > Thanks, > > Pallavi Sonal > > -----Original Message----- > > From: Roger Riggs > > Sent: Friday, September 28, 2018 12:51 AM > > To: core-libs-dev > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should > > handle offsets > > Hi Pallavi, > > I'd suggest using @link for the reference (in both files). > > It will be easier for the reader to traverse and understand the pattern. > > DateTimeFormatterBuilder.java: line 836. > > The trailing "

" should be omitted so the readability of the source is maintained. > > Otherwise, looks good, > > Thanks, Roger > > On 09/27/2018 03:39 AM, Stephen Colebourne wrote: > > In DateTimeFormatter you need to qualify the @code part to refer to > > DateTimeFormatterBuilder. > > Otherwise good. > > thanks > > Stephen > > On Thu, 27 Sep 2018 at 05:35, Pallavi Sonal wrote: > > Thanks for the clarification. Here is the updated webrev for review : > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.03/ > > Thanks, > > Pallavi Sonal > > -----Original Message----- > > From: Stephen Colebourne > > Sent: Tuesday, September 25, 2018 4:39 PM > > To: core-libs-dev > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT > > should handle offsets > > I think it makes sense for both, although I was only considering > > appendInstant() when I wrote it. > > Stephen > > On Tue, 25 Sep 2018 at 09:27, Pallavi Sonal > wrote: > > Hi Stephen, > > Is the addition to the documentation in your mail below meant for only appendInstant() method or for DateTimeFormatter.ISO_INSTANT? as well ? > > -----Original Message----- > > From: Stephen Colebourne > > Sent: Sunday, September 23, 2018 12:36 PM > > To: core-libs-dev > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT > > should handle offsets > > Thanks > > Can we change the docs to: > >

> > When formatting, the instant will always be suffixed by 'Z' to indicate UTC. > > When parsing, the behaviour of {@code appendOffsetId()} will be used to parse the offset, converting the instant to UTC as necessary. > > thanks > > Stephen > > On Fri, 21 Sep 2018 at 13:26, Pallavi Sonal > wrote: > > Thank you Stephen for your inputs. Based on that, here is the updated webrev for review : > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.02/ > > > Thanks, > > Pallavi Sonal. > > -----Original Message----- > > From: Stephen Colebourne > > > Sent: Thursday, September 20, 2018 6:38 PM > > To: core-libs-dev > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT > > should handle offsets > > Thanks for the update. > > The test case does not cover the situation of MAX/MIN instant and an offset other than zero, where the offset makes the instant invalid. > > eg. a negative offset at MAX or a positive offset at MIN. > > The doc of appendInstant() in DateTimeFormatterBuilder should be clarified to cover the fact that any OffsetId is parsed. > > thanks > > Stephen > > On Thu, 20 Sep 2018 at 13:54, Pallavi Sonal > wrote: > > Thanks Roger , Naoto and Stephen for the review and valuable inputs. > > Here is the updated webrev for review : > > http://cr.openjdk.java.net/~rpatil/8166138/webrev.01/ > > > Thanks, > > Pallavi Sonal > > -----Original Message----- > > From: Stephen Colebourne > > > Sent: Thursday, September 20, 2018 2:50 AM > > To: core-libs-dev > > > Subject: Re: RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT > > should handle offsets > > Thanks for looking at this. > > The proposed fix does not tackle the bug fully. The bug is that > > the spec says > > "The format consists of: The ISO_OFFSET_DATE_TIME where ..." > > As such, the format must parse *any* offset, not just "Z" / "+00:00" etc. > > In addition, the fix doesn't work properly. Parsers work off a CharSequence which may be much longer than the instant. For example, the instant might be followed by a literal space and then a ZoneId. > > Using (length - 3) is simply not a valid approach - the parsing code cannot use the length like that. > > Furthermore, although there are numerous valid ISO-8601 ways of > > saying zero, this format uses dashes and colons in the date/time > > part, so > > ISO-8601 restricts the offset to only those formats that include colons. > > I think it simply needs the appendLiteral(Z) changing to appendOffsetId() And line 3495 changes to use the offset from the newContext. > > thanks > > Stephen > > On Wed, 19 Sep 2018 at 18:16, Pallavi Sonal > wrote: > > Hi, > > Please review the changes to the following issue: > > Bug :https://bugs.openjdk.java.net/browse/JDK-8166138 > > The proposed fix is located at: > > Webrev :http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/ > > > As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1].? With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed. > > [1]https://en.wikipedia.org/wiki/ISO_8601 > > Thanks, > > Pallavi Sonal > > -- > > Thanks, Roger > > > > -- > > Thanks, Roger > From martinrb at google.com Mon Oct 1 17:35:32 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 1 Oct 2018 10:35:32 -0700 Subject: Optimized HashSet.toArray() In-Reply-To: References: Message-ID: Thanks, Tagir. I agree these optimizations are worth doing. I have worked on similar toArray methods in other Collection implementations. I have a benchmark that is also a correctness test Collection/IteratorMicroBenchmark.java but I never added any Set implementations since I intentionally want to test duplicates and we'd have to special-case Sets somehow. We probably want to check in the jmh benchmark, but not sure where - there have been recent discussions ... """Reviving JEP 230: Microbenchmark Suite""" On Sun, Sep 30, 2018 at 10:03 PM, Tagir Valeev wrote: > Hello! > > I think that HashSet.toArray(), HashMap.keySet().toArray() and > HashMap.values().toArray() methods are used often enough to deserve a > dedicated optimized implementation. Here's the patch I propose which > is based on KeySet#forEach and AbstractCollection#toArray > implementations: > http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/patch.txt > > I performed quick JMH test for HashSet.toArray(). The source code is here: > http://cr.openjdk.java.net/~tvaleev/patches/hashset_ > toarray/jmh/ToArray.java > > Result on JDK 11+28 is here: > http://cr.openjdk.java.net/~tvaleev/patches/hashset_ > toarray/jmh/jmh_toArray_11.txt > > Result on JDK 11+28 with patch applied is here > http://cr.openjdk.java.net/~tvaleev/patches/hashset_ > toarray/jmh/jmh_toArray_11_patched.txt > > Summary (non-patched): > Benchmark (size) Score Error Units > ToArray.toArray 0 6,327 ? 0,094 ns/op > ToArray.toArray 1 55,040 ? 0,389 ns/op > ToArray.toArray 10 112,903 ? 3,571 ns/op > ToArray.toArray 1000 11281,875 ? 74,423 ns/op > ToArray.toArray 100000 2795345,640 ? 57164,196 ns/op > ToArray.toArray 10000000 443763064,267 ? 82551994,563 ns/op > ToArray.toArrayPresized 0 8,244 ? 0,054 ns/op > ToArray.toArrayPresized 1 57,094 ? 0,431 ns/op > ToArray.toArrayPresized 10 105,456 ? 3,831 ns/op > ToArray.toArrayPresized 1000 11935,895 ? 251,150 ns/op > ToArray.toArrayPresized 100000 2771938,363 ? 42917,423 ns/op > ToArray.toArrayPresized 10000000 421335484,317 ? 66222482,723 ns/op > ToArray.toObjectArray 0 8,288 ? 0,060 ns/op > ToArray.toObjectArray 1 49,415 ? 2,454 ns/op > ToArray.toObjectArray 10 94,243 ? 2,346 ns/op > ToArray.toObjectArray 1000 10061,125 ? 77,197 ns/op > ToArray.toObjectArray 100000 2455011,037 ? 86539,734 ns/op > ToArray.toObjectArray 10000000 416595706,650 ? 84619961,188 ns/op > > Summary (patched): > Benchmark (size) Score Error Units > ToArray.toArray 0 5,319 ? 0,050 ns/op > ToArray.toArray 1 22,235 ? 0,365 ns/op > ToArray.toArray 10 57,515 ? 0,687 ns/op > ToArray.toArray 1000 6586,112 ? 71,258 ns/op > ToArray.toArray 100000 1700754,903 ? 41289,676 ns/op > ToArray.toArray 10000000 299815797,250 ? 37778823,759 ns/op > ToArray.toArrayPresized 0 6,689 ? 0,042 ns/op > ToArray.toArrayPresized 1 44,852 ? 0,813 ns/op > ToArray.toArrayPresized 10 66,904 ? 0,748 ns/op > ToArray.toArrayPresized 1000 7839,880 ? 75,954 ns/op > ToArray.toArrayPresized 100000 1605381,429 ? 55070,143 ns/op > ToArray.toArrayPresized 10000000 292954965,933 ? 45912224,761 ns/op > ToArray.toObjectArray 0 6,608 ? 0,049 ns/op > ToArray.toObjectArray 1 28,085 ? 0,326 ns/op > ToArray.toObjectArray 10 58,170 ? 2,716 ns/op > ToArray.toObjectArray 1000 5979,407 ? 55,930 ns/op > ToArray.toObjectArray 100000 1420318,139 ? 27226,724 ns/op > ToArray.toObjectArray 10000000 255417541,372 ? 33366555,142 ns/op > > As you can see, the patched version is always faster, sometimes 2x and > even more. Also it doesn't allocate anything except the target array > when necessary (current version allocates an iterator). > > If anybody is interested to sponsor this change, I can log a JBS issue > and provide proper webrev for review. Do we need to add new unit-tests > or these methods are covered enough by existing tests? > > With best regards, > Tagir Valeev. > From martinrb at google.com Mon Oct 1 17:46:59 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 1 Oct 2018 10:46:59 -0700 Subject: Convert old-style array declarations (was: Re: ByteArrayOutputStream should not have a new writeBytes method in Java) In-Reply-To: References: <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com> Message-ID: Thank you very much for working on these cleanups. I've occasionally done similar in the past. I've made big changesets with only one automated change at a time. So e.g. I would do only "C-style array declaration" in one changeset. This is one example of a change that should leave zero impact on the generated bytecode, and that should be testable, if only by comparing the .class files for identical size. One difficulty is that the copy of the source code in openjdk may not be the "master" copy - it may be imported from some other project, and in general it's hard to tell. On Sun, Sep 30, 2018 at 8:40 PM, Tagir Valeev wrote: > Hello! > > Ok, let's start with smaller thing which is java.desktop. Created a > JBS issue and posted a patch here: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-October/009486.html > > Jonathan, > > > Although cleanup like this is nice, I'll give a word of warning that > pervasive > > changes like that can sometimes cause difficulties when there are lots of > > changes in code which is undergoing different lines of development in > different > > branches or repos. If nothing else, I'd consider doing it on a > per-component > > or per-module basis. > > I'm not sure I have enough time to post 70+ reviews for every module > and track all of them. My volunteering abilities are quite limited :-) > I think I can manage up to 3-4 separate changesets including already > posted java.desktop change. If you have suggestions on how to split > this to several big parts, you are welcome (I don't know how > "components" are mapped to modules, probably components are big > enough?). Or probably we can cover only part of modules for now and > wait for the next volunteer to pick up this. > > With best regards, > Tagir Valeev. > > > On Sat, Sep 29, 2018 at 5:41 AM Sergey Bylokhov > wrote: > > > > I can review the changes in java.desktop, please use these email alias > > awt-dev/2d-dev/swing-dev. > > > > On 28/09/2018 04:13, Alan Bateman wrote: > > > As regards doing the entire source base then I think that would be > good. > > > Due to the complexity of testing, changes to the java.desktop module > are > > > pushed to jdk/client repo rather than jdk/jdk so if it's not too > awkward > > > then it might be helper if the patch for java.desktop were a separate > > > change that gets pushed to jdk/client rather than jdk/jdk. > > > > > > -- > > Best regards, Sergey. > From lance.andersen at oracle.com Mon Oct 1 20:19:51 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 1 Oct 2018 16:19:51 -0400 Subject: RFR 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl In-Reply-To: <1f243591-31cc-de91-d3e1-333f8532386e@oracle.com> References: <1f243591-31cc-de91-d3e1-333f8532386e@oracle.com> Message-ID: <8D3C482C-D2E7-4F4B-9BDC-D194682215B0@oracle.com> > On Oct 1, 2018, at 1:09 PM, Mandy Chung wrote: > > > > On 9/29/18 1:59 PM, Lance Andersen wrote: >> Attached is the webrev for the JDBC RowSet/DriverManager issue, https://bugs.openjdk.java.net/browse/JDK-8211295 , that was raised on the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.html >> >> I have run the JDBC TestSuite against the Derby Embedded and Derby Network server; Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK java.sql and javax.sql tests. All pass with the fix >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8211295/webrev.00/ > > The change looks okay. DriverManager::drivers and a few other methods are caller-sensitive. If they were called from java.sql.rowset, it won't work properly. I believe no such code path and so it's okay. That is correct, only DriverManager::getConnection is called > > We should try again to investigate removing @CallerSensitive from DriverManager in the future: > https://bugs.openjdk.java.net/browse/JDK-8154346 OK, let the fun times begin ;-) > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Mon Oct 1 21:31:22 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Oct 2018 14:31:22 -0700 Subject: 8152910: Get performance improvement with Stable annotation Message-ID: <1D0F24A9-8A24-42B9-9226-3520EB1B063C@oracle.com> Please review at your convenience: https://bugs.openjdk.java.net/browse/JDK-8152910 JMH benchmarks do show a slight but measurable performance improvement with the below patch applied. Thanks, Brian --- a/src/java.base/share/classes/java/math/BigInteger.java +++ b/src/java.base/share/classes/java/math/BigInteger.java @@ -41,6 +41,7 @@ import jdk.internal.math.DoubleConsts; import jdk.internal.math.FloatConsts; import jdk.internal.HotSpotIntrinsicCandidate; +import jdk.internal.vm.annotation.Stable; /** * Immutable arbitrary-precision integers. All operations behave as if @@ -1219,8 +1220,10 @@ * Initialize static constant array when class is loaded. */ private static final int MAX_CONSTANT = 16; - private static BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; - private static BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; + @Stable + private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; + @Stable + private static final BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; From brian.burkhalter at oracle.com Mon Oct 1 21:44:04 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Oct 2018 14:44:04 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes Message-ID: https://bugs.openjdk.java.net/browse/JDK-6516099 http://cr.openjdk.java.net/~bpb/6516099/webrev.00/ This patch implements a method InputStream.skipNBytes() instead of skipFully() based on the supposition that this name is less likely to conflict with existing subclasses, e.g., [1]. There is some inconsistency however with respect to the description of the method readNBytes() [2], which may return fewer than N bytes if end of stream is reached first. If we converge on a solution in this thread I?ll file a CSR. Thanks, Brian [1] https://developer.ibm.com/static/site-id/155/maximodev/7609/maximocore/businessobjects/psdi/iface/webservices/action/bytecode/ClassReader.html [2] https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/io/InputStream.html#readNBytes(byte[],int,int) From forax at univ-mlv.fr Mon Oct 1 21:46:11 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 1 Oct 2018 23:46:11 +0200 (CEST) Subject: 8152910: Get performance improvement with Stable annotation In-Reply-To: <1D0F24A9-8A24-42B9-9226-3520EB1B063C@oracle.com> References: <1D0F24A9-8A24-42B9-9226-3520EB1B063C@oracle.com> Message-ID: <94224291.5834.1538430371959.JavaMail.zimbra@u-pem.fr> Hi Brian, can you move the [] to the right place at the same time, to use the java syntax not the C one. i.e. @Stable private static final BigInteger[] posConst = new BigInteger[MAX_CONSTANT+1]; instead of @Stable private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; cheers, R?mi ----- Mail original ----- > De: "Brian Burkhalter" > ?: "core-libs-dev" > Envoy?: Lundi 1 Octobre 2018 23:31:22 > Objet: 8152910: Get performance improvement with Stable annotation > Please review at your convenience: > > https://bugs.openjdk.java.net/browse/JDK-8152910 > > JMH benchmarks do show a slight but measurable performance improvement with the > below patch applied. > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/math/BigInteger.java > +++ b/src/java.base/share/classes/java/math/BigInteger.java > @@ -41,6 +41,7 @@ > import jdk.internal.math.DoubleConsts; > import jdk.internal.math.FloatConsts; > import jdk.internal.HotSpotIntrinsicCandidate; > +import jdk.internal.vm.annotation.Stable; > > /** > * Immutable arbitrary-precision integers. All operations behave as if > @@ -1219,8 +1220,10 @@ > * Initialize static constant array when class is loaded. > */ > private static final int MAX_CONSTANT = 16; > - private static BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; > - private static BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; > + @Stable > + private static final BigInteger posConst[] = new > BigInteger[MAX_CONSTANT+1]; > + @Stable > + private static final BigInteger negConst[] = new > BigInteger[MAX_CONSTANT+1]; From brian.burkhalter at oracle.com Mon Oct 1 21:48:26 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 1 Oct 2018 14:48:26 -0700 Subject: 8152910: Get performance improvement with Stable annotation In-Reply-To: <94224291.5834.1538430371959.JavaMail.zimbra@u-pem.fr> References: <1D0F24A9-8A24-42B9-9226-3520EB1B063C@oracle.com> <94224291.5834.1538430371959.JavaMail.zimbra@u-pem.fr> Message-ID: <5CA3DCE5-FFBD-4649-889D-900E5D17E842@oracle.com> Hi R?mi, You?re right: that was stupid, especially given the work currently being done for https://bugs.openjdk.java.net/browse/JDK-8211300. Will change. Thanks, Brian On Oct 1, 2018, at 2:46 PM, Remi Forax wrote: > can you move the [] to the right place at the same time, to use the java syntax not the C one. > i.e. > @Stable > private static final BigInteger[] posConst = new BigInteger[MAX_CONSTANT+1]; > instead of > @Stable > private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; From igor.ignatyev at oracle.com Mon Oct 1 23:18:15 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 1 Oct 2018 16:18:15 -0700 Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary In-Reply-To: References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com> <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com> Message-ID: Hi Alan, thanks for your review! -- Igor > On Sep 30, 2018, at 8:00 AM, Alan Bateman wrote: > > On 27/09/2018 00:38, Igor Ignatyev wrote: >> here is the webrevs w/ JarUtils from default package inserted into jdk.test.lib.util.JarUtils: >> whole patch: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html >>> 655 lines changed: 239 ins; 355 del; 61 mod; >> incremental: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html >>> 476 lines changed: 239 ins; 203 del; 34 mod; >> >> doing that, I noticed that both updateJarFile and createJarFile don't close Stream from Files::find, the current patch fixes that. >> > I see you've also deprecated the String methods in the old class - good! I'd probably carry over test/jdk/lib/testlibrary/JarUtils.java without changing the format but your IDE must be setup differently and it will get changed again by whoever next changes it so I think it's okay. > > The update to tests using this look fine. > > -Alan From ivan.gerasimov at oracle.com Mon Oct 1 23:37:51 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 1 Oct 2018 16:37:51 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike Message-ID: Hello! A handful of a few similar typos across core-libs/security-libs areas. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ Would you please help review the fix? -- With kind regards, Ivan Gerasimov From lance.andersen at oracle.com Mon Oct 1 23:43:35 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 1 Oct 2018 19:43:35 -0400 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: References: Message-ID: <77361AB4-670F-4284-A32E-E5A106BACDAC@oracle.com> The changes look reasonable Ivan > On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov wrote: > > Hello! > > A handful of a few similar typos across core-libs/security-libs areas. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ > > Would you please help review the fix? > > -- > With kind regards, > Ivan Gerasimov > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From bradford.wetmore at oracle.com Mon Oct 1 23:58:55 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 1 Oct 2018 16:58:55 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: References: Message-ID: <2032e61f-4a63-3a51-80a6-eb8e77791b7c@oracle.com> I checked the last 6 only (SSLEngine+). Looks good. Brad On 10/1/2018 4:37 PM, Ivan Gerasimov wrote: > Hello! > > A handful of a few similar typos across core-libs/security-libs areas. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 > WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ > > Would you please help review the fix? > From prasadarao.koppula at oracle.com Tue Oct 2 01:09:00 2018 From: prasadarao.koppula at oracle.com (Prasadrao Koppula) Date: Mon, 1 Oct 2018 18:09:00 -0700 (PDT) Subject: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181 Message-ID: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> Hi, Could you please review this patch. This patch fixes the regression caused by LDAP fixes in JDK11, JDK8u181, JDK7u191 Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ Issue: https://bugs.openjdk.java.net/browse/JDK-8211107 Thanks, Prasad.K From joe.darcy at oracle.com Tue Oct 2 01:41:35 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 1 Oct 2018 18:41:35 -0700 Subject: RFR (XS) 8200381 : Typos in javadoc - missing verb "be" and alike In-Reply-To: <77361AB4-670F-4284-A32E-E5A106BACDAC@oracle.com> References: <77361AB4-670F-4284-A32E-E5A106BACDAC@oracle.com> Message-ID: <8fefa7f9-e6c1-fc4b-3c78-56ecfe787090@oracle.com> Changes look fine; thanks, -Joe On 10/1/2018 4:43 PM, Lance Andersen wrote: > The changes look reasonable Ivan > >> On Oct 1, 2018, at 7:37 PM, Ivan Gerasimov wrote: >> >> Hello! >> >> A handful of a few similar typos across core-libs/security-libs areas. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8200381 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8200381/00/webrev/ >> >> Would you please help review the fix? >> >> -- >> With kind regards, >> Ivan Gerasimov >> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From vyom.tewari at oracle.com Tue Oct 2 03:48:21 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 2 Oct 2018 09:18:21 +0530 Subject: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181 In-Reply-To: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> References: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> Message-ID: <809026de-f31d-0e89-6ec0-def6eb81c8d7@oracle.com> Hi Prasad, Change looks good to me, can you please put some comment why we are not performing "ssl handshake" if connectTime <= 0. This will help future maintainer of this code. Thanks, Vyom On Tuesday 02 October 2018 06:39 AM, Prasadrao Koppula wrote: > Hi, > > > > Could you please review this patch. This patch fixes the regression caused by LDAP fixes in JDK11, JDK8u181, JDK7u191 > > > > Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211107 > > > > > > Thanks, > > Prasad.K > > From mikael.vidstedt at oracle.com Tue Oct 2 07:21:13 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 2 Oct 2018 00:21:13 -0700 Subject: RFR(S): 8211350: Remove jprt support Message-ID: Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. bug: https://bugs.openjdk.java.net/browse/JDK-8211350 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ * Background (from the issue) The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. * About the change The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: build-dev: make related files, jprt.* hotspot-dev: {src,test}/hotspot core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid Of course I?d welcome reviews across those mappings as well. * Testing tier1 (passed), tier2-3 still running (looking good so far). Cheers, Mikael From sean.coffey at oracle.com Tue Oct 2 07:23:16 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Oct 2018 08:23:16 +0100 Subject: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181 In-Reply-To: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> References: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> Message-ID: Correction looks good to me. regards, Sean. On 02/10/2018 02:09, Prasadrao Koppula wrote: > Hi, > > > > Could you please review this patch. This patch fixes the regression caused by LDAP fixes in JDK11, JDK8u181, JDK7u191 > > > > Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211107 > > > > > > Thanks, > > Prasad.K > > From david.holmes at oracle.com Tue Oct 2 07:44:05 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Oct 2018 17:44:05 +1000 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: Hi Mikael, This all looks fine to me. Thanks for cleaning it up! David On 2/10/2018 5:21 PM, Mikael Vidstedt wrote: > > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > > * Background (from the issue) > > The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. > > > * About the change > > The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: > > build-dev: make related files, jprt.* > hotspot-dev: {src,test}/hotspot > core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid > > Of course I?d welcome reviews across those mappings as well. > > * Testing > > tier1 (passed), tier2-3 still running (looking good so far). > > Cheers, > Mikael > From chris.hegarty at oracle.com Tue Oct 2 07:54:52 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 2 Oct 2018 08:54:52 +0100 Subject: RFR[12] JDK-8211107: LDAPS communication failure with jdk 1.8.0_181 In-Reply-To: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> References: <5744098e-f2f3-4ecf-a130-141ab55b60db@default> Message-ID: <609E6614-4B35-42A5-AC79-27A6780E5C02@oracle.com> > On 2 Oct 2018, at 02:09, Prasadrao Koppula wrote: > > .. > Webrev: http://cr.openjdk.java.net/~pkoppula/8211107/webrev.01/ Looks good. -Chris. From Alan.Bateman at oracle.com Tue Oct 2 08:34:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Oct 2018 09:34:31 +0100 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: On 02/10/2018 08:21, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > Does the change to Helper.java and tests that use it break testing of exploded builds? I don't know why it has the comment "JPRT not yet ready" but whether $JAVA_HOME/jmods exists or not isn't connected to JPRT or any build or test system. -Alan From takiguc at linux.vnet.ibm.com Tue Oct 2 09:21:50 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 02 Oct 2018 18:21:50 +0900 Subject: RFR: 8211382 ISO2022JP and GB18030 NIO converter issues Message-ID: Hello, IBM would like to contribute NIO converter patch to OpenJDK project. Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211382 Change: https://cr.openjdk.java.net/~itakiguchi/8211382/webrev.00/ Issue: ISO2022JP decoder and GB18030 decoder (for decodeBufferLoop()) have code range definition issues. ISO2022JP, 0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, 0x42, is converted to \uFFA0 ISO2022JP is for Japanese, but \uFFA0 is a part of Korean Hangul character. GB18030, \uFFFE is converted to 0x84, 0x31, 0xA4, 0x38. 0x84, 0x31, 0xA4, 0x38 is converted to replacement character \uFFFD. $ java Test1 \uFFA0 \uFFFD Expected result $ java Test1 \uFFFD \uFFFE Testcase is as follows: ======================== $ cat Test1.java import java.nio.*; import java.nio.charset.*; public class Test1 { ? public static void main(String[] args) throws Exception { ??? { ????? byte[] ba = new byte[] {0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, 0x42,}; ????? for(char ch : (new String(ba, "ISO2022JP")).toCharArray()) { ??????? System.out.printf("\\u%04X",(int)ch); ????? } ????? System.out.println(); ??? } ??? { ????? Charset cs = Charset.forName("GB18030"); ????? CharsetDecoder cd = cs.newDecoder(); ????? cd.onMalformedInput(CodingErrorAction.REPLACE) ??????? .onUnmappableCharacter(CodingErrorAction.REPLACE); ????? byte[] ba = "\uFFFE".getBytes(cs); ????? ByteBuffer bb = ByteBuffer.allocateDirect(ba.length); ????? bb.put(ByteBuffer.wrap(ba)); ????? bb.position(0); ????? CharBuffer cb = cd.decode(bb); ????? for(int i=0; i References: Message-ID: <3b27a611-3a53-af1e-aa08-4bd81ecdceff@oracle.com> On 2/10/2018 6:34 PM, Alan Bateman wrote: > On 02/10/2018 08:21, Mikael Vidstedt wrote: >> Please review this change which removes support for, and references >> to, the (Oracle internal) JPRT system. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >> webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >> > Does the change to Helper.java and tests that use it break testing of > exploded builds? I don't know why it has the comment "JPRT not yet > ready" but whether $JAVA_HOME/jmods exists or not isn't connected to > JPRT or any build or test system. Yes it will break as now an exception will be thrown instead of just cleanly exiting with an error message. I think the Helper changes can be left as-is, just update the comment. David > -Alan From claes.redestad at oracle.com Tue Oct 2 10:01:10 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 2 Oct 2018 12:01:10 +0200 Subject: Optimized HashSet.toArray() In-Reply-To: References: Message-ID: <45a58d58-f97f-c86d-75a2-41d8ae914a60@oracle.com> Hi, On 2018-10-01 19:35, Martin Buchholz wrote: > We probably want to check in the jmh benchmark, but not sure where - there > have been recent discussions ... """Reviving JEP 230: Microbenchmark > Suite""" we have a prototype up and running in the sandbox[1] and I hope to move forward with the JEP shortly. I guess we could accept contributions and fold them in there, but it's all subject to change. /Claes [1] http://hg.openjdk.java.net/jdk/sandbox JEP-230-microbenchmarks-branch From matthias.baesken at sap.com Tue Oct 2 13:01:06 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 2 Oct 2018 13:01:06 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 Message-ID: Hello, please review change 8211106 . It updates the Windows OS detection code to recognize Windows Server 2019 . For this we have to look at the build number (dwBuildNumber of OSVERSIONINFOEX), https://docs.microsoft.com/en-us/windows/desktop/api/Winnt/ns-winnt-_osversioninfoexa because dwMajorVersion and dwMinorVersion are the same for Windows server 2016 and 2019 . The build number used to compare ( 17677 ) is for Windows Server 2019 preview , most likely the final version will have a higher build number but this is fine for the coding . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8211106 http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ Thanks, Matthias From bob.vandette at oracle.com Tue Oct 2 14:09:18 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 2 Oct 2018 10:09:18 -0400 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: Message-ID: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Matthias, We don?t usually add logic to the JDK related to unreleased operating system previews. Has the ReleaseID been updated on the system you are testing on? This is the documented way of determining the OS version you are running on? The latest preview release is build 17744. Are you testing on that release? https://techcommunity.microsoft.com/t5/Windows-Server-Insiders/Windows-Server-2019-version-info/td-p/234472 Bob. > On Oct 2, 2018, at 9:01 AM, Baesken, Matthias wrote: > > Hello, please review change 8211106 . > > It updates the Windows OS detection code to recognize Windows Server 2019 . > > For this we have to look at the build number (dwBuildNumber of OSVERSIONINFOEX), > > https://docs.microsoft.com/en-us/windows/desktop/api/Winnt/ns-winnt-_osversioninfoexa > > > because dwMajorVersion and dwMinorVersion are the same for Windows server 2016 and 2019 . > > The build number used to compare ( 17677 ) is for Windows Server 2019 preview , most likely the final version will have a higher build number but this is fine for the coding . > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8211106 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ > > > Thanks, Matthias From matthias.baesken at sap.com Tue Oct 2 15:02:53 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 2 Oct 2018 15:02:53 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: Hi Bob, no problem , we can wait a few days until the final version of Win server 2019 is out, and check the buildNumber again : https://cloudblogs.microsoft.com/windowsserver/2018/09/24/windows-server-2019-announcing-general-availability-in-october/ says : "In October, customers will have access to Windows Server 2019 through all the channels! We will publish a blog post to mark the availability of Windows Server 2019 soon." > > The latest preview release is build 17744. Are you testing on that release? > I was testing on a system with build number 17677 ( Windows Server 2019 preview , seems older than what you are seeing) and 17723 . Best regards, Matthias > -----Original Message----- > From: Bob Vandette > Sent: Dienstag, 2. Oktober 2018 16:09 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; > Moldenhauer, Niclas > Subject: Re: RFR : 8211106: [windows] Update OS detection code to > recognize Windows Server 2019 > > Matthias, > > We don?t usually add logic to the JDK related to unreleased operating system > previews. > > Has the ReleaseID been updated on the system you are testing on? > > This is the documented way of determining the OS version you are running > on? > > The latest preview release is build 17744. Are you testing on that release? > > https://techcommunity.microsoft.com/t5/Windows-Server- > Insiders/Windows-Server-2019-version-info/td-p/234472 > > > Bob. > > > > On Oct 2, 2018, at 9:01 AM, Baesken, Matthias > wrote: > > > > Hello, please review change 8211106 . > > > > It updates the Windows OS detection code to recognize Windows Server > 2019 . > > > > For this we have to look at the build number (dwBuildNumber of > OSVERSIONINFOEX), > > > > https://docs.microsoft.com/en-us/windows/desktop/api/Winnt/ns-winnt- > _osversioninfoexa > > > > > > because dwMajorVersion and dwMinorVersion are the same for > Windows server 2016 and 2019 . > > > > The build number used to compare ( 17677 ) is for Windows Server 2019 > preview , most likely the final version will have a higher build number but > this is fine for the coding . > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8211106 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ > > > > > > Thanks, Matthias From mandy.chung at oracle.com Tue Oct 2 15:40:35 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 08:40:35 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> On 10/2/18 12:21 AM, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). I think Helper class should continue to return null if jmods does not exist.? test/jdk/tools/jimage/JImageTest.java should also be reverted. Otherwise, the clean up looks good. Mandy From erik.joelsson at oracle.com Tue Oct 2 15:53:46 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Oct 2018 08:53:46 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <3971e8aa-c8f1-4676-8288-40828b172c90@oracle.com> Build changes look good to me. /Erik On 2018-10-02 00:21, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > > * Background (from the issue) > > The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. > > > * About the change > > The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: > > build-dev: make related files, jprt.* > hotspot-dev: {src,test}/hotspot > core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid > > Of course I?d welcome reviews across those mappings as well. > > * Testing > > tier1 (passed), tier2-3 still running (looking good so far). > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Tue Oct 2 18:17:18 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 2 Oct 2018 11:17:18 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. Cheers, Mikael > On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: > > > > On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >> Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >> > > test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). > > I think Helper class should continue to return null if jmods does not exist. test/jdk/tools/jimage/JImageTest.java should also be reverted. > > Otherwise, the clean up looks good. > > Mandy From martinrb at google.com Tue Oct 2 18:17:27 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Oct 2018 11:17:27 -0700 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: Raffaello and Ulf should talk. It seems like Ulf's ryu project is trying to solve the same problem. ryu is also still being worked on, but there is already a published paper and ryu is being adopted by various core libraries. https://github.com/ulfjack/ryu https://dl.acm.org/citation.cfm?id=3192369 Ulf, if you haven't already signed an Oracle Contributor Agreement for openjdk, you should do so. (Who knew printing floating point numbers could be so hard?) On Wed, Sep 26, 2018 at 10:39 AM, wrote: > Hi, > > the current specification of Double.toString(double) is not precise > enough to uniquely determine the resulting String. It leaves leeway for > interpretation, thus potentially allowing implementations to return > slightly different results, even from one release to the next [1]. > > In addition, as the bug description points out, the current > implementation does not even always meet its own specification, leading > to results that are sometimes longer than needed. > > To address and overcome both issues, a new specification in the form of > Javadoc associated to Double.toString(double) and Float.toString(float) > is proposed, along with a clean-room re-implementation. > > The intent of the specification is to explicitly separate the > determination of the unique decimal number to represent the floating > point argument (double/float) from its formatting as a String. > > The clean-room implementation enjoys the following properties: > * No objects at all are instantiated except for the resulting String and > its backing storage. > * Only arithmetic on longs/ints is performed. > * The decimal selection algorithm performs at most one division on longs > per conversion and is loop-free. > * The digits extraction algorithm is totally division-free. > * None of the anomalies described in the bug report have been observed. > * The new Double.toString(double) speedup with respect to the current > implementation, according to jmh, is better than 13x when measured over > bitwise uniformly distributed random samples. > * In the case of Float.toString(float), *all* results of the 2^32 float > values have been extensively tested to meet the specification. > * In the case of Double.toString(double), as it is infeasible to test > all results, several billions of random doubles have been extensively > tested. > > Since there's a change in the specification, according to my sponsor and > the formalities it has to undergo a CSR. > > > > The submitted code contains both the changes to the current > implementation and extensive jtreg tests. > > > > While I've struggled to keep the code within the 80 chars/line limit, > mercurial still generates longer lines. Thus, to avoid possible problems > with the email systems, the code is submitted both inline and as an > attachment. Hope at least one copy makes its way without errors. > > > Greetings > Raffaello > > > [1] https://bugs.openjdk.java.net/browse/JDK-4511638 > > > > # HG changeset patch > # User lello > # Date 1537948169 -7200 > # Wed Sep 26 09:49:29 2018 +0200 > # Node ID 6bd9d2c45440c578b93d2f07e5eaea73928be4d5 > # Parent 5f931e3e7a63b550d832d2624db32033b875c720 > Patches to fix JDK-4511638 > > diff --git a/src/java.base/share/classes/java/lang/Double.java > b/src/java.base/share/classes/java/lang/Double.java > --- a/src/java.base/share/classes/java/lang/Double.java > +++ b/src/java.base/share/classes/java/lang/Double.java > @@ -25,6 +25,7 @@ > > package java.lang; > > +import jdk.internal.math.DoubleToDecimal; > import jdk.internal.math.FloatingDecimal; > import jdk.internal.math.DoubleConsts; > import jdk.internal.HotSpotIntrinsicCandidate; > @@ -139,69 +140,108 @@ > public static final Class TYPE = (Class) > Class.getPrimitiveClass("double"); > > /** > - * Returns a string representation of the {@code double} > - * argument. All characters mentioned below are ASCII characters. > - *

    > - *
  • If the argument is NaN, the result is the string > - * "{@code NaN}". > - *
  • Otherwise, the result is a string that represents the sign and > - * magnitude (absolute value) of the argument. If the sign is > negative, > - * the first character of the result is '{@code -}' > - * ({@code '\u005Cu002D'}); if the sign is positive, no sign character > - * appears in the result. As for the magnitude m: > + * Returns a string rendering of the {@code double} argument. > + * > + *

    The characters of the result are all drawn from the ASCII set. > *

      > - *
    • If m is infinity, it is represented by the characters > - * {@code "Infinity"}; thus, positive infinity produces the result > - * {@code "Infinity"} and negative infinity produces the result > - * {@code "-Infinity"}. > + *
    • Any NaN, whether quiet or signaling, is rendered > symbolically > + * as {@code "NaN"}, regardless of the sign bit. > + *
    • The infinities +∞ and -∞ are rendered as > + * {@code "Infinity"} and {@code "-Infinity"}, respectively. > + *
    • The positive and negative zeroes are rendered as > + * {@code "0.0"} and {@code "-0.0"}, respectively. > + *
    • Otherwise {@code v} is finite and non-zero. > + * It is rendered in two stages: > + *
        > + *
      • Selection of a decimal: A well-specified > non-zero > + * decimal d is selected to represent {@code v}. > + *
      • Formatting as a string: The decimal > d is > + * formatted as a string, either in plain or in computerized > + * scientific notation, depending on its value. > + *
      > + *
    > * > - *
  • If m is zero, it is represented by the characters > - * {@code "0.0"}; thus, negative zero produces the result > - * {@code "-0.0"} and positive zero produces the result > - * {@code "0.0"}. > - * > - *
  • If m is greater than or equal to 10-3 but > less > - * than 107, then it is represented as the integer part of > - * m, in decimal form with no leading zeroes, followed by > - * '{@code .}' ({@code '\u005Cu002E'}), followed by one or > - * more decimal digits representing the fractional part of m. > + *

    The selected decimal d has a length n if it can be > + * written as d = c·10q for > some > + * integers q and c meeting 10n-1 ≤ > + * |c| < 10n. It has all the following > + * properties: > + *

      > + *
    • It rounds to {@code v} according to the usual > round-to-closest > + * rule of IEEE 754 floating-point arithmetic. > + *
    • Among the decimals above, it has a length of 2 or more. > + *
    • Among all such decimals, it is one of those with the > shortest > + * length. > + *
    • Among the latter ones, it is the one closest to {@code > v}. Or > + * if there are two that are equally close to {@code v}, it is > the one > + * whose least significant digit is even. > + *
    > + * More formally, let d' = > c'·10q' > + * ≠ d be any other decimal that rounds to {@code v} > according to > + * IEEE 754 and of a length n'. Then: > + *
      > + *
    • either n' = 1, thus d' is too short; > + *
    • or n' > n, thus d' is too long; > + *
    • or n' = n and > + *
        > + *
      • either |d - {@code v}| < |d' - > {@code v}|: > + * thus d' is farther from {@code v}; > + *
      • or |d - {@code v}| = |d' - {@code v}| > and > + * c is even while c' is odd > + *
      > + *
    > * > - *
  • If m is less than 10-3 or greater than or > - * equal to 107, then it is represented in so-called > - * "computerized scientific notation." Let n be the unique > - * integer such that 10n ≤ m {@literal <} > - * 10n+1; then let a be the > - * mathematically exact quotient of m and > - * 10n so that 1 ≤ a {@literal <} 10. The > - * magnitude is then represented as the integer part of a, > - * as a single decimal digit, followed by '{@code .}' > - * ({@code '\u005Cu002E'}), followed by decimal digits > - * representing the fractional part of a, followed by the > - * letter '{@code E}' ({@code '\u005Cu0045'}), followed > - * by a representation of n as a decimal integer, as > - * produced by the method {@link Integer#toString(int)}. > - *
> - * > - * How many digits must be printed for the fractional part of > - * m or a? There must be at least one digit to represent > - * the fractional part, and beyond that as many, but only as many, > more > - * digits as are needed to uniquely distinguish the argument value > from > - * adjacent values of type {@code double}. That is, suppose that > - * x is the exact mathematical value represented by the decimal > - * representation produced by this method for a finite nonzero > argument > - * d. Then d must be the {@code double} value nearest > - * to x; or if two {@code double} values are equally close > - * to x, then d must be one of them and the least > - * significant bit of the significand of d must be {@code 0}. > + *

The selected decimal d is then formatted as a string. > + * If d < 0, the first character of the string is the sign > + * '{@code -}'. Let |d| = m·10k i>, > + * for the unique pair of integer k and real m meeting > + * 1 ≤ m < 10. Also, let the decimal expansion of > m be > + * > m1 . m2 … mi, > + * with i ≥ 1 and mi ≠ 0. > + *

    > + *
  • Case -3 ≤ k < 0: |d| is formatted as > + * 0 . 0…0m1…mi, > + * where there are exactly -k leading zeroes before > + * m1, including the zero to the left of the > + * decimal point; for example, {@code "0.01234"}. > + *
  • Case 0 ≤ k < 7: > + *
      > + *
    • Subcase i < k + 2: > + * |d| is formatted as > + * m1…mi > 0…0 . 0, > + * where there are exactly k + 2 - i trailing > zeroes > + * after mi, including the zero to > the > + * right of the decimal point; for example, {@code "1200.0"}. > + *
    • Subcase i ≥ k + 2: > + * |d| is formatted as m1… -- > + * -->mk+1 . mk+2…mi; for example, {@code > "1234.32"}. > + *
    > + *
  • Case k < -3 or k ≥ 7: > + * computerized scientific notation is used to format |d|, > + * by combining m and k separated by the exponent > + * indicator '{@code E}'. The exponent k is formatted as in > + * {@link Integer#toString(int)}. > + *
      > + *
    • Subcase i = 1: |d| is formatted as > + * m1 . 0Ek; > + * for example, {@code "2.0E23"}. > + *
    • Subcase i > 1: |d| is formatted as > + * > m1 . m2…miEk; > + * for example, {@code "1.234E-32"}. > + *
    > + *
> * > - *

To create localized string representations of a floating-point > - * value, use subclasses of {@link java.text.NumberFormat}. > - * > - * @param d the {@code double} to be converted. > - * @return a string representation of the argument. > + * @param v the {@code double} to be rendered. > + * @return a string rendering of the argument. > */ > - public static String toString(double d) { > - return FloatingDecimal.toJavaFormatString(d); > + public static String toString(double v) { > + return DoubleToDecimal.toString(v); > } > > /** > diff --git a/src/java.base/share/classes/java/lang/Float.java > b/src/java.base/share/classes/java/lang/Float.java > --- a/src/java.base/share/classes/java/lang/Float.java > +++ b/src/java.base/share/classes/java/lang/Float.java > @@ -25,6 +25,7 @@ > > package java.lang; > > +import jdk.internal.math.FloatToDecimal; > import jdk.internal.math.FloatingDecimal; > import jdk.internal.HotSpotIntrinsicCandidate; > > @@ -136,73 +137,107 @@ > public static final Class TYPE = (Class) > Class.getPrimitiveClass("float"); > > /** > - * Returns a string representation of the {@code float} > - * argument. All characters mentioned below are ASCII characters. > + * Returns a string rendering of the {@code float} argument. > + * > + *

The characters of the result are all drawn from the ASCII set. > *

    > - *
  • If the argument is NaN, the result is the string > - * "{@code NaN}". > - *
  • Otherwise, the result is a string that represents the sign and > - * magnitude (absolute value) of the argument. If the sign is > - * negative, the first character of the result is > - * '{@code -}' ({@code '\u005Cu002D'}); if the sign is > - * positive, no sign character appears in the result. As for > - * the magnitude m: > + *
  • Any NaN, whether quiet or signaling, is rendered > symbolically > + * as {@code "NaN"}, regardless of the sign bit. > + *
  • The infinities +∞ and -∞ are rendered as > + * {@code "Infinity"} and {@code "-Infinity"}, respectively. > + *
  • The positive and negative zeroes are rendered as > + * {@code "0.0"} and {@code "-0.0"}, respectively. > + *
  • Otherwise {@code v} is finite and non-zero. > + * It is rendered in two stages: > + *
      > + *
    • Selection of a decimal: A well-specified > non-zero > + * decimal d of finite length is selected to represent > + * {@code v}. > + *
    • Formatting as a string: The decimal > d is > + * formatted as a string, either in plain or in computerized > + * scientific notation, depending on its value. > + *
    > + *
> + * > + *

A number d is a decimal of finite length if and only > if it has > + * the form d = c·10q for some > + * integers c and q. It has a length n if > + * 10n-1 ≤ |c| < 10n. > + *

The selected decimal d has all the following properties: > + *

    > + *
  • It rounds to {@code v} according to the usual > round-to-closest > + * rule of IEEE 754 floating-point arithmetic. > + *
  • It has a shortest length n ≥ 2. > + *
  • It is the decimal closest to {@code v} among those > meeting the > + * previous properties. > + *
> + * More formally, let d' = > c'·10q' > + * ≠ d be another decimal that also rounds to {@code v} > according > + * to IEEE 754 and with a length n'. Then: > *
    > - *
  • If m is infinity, it is represented by the characters > - * {@code "Infinity"}; thus, positive infinity produces > - * the result {@code "Infinity"} and negative infinity > - * produces the result {@code "-Infinity"}. > - *
  • If m is zero, it is represented by the characters > - * {@code "0.0"}; thus, negative zero produces the result > - * {@code "-0.0"} and positive zero produces the result > - * {@code "0.0"}. > - *
  • If m is greater than or equal to 10-3 but > - * less than 107, then it is represented as the > - * integer part of m, in decimal form with no leading > - * zeroes, followed by '{@code .}' > - * ({@code '\u005Cu002E'}), followed by one or more > - * decimal digits representing the fractional part of > - * m. > - *
  • If m is less than 10-3 or greater than or > - * equal to 107, then it is represented in > - * so-called "computerized scientific notation." Let n > - * be the unique integer such that 10n ≤ > - * m {@literal <} 10n+1; then let > a > - * be the mathematically exact quotient of m and > - * 10n so that 1 ≤ a {@literal <} 10. > - * The magnitude is then represented as the integer part of > - * a, as a single decimal digit, followed by > - * '{@code .}' ({@code '\u005Cu002E'}), followed by > - * decimal digits representing the fractional part of > - * a, followed by the letter '{@code E}' > - * ({@code '\u005Cu0045'}), followed by a representation > - * of n as a decimal integer, as produced by the > - * method {@link java.lang.Integer#toString(int)}. > + *
  • n' = 1 (d' is too short) or > + *
  • n' > n (d' is too long) or > + *
  • n' = n and > + *
      > + *
    • |d - {@code v}| < |d' - {@code v}| > + * (d' is farther) > + *
    • |d - {@code v}| = |d' - {@code v}| and > + * c is even while c' is odd (tie-breaking > rule when > + * d and d' are equally close to {@code v}) > + *
    > + *
> * > - * > - * > - * How many digits must be printed for the fractional part of > - * m or a? There must be at least one digit > - * to represent the fractional part, and beyond that as many, but > - * only as many, more digits as are needed to uniquely distinguish > - * the argument value from adjacent values of type > - * {@code float}. That is, suppose that x is the > - * exact mathematical value represented by the decimal > - * representation produced by this method for a finite nonzero > - * argument f. Then f must be the {@code float} > - * value nearest to x; or, if two {@code float} values are > - * equally close to x, then f must be one of > - * them and the least significant bit of the significand of > - * f must be {@code 0}. > + *

The selected decimal d is then formatted as a string. > + * If d < 0, the first character of the string is the sign > + * '{@code -}'. Let |d| = m·10k i>, > + * for the unique pair of integer k and real m meeting > + * 1 ≤ m < 10. Also, let the decimal expansion of > m be > + * > m1 . m2 … mi, > + * with i ≥ 1 and mi ≠ 0. > + *

    > + *
  • Case -3 ≤ k < 0: |d| is formatted as > + * 0 . 0…0m1…mi, > + * where there are exactly -k leading zeroes before > + * m1, including the zero to the left of the > + * decimal point; for example, {@code "0.01234"}. > + *
  • Case 0 ≤ k < 7: > + *
      > + *
    • Subcase i < k + 2: > + * |d| is formatted as > + * m1…mi > 0…0 . 0, > + * where there are exactly k + 2 - i trailing > zeroes > + * after mi, including the zero to > the > + * right of the decimal point; for example, {@code "1200.0"}. > + *
    • Subcase i ≥ k + 2: > + * |d| is formatted as m1… -- > + * -->mk+1 . mk+2…mi; for example, {@code > "1234.32"}. > + *
    > + *
  • Case k < -3 or k ≥ 7: > + * computerized scientific notation is used to format |d|, > + * by combining m and k separated by the exponent > + * indicator '{@code E}'. The exponent k is formatted as in > + * {@link Integer#toString(int)}. > + *
      > + *
    • Subcase i = 1: |d| is formatted as > + * m1 . 0Ek; > + * for example, {@code "2.0E23"}. > + *
    • Subcase i > 1: |d| is formatted as > + * > m1 . m2…miEk; > + * for example, {@code "1.234E-32"}. > + *
    > + *
> * > - *

To create localized string representations of a floating-point > - * value, use subclasses of {@link java.text.NumberFormat}. > - * > - * @param f the float to be converted. > - * @return a string representation of the argument. > + * @param v the {@code float} to be rendered. > + * @return a string rendering of the argument. > */ > - public static String toString(float f) { > - return FloatingDecimal.toJavaFormatString(f); > + public static String toString(float v) { > + return FloatToDecimal.toString(v); > } > > /** > diff --git > a/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java > b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java > new file mode 100644 > --- /dev/null > +++ b/src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java > @@ -0,0 +1,409 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +package jdk.internal.math; > + > +import static java.lang.Double.*; > +import static java.lang.Long.numberOfLeadingZeros; > +import static java.lang.Math.multiplyHigh; > +import static jdk.internal.math.MathUtils.*; > + > +/** > + * This class exposes a method to render a {@code double} as a string. > + > + * @author Raffaello Giulietti > + */ > +final public class DoubleToDecimal { > + > + // Precision of normal values in bits. > + private static final int P = 53; > + > + // Length in bits of the exponent field. > + private static final int W = (Double.SIZE - 1) - (P - 1); > + > + // Minimum value of the exponent. > + private static final int Q_MIN = (-1 << W - 1) - P + 3; > + > + // Minimum value of the coefficient of a normal value. > + private static final long C_MIN = 1L << P - 1; > + > + // Mask to extract the IEEE 754-2008 biased exponent. > + private static final int BQ_MASK = (1 << W) - 1; > + > + // Mask to extract the IEEE 754-2008 fraction bits. > + private static final long T_MASK = (1L << P - 1) - 1; > + > + // H = min {n integer | 10^(n-1) > 2^P} > + private static final int H = 17; > + > + // used in the left-to-right extraction of the digits > + private static final int LTR = 28; > + private static final int MASK_LTR = (1 << LTR) - 1; > + > + private static final long MASK_63 = (1L << Long.SIZE - 1) - 1; > + > + // for thread-safety, each thread gets its own instance of this class > + private static final ThreadLocal threadLocal = > + ThreadLocal.withInitial(DoubleToDecimal::new); > + > + /* > + Room for the longer of the forms > + -ddddd.dddddddddddd H + 2 characters > + -0.00ddddddddddddddddd H + 5 characters > + -d.ddddddddddddddddE-eee H + 7 characters > + where there are H digits d > + */ > + private final char[] buf = new char[H + 7]; > + > + // index of rightmost valid character > + private int index; > + > + private DoubleToDecimal() { > + } > + > + /* > + See Double::toString for javadoc. > + */ > + public static String toString(double v) { > + return threadLocalInstance().toDecimal(v); > + } > + > + private static DoubleToDecimal threadLocalInstance() { > + return threadLocal.get(); > + } > + > + private String toDecimal(double v) { > + long bits = doubleToRawLongBits(v); > + int bq = (int) (bits >>> P - 1) & BQ_MASK; > + if (bq < BQ_MASK) { > + index = -1; > + if (bits < 0) { > + append('-'); > + } > + if (bq > 0) { > + return toDecimal(Q_MIN - 1 + bq, C_MIN | bits & T_MASK); > + } > + if (bits == 0x0000_0000_0000_0000L) { > + return "0.0"; > + } > + if (bits == 0x8000_0000_0000_0000L) { > + return "-0.0"; > + } > + return toDecimal(Q_MIN, bits & T_MASK); > + } > + if (v != v) { > + return "NaN"; > + } > + if (v == POSITIVE_INFINITY) { > + return "Infinity"; > + } > + return "-Infinity"; > + } > + > + // Let v = c * 2^q be the absolute value of the original double. > Renders v. > + private String toDecimal(int q, long c) { > + /* > + out = 0, if the boundaries of the rounding interval are included > + out = 1, if they are excluded > + d = 1 for even, d = 2 for uneven spacing around v. > + v = cb * 2^qb > + predecessor(v) = cbl * 2^qb > + successor(v) = cbr * 2^qb > + */ > + int out = (int) c & 0x1; > + > + long cb; > + long cbr; > + long cbl; > + int k; > + int ord2alpha; > + if (c != C_MIN | q == Q_MIN) { > + cb = c << 1; > + cbr = cb + 1; > + k = flog10pow2(q); > + ord2alpha = q + flog2pow10(-k) + 1; > + } else { > + cb = c << 2; > + cbr = cb + 2; > + k = flog10threeQuartersPow2(q); > + ord2alpha = q + flog2pow10(-k); > + } > + cbl = cb - 1; > + long mask = (1L << 63 - ord2alpha) - 1; > + long threshold = 1L << 62 - ord2alpha; > + > + // pow5 = pow51*2^63 + pow50 > + long pow51 = ceilPow5dHigh(-k); > + long pow50 = ceilPow5dLow(-k); > + > + // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb > + long x0 = pow50 * cb; > + long x1 = multiplyHigh(pow50, cb); > + long y0 = pow51 * cb; > + long y1 = multiplyHigh(pow51, cb); > + long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63); > + long p0 = x0 & MASK_63; > + long p1 = z & MASK_63; > + long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63); > + long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha; > + if ((p1 & mask) != 0 || p0 >= threshold) { > + vn |= 1; > + } > + > + // Similarly as above, with p = pow5 * cbl > + x0 = pow50 * cbl; > + x1 = multiplyHigh(pow50, cbl); > + y0 = pow51 * cbl; > + y1 = multiplyHigh(pow51, cbl); > + z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63); > + p0 = x0 & MASK_63; > + p1 = z & MASK_63; > + p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63); > + long vnl = p2 << ord2alpha | p1 >>> 63 - ord2alpha; > + if ((p1 & mask) != 0 || p0 >= threshold) { > + vnl |= 1; > + } > + > + // Similarly as above, with p = pow5 * cbr > + x0 = pow50 * cbr; > + x1 = multiplyHigh(pow50, cbr); > + y0 = pow51 * cbr; > + y1 = multiplyHigh(pow51, cbr); > + z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63); > + p0 = x0 & MASK_63; > + p1 = z & MASK_63; > + p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63); > + long vnr = p2 << ord2alpha | p1 >>> 63 - ord2alpha; > + if ((p1 & mask) != 0 || p0 >= threshold) { > + vnr |= 1; > + } > + > + long s = vn >> 2; > + if (s >= 100) { > + long s10 = s - s % 10; > + long t10 = s10 + 10; > + boolean uin10 = vnl + out <= s10 << 1; > + boolean win10 = (t10 << 1) + out <= vnr; > + if (uin10 | win10) { > + if (!win10) { > + return toChars(s10, k); > + } > + if (!uin10) { > + return toChars(t10, k); > + } > + } > + } else if (s < 10) { > + /* > + Special cases that need to be made artificially longer to meet > + the specification > + */ > + switch ((int) s) { > + case 4: return toChars(49, -325); // 4.9 * 10^-324 > + case 9: return toChars(99, -325); // 9.9 * 10^-324 > + } > + } > + long t = s + 1; > + boolean uin = vnl + out <= s << 1; > + boolean win = (t << 1) + out <= vnr; > + if (!win) { > + return toChars(s, k); > + } > + if (!uin) { > + return toChars(t, k); > + } > + long cmp = vn - (s + t << 1); > + if (cmp < 0) { > + return toChars(s, k); > + } > + if (cmp > 0) { > + return toChars(t, k); > + } > + if ((s & 1) == 0) { > + return toChars(s, k); > + } > + return toChars(t, k); > + } > + > + /* > + The method formats the number f * 10^e > + > + Division is avoided altogether by replacing it with multiplications > + and shifts. This has a noticeable impact on performance. > + For more in-depth readings, see for example > + * Moeller & Granlund, "Improved division by invariant integers" > + * ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned > + Division by Constants" > + > + Also, once the quotient is known, the remainder is computed > indirectly. > + */ > + private String toChars(long f, int e) { > + // Normalize f to lie in the f-independent interval [10^(H-1), > 10^H) > + int len10 = flog10pow2(Long.SIZE - numberOfLeadingZeros(f)); > + if (f >= pow10[len10]) { > + len10 += 1; > + } > + // 10^(len10-1) <= f < 10^len10 > + f *= pow10[H - len10]; > + e += len10; > + > + /* > + Split the H = 17 digits of f into: > + h = the most significant digit of f > + m = the next 8 most significant digits of f > + l = the last 8, least significant digits of f > + > + Pictorially, the selected decimal to format as String is > + 0.hmmmmmmmmllllllll * 10^e > + Depending on the value of e, plain or computerized scientific > notation > + is used. > + */ > + long hm = multiplyHigh(f, 48_357_032_784_585_167L) >>> 18; > + int l = (int) (f - 100_000_000L * hm); > + int h = (int) (hm * 1_441_151_881L >>> 57); > + int m = (int) (hm - 100_000_000 * h); > + > + /* > + The left-to-right digits generation in toChars_* is inspired by > + * Bouvier & Zimmermann, "Division-Free Binary-to-Decimal > Conversion" > + */ > + if (0 < e && e <= 7) { > + return toChars_1(h, m, l, e); > + } > + if (-3 < e && e <= 0) { > + return toChars_2(h, m, l, e); > + } > + return toChars_3(h, m, l, e); > + } > + > + // 0 < e <= 7: plain format without leading zeroes. > + private String toChars_1(int h, int m, int l, int e) { > + appendDigit(h); > + // y = (m + 1) * 2^LTR / 100_000_000 - 1; > + int y = (int) (multiplyHigh( > + (long) (m + 1) << LTR, > + 48_357_032_784_585_167L) >>> 18) - 1; > + int t; > + int i = 1; > + for (; i < e; ++i) { > + t = 10 * y; > + appendDigit(t >>> LTR); > + y = t & MASK_LTR; > + } > + append('.'); > + for (; i <= 8; ++i) { > + t = 10 * y; > + appendDigit(t >>> LTR); > + y = t & MASK_LTR; > + } > + lowDigits(l); > + return charsToString(); > + } > + > + // -3 < e <= 0: plain format with leading zeroes. > + private String toChars_2(int h, int m, int l, int e) { > + appendDigit(0); > + append('.'); > + for (; e < 0; ++e) { > + appendDigit(0); > + } > + appendDigit(h); > + append8Digits(m); > + lowDigits(l); > + return charsToString(); > + } > + > + // -3 >= e | e > 7: computerized scientific notation > + private String toChars_3(int h, int m, int l, int e) { > + appendDigit(h); > + append('.'); > + append8Digits(m); > + lowDigits(l); > + exponent(e - 1); > + return charsToString(); > + } > + > + private void lowDigits(int l) { > + if (l != 0) { > + append8Digits(l); > + } > + removeTrailingZeroes(); > + } > + > + private void append8Digits(int v) { > + // y = (v + 1) * 2^LTR / 100_000_000 - 1; > + int y = (int) (multiplyHigh((long) (v + 1) << LTR, > + 48_357_032_784_585_167L) >>> 18) - 1; > + for (int i = 0; i < 8; ++i) { > + int t = 10 * y; > + appendDigit(t >>> LTR); > + y = t & MASK_LTR; > + } > + } > + > + private void removeTrailingZeroes() { > + while (buf[index] == '0') { > + --index; > + } > + if (buf[index] == '.') { > + ++index; > + } > + } > + > + private void exponent(int e) { > + append('E'); > + if (e < 0) { > + append('-'); > + e = -e; > + } > + if (e < 10) { > + appendDigit(e); > + return; > + } > + if (e < 100) { > + // d = e / 10 > + int d = e * 205 >>> 11; > + appendDigit(d); > + appendDigit(e - 10 * d); > + return; > + } > + // d = e / 100 > + int d = e * 1_311 >>> 17; > + appendDigit(d); > + e -= 100 * d; > + // d = e / 10 > + d = e * 205 >>> 11; > + appendDigit(d); > + appendDigit(e - 10 * d); > + } > + > + private void append(int c) { > + buf[++index] = (char) c; > + } > + > + private void appendDigit(int d) { > + buf[++index] = (char) ('0' + d); > + } > + > + private String charsToString() { > + return new String(buf, 0, index + 1); > + } > + > +} > diff --git > a/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java > b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java > new file mode 100644 > --- /dev/null > +++ b/src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java > @@ -0,0 +1,393 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +package jdk.internal.math; > + > +import static java.lang.Float.*; > +import static java.lang.Long.numberOfLeadingZeros; > +import static java.lang.Math.multiplyHigh; > +import static jdk.internal.math.MathUtils.*; > + > +/** > + * This class exposes a method to render a {@code float} as a string. > + > + * @author Raffaello Giulietti > + */ > +final public class FloatToDecimal { > + > + // Precision of normal values in bits. > + private static final int P = 24; > + > + // Length in bits of the exponent field. > + private static final int W = (Float.SIZE - 1) - (P - 1); > + > + // Minimum value of the exponent. > + private static final int Q_MIN = (-1 << W - 1) - P + 3; > + > + // Minimum value of the coefficient of a normal value. > + private static final int C_MIN = 1 << P - 1; > + > + // Mask to extract the IEEE 754-2008 biased exponent. > + private static final int BQ_MASK = (1 << W) - 1; > + > + // Mask to extract the IEEE 754-2008 fraction bits. > + private static final int T_MASK = (1 << P - 1) - 1; > + > + // H = min {n integer | 10^(n-1) > 2^P} > + private static final int H = 9; > + > + // used in the left-to-right extraction of the digits > + private static final int LTR = 28; > + private static final int MASK_LTR = (1 << LTR) - 1; > + > + private static final long MASK_63 = (1L << Long.SIZE - 1) - 1; > + > + // for thread-safety, each thread gets its own instance of this class > + private static final ThreadLocal threadLocal = > + ThreadLocal.withInitial(FloatToDecimal::new); > + > + /* > + Room for the longer of the forms > + -ddddd.dddd H + 2 characters > + -0.00ddddddddd H + 5 characters > + -d.ddddddddE-ee H + 6 characters > + where there are H digits d > + */ > + private final char[] buf = new char[H + 6]; > + > + // index of rightmost valid character > + private int index; > + > + private FloatToDecimal() { > + } > + > + /* > + See Float::toString for javadoc. > + */ > + public static String toString(float v) { > + return threadLocalInstance().toDecimal(v); > + } > + > + private static FloatToDecimal threadLocalInstance() { > + return threadLocal.get(); > + } > + > + private String toDecimal(float v) { > + int bits = floatToRawIntBits(v); > + int bq = (bits >>> P - 1) & BQ_MASK; > + if (bq < BQ_MASK) { > + index = -1; > + if (bits < 0) { > + append('-'); > + } > + if (bq > 0) { > + return toDecimal(Q_MIN - 1 + bq, C_MIN | bits & T_MASK); > + } > + if (bits == 0x0000_0000) { > + return "0.0"; > + } > + if (bits == 0x8000_0000) { > + return "-0.0"; > + } > + return toDecimal(Q_MIN, bits & T_MASK); > + } > + if (v != v) { > + return "NaN"; > + } > + if (v == POSITIVE_INFINITY) { > + return "Infinity"; > + } > + return "-Infinity"; > + } > + > + // Let v = c * 2^q be the absolute value of the original float. > Renders v. > + private String toDecimal(int q, int c) { > + /* > + out = 0, if the boundaries of the rounding interval are included > + out = 1, if they are excluded > + d = 1 for even, d = 2 for uneven spacing around v. > + v = cb * 2^qb > + predecessor(v) = cbl * 2^qb > + successor(v) = cbr * 2^qb > + */ > + int out = c & 0x1; > + > + long cb; > + long cbr; > + long cbl; > + int k; > + int ord2alpha; > + if (c != C_MIN | q == Q_MIN) { > + cb = c << 1; > + cbr = cb + 1; > + k = flog10pow2(q); > + ord2alpha = q + flog2pow10(-k) + 1; > + } else { > + cb = c << 2; > + cbr = cb + 2; > + k = flog10threeQuartersPow2(q); > + ord2alpha = q + flog2pow10(-k); > + } > + cbl = cb - 1; > + long mask = (1L << 63 - ord2alpha) - 1; > + long threshold = 1L << 62 - ord2alpha; > + > + // pow5 = pow51*2^63 + pow50 > + long pow51 = ceilPow5dHigh(-k); > + long pow50 = ceilPow5dLow(-k); > + > + // p = p2*2^126 + p1*2^63 + p0 and p = pow5 * cb > + long x0 = pow50 * cb; > + long x1 = multiplyHigh(pow50, cb); > + long y0 = pow51 * cb; > + long y1 = multiplyHigh(pow51, cb); > + long z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63); > + long p0 = x0 & MASK_63; > + long p1 = z & MASK_63; > + long p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63); > + long vn = p2 << 1 + ord2alpha | p1 >>> 62 - ord2alpha; > + if ((p1 & mask) != 0 || p0 >= threshold) { > + vn |= 1; > + } > + > + // Similarly as above, with p = pow5 * cbl > + x0 = pow50 * cbl; > + x1 = multiplyHigh(pow50, cbl); > + y0 = pow51 * cbl; > + y1 = multiplyHigh(pow51, cbl); > + z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63); > + p0 = x0 & MASK_63; > + p1 = z & MASK_63; > + p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63); > + long vnl = p2 << ord2alpha | p1 >>> 63 - ord2alpha; > + if ((p1 & mask) != 0 || p0 >= threshold) { > + vnl |= 1; > + } > + > + // Similarly as above, with p = pow5 * cbr > + x0 = pow50 * cbr; > + x1 = multiplyHigh(pow50, cbr); > + y0 = pow51 * cbr; > + y1 = multiplyHigh(pow51, cbr); > + z = (x1 << 1 | x0 >>> 63) + (y0 & MASK_63); > + p0 = x0 & MASK_63; > + p1 = z & MASK_63; > + p2 = (y1 << 1 | y0 >>> 63) + (z >>> 63); > + long vnr = p2 << ord2alpha | p1 >>> 63 - ord2alpha; > + if ((p1 & mask) != 0 || p0 >= threshold) { > + vnr |= 1; > + } > + > + long s = vn >> 2; > + if (s >= 100) { > + long s10 = s - s % 10; > + long t10 = s10 + 10; > + boolean uin10 = vnl + out <= s10 << 1; > + boolean win10 = (t10 << 1) + out <= vnr; > + if (uin10 | win10) { > + if (!win10) { > + return toChars(s10, k); > + } > + if (!uin10) { > + return toChars(t10, k); > + } > + } > + } else if (s < 10) { > + /* > + Special cases that need to be made artificially longer to meet > + the specification > + */ > + switch ((int) s) { > + case 1: return toChars(14, -46); // 1.4 * 10^-45 > + case 2: return toChars(28, -46); // 2.8 * 10^-45 > + case 4: return toChars(42, -46); // 4.2 * 10^-45 > + case 5: return toChars(56, -46); // 5.6 * 10^-45 > + case 7: return toChars(70, -46); // 7.0 * 10^-45 > + case 8: return toChars(84, -46); // 8.4 * 10^-45 > + case 9: return toChars(98, -46); // 9.8 * 10^-45 > + } > + } > + long t = s + 1; > + boolean uin = vnl + out <= s << 1; > + boolean win = (t << 1) + out <= vnr; > + if (!win) { > + return toChars(s, k); > + } > + if (!uin) { > + return toChars(t, k); > + } > + long cmp = vn - (s + t << 1); > + if (cmp < 0) { > + return toChars(s, k); > + } > + if (cmp > 0) { > + return toChars(t, k); > + } > + if ((s & 1) == 0) { > + return toChars(s, k); > + } > + return toChars(t, k); > + } > + > + /* > + The method formats the number f * 10^e > + > + Division is avoided altogether by replacing it with multiplications > + and shifts. This has a noticeable impact on performance. > + For more in-depth readings, see for example > + * Moeller & Granlund, "Improved division by invariant integers" > + * ridiculous_fish, "Labor of Division (Episode III): Faster Unsigned > + Division by Constants" > + > + Also, once the quotient is known, the remainder is computed > indirectly. > + */ > + private String toChars(long f, int e) { > + // Normalize f to lie in the f-independent interval [10^(H-1), > 10^H) > + int len10 = flog10pow2(Long.SIZE - numberOfLeadingZeros(f)); > + if (f >= pow10[len10]) { > + len10 += 1; > + } > + // 10^(len10-1) <= f < 10^len10 > + f *= pow10[H - len10]; > + e += len10; > + > + /* > + Split the H = 9 digits of f into: > + h = the most significant digit of f > + l = the last 8, least significant digits of f > + > + Pictorially, the selected decimal to format as String is > + 0.hllllllll * 10^e > + Depending on the value of e, plain or computerized scientific > notation > + is used. > + */ > + int h = (int) (f * 1_441_151_881L >>> 57); > + int l = (int) (f - 100_000_000 * h); > + > + /* > + The left-to-right digits generation in toChars_* is inspired by > + * Bouvier & Zimmermann, "Division-Free Binary-to-Decimal > Conversion" > + */ > + if (0 < e && e <= 7) { > + return toChars_1(h, l, e); > + } > + if (-3 < e && e <= 0) { > + return toChars_2(h, l, e); > + } > + return toChars_3(h, l, e); > + } > + > + // 0 < e <= 7: plain format without leading zeroes. > + private String toChars_1(int h, int l, int e) { > + appendDigit(h); > + // y = (l + 1) * 2^LTR / 100_000_000 - 1; > + int y = (int) (multiplyHigh( > + (long) (l + 1) << LTR, > + 48_357_032_784_585_167L) >>> 18) - 1; > + int t; > + int i = 1; > + for (; i < e; ++i) { > + t = 10 * y; > + appendDigit(t >>> LTR); > + y = t & MASK_LTR; > + } > + append('.'); > + for (; i <= 8; ++i) { > + t = 10 * y; > + appendDigit(t >>> LTR); > + y = t & MASK_LTR; > + } > + removeTrailingZeroes(); > + return charsToString(); > + } > + > + // -3 < e <= 0: plain format with leading zeroes. > + private String toChars_2(int h, int l, int e) { > + appendDigit(0); > + append('.'); > + for (; e < 0; ++e) { > + appendDigit(0); > + } > + appendDigit(h); > + append8Digits(l); > + removeTrailingZeroes(); > + return charsToString(); > + } > + > + // -3 >= e | e > 7: computerized scientific notation > + private String toChars_3(int h, int l, int e) { > + appendDigit(h); > + append('.'); > + append8Digits(l); > + removeTrailingZeroes(); > + exponent(e - 1); > + return charsToString(); > + } > + > + private void append8Digits(int v) { > + // y = (v + 1) * 2^LTR / 100_000_000 - 1; > + int y = (int) (multiplyHigh((long) (v + 1) << LTR, > + 48_357_032_784_585_167L) >>> 18) - 1; > + for (int i = 0; i < 8; ++i) { > + int t = 10 * y; > + appendDigit(t >>> LTR); > + y = t & MASK_LTR; > + } > + } > + > + private void removeTrailingZeroes() { > + while (buf[index] == '0') { > + --index; > + } > + if (buf[index] == '.') { > + ++index; > + } > + } > + > + private void exponent(int e) { > + append('E'); > + if (e < 0) { > + append('-'); > + e = -e; > + } > + if (e < 10) { > + appendDigit(e); > + return; > + } > + // d = e / 10 > + int d = e * 205 >>> 11; > + appendDigit(d); > + appendDigit(e - 10 * d); > + } > + > + private void append(int c) { > + buf[++index] = (char) c; > + } > + > + private void appendDigit(int d) { > + buf[++index] = (char) ('0' + d); > + } > + > + private String charsToString() { > + return new String(buf, 0, index + 1); > + } > + > +} > diff --git > a/src/java.base/share/classes/jdk/internal/math/MathUtils.java > b/src/java.base/share/classes/jdk/internal/math/MathUtils.java > new file mode 100644 > --- /dev/null > +++ b/src/java.base/share/classes/jdk/internal/math/MathUtils.java > @@ -0,0 +1,775 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +package jdk.internal.math; > + > +/** > + * @author Raffaello Giulietti > + */ > +final class MathUtils { > + > + // C_10 = floor(log10(2) * 2^Q_10), A_10 = floor(log10(3/4) * 2^Q_10) > + private static final int Q_10 = 41; > + private static final long C_10 = 661_971_961_083L; > + private static final long A_10 = -274_743_187_321L; > + > + // C_2 = floor(log2(10) * 2^Q_2) > + private static final int Q_2 = 38; > + private static final long C_2 = 913_124_641_741L; > + > + // The minimum exponent for ceilPow5dHigh(int) > + private static final int MIN_EXP = -292; > + > + private MathUtils() { > + } > + > + // pow10[i] = 10^i, 0 <= i <= H > + static final long[] pow10 = { > + 1L, > + 10L, > + 100L, > + 1_000L, > + 10_000L, > + 100_000L, > + 1_000_000L, > + 10_000_000L, > + 100_000_000L, > + 1_000_000_000L, > + 10_000_000_000L, > + 100_000_000_000L, > + 1_000_000_000_000L, > + 10_000_000_000_000L, > + 100_000_000_000_000L, > + 1_000_000_000_000_000L, > + 10_000_000_000_000_000L, > + 100_000_000_000_000_000L, > + }; > + > + /** > + * Returns the unique integer k such that > + * 10k ≤ 2{@code e} > + * < 10k+1. > + *

> + * The result is correct when |{@code e}| ≤ 5_456_721. > + * Otherwise the result may or may not be correct. > + * > + * @param e The exponent of 2, which should meet > + * |{@code e}| ≤ 5_456_721 for safe results. > + * @return ⌊log102{@code e}⌋. > + */ > + static int flog10pow2(int e) { > + return (int) (e * C_10 >> Q_10); > + } > + > + /** > + * Returns the unique integer k such that > + * 10k ≤ 3/4 · 2{@code e} > + * < 10k+1. > + *

> + * The result is correct when > + * -2_956_395 ≤ |{@code e}| ≤ 2_500_325. > + * Otherwise the result may or may not be correct. > + * > + * @param e The exponent of 2, which should meet > + * -2_956_395 ≤ |{@code e}| ≤ 2_500_325 for safe > results. > + * @return ⌊log10(3/4 · > + * 2{@code e})⌋. > + */ > + static int flog10threeQuartersPow2(int e) { > + return (int) ((e * C_10 + A_10) >> Q_10); > + } > + > + /** > + * Returns the unique integer k such that > + * 2k ≤ 10{@code e} > + * < 2k+1. > + *

> + * The result is correct when |{@code e}| ≤ 1_838_394. > + * Otherwise the result may or may not be correct. > + * > + * @param e The exponent of 10, which should meet > + * |{@code e}| ≤ 1_838_394 for safe results. > + * @return ⌊log210{@code e}⌋. > + */ > + static int flog2pow10(int e) { > + return (int) (e * C_2 >> Q_2); > + } > + > + /** > + * Let 5{@code e} = d · 2r, > + * for the unique pair of integer r and real d meeting > + * 2125 ≤ d < 2126. > + * Further, let c = ⌈d⌉. > + * Split c into the higher 63 bits c1 and > + * the lower 63 bits c0. Thus, > + * c1 = > + * ⌊c · 2-63⌋ > + * and > + * c0 = > + * c - c1 · 263. > + *

> + * This method returns c1 while > + * {@link #ceilPow5dLow(int)} returns c0. > + *

> + * If needed, the exponent r can be computed as > + * r = {@code flog2pow10(e) - e - 125} > + * (see {@link #flog2pow10(int)}). > + * > + * @param e The exponent of 5, > + * which must meet -292 ≤ {@code e} ≤ 324. > + * @return c1 as described above. > + */ > + static long ceilPow5dHigh(int e) { > + return ceilPow5d[e - MIN_EXP << 1]; > + } > + > + /** > + * Returns c0 as described in {@link > #ceilPow5dHigh(int)}. > + * > + * @param e The exponent of 5, > + * which must meet -292 ≤ {@code e} ≤ 324. > + * @return c0 as described in {@link > #ceilPow5dHigh(int)}. > + */ > + static long ceilPow5dLow(int e) { > + return ceilPow5d[e - MIN_EXP << 1 | 1]; > + } > + > + private static final long[] ceilPow5d = { > + /* -292 */ 0x7FBB_D8FE_5F5E_6E27L, 0x497A_3A27_04EE_C3DFL, > + /* -291 */ 0x4FD5_679E_FB9B_04D8L, 0x5DEC_6458_6315_3A6CL, > + /* -290 */ 0x63CA_C186_BA81_C60EL, 0x7567_7D6E_7BDA_8906L, > + /* -289 */ 0x7CBD_71E8_6922_3792L, 0x52C1_5CCA_1AD1_2B48L, > + /* -288 */ 0x4DF6_6731_41B5_62BBL, 0x53B8_D9FE_50C2_BB0DL, > + /* -287 */ 0x6174_00FD_9222_BB6AL, 0x48A7_107D_E4F3_69D0L, > + /* -286 */ 0x79D1_013C_F6AB_6A45L, 0x1AD0_D49D_5E30_4444L, > + /* -285 */ 0x4C22_A0C6_1A2B_226BL, 0x20C2_84E2_5ADE_2AABL, > + /* -284 */ 0x5F2B_48F7_A0B5_EB06L, 0x08F3_261A_F195_B555L, > + /* -283 */ 0x76F6_1B35_88E3_65C7L, 0x4B2F_EFA1_ADFB_22ABL, > + /* -282 */ 0x4A59_D101_758E_1F9CL, 0x5EFD_F5C5_0CBC_F5ABL, > + /* -281 */ 0x5CF0_4541_D2F1_A783L, 0x76BD_7336_4FEC_3315L, > + /* -280 */ 0x742C_5692_47AE_1164L, 0x746C_D003_E3E7_3FDBL, > + /* -279 */ 0x489B_B61B_6CCC_CADFL, 0x08C4_0202_6E70_87E9L, > + /* -278 */ 0x5AC2_A3A2_47FF_FD96L, 0x6AF5_0283_0A0C_A9E3L, > + /* -277 */ 0x7173_4C8A_D9FF_FCFCL, 0x45B2_4323_CC8F_D45CL, > + /* -276 */ 0x46E8_0FD6_C83F_FE1DL, 0x6B8F_69F6_5FD9_E4B9L, > + /* -275 */ 0x58A2_13CC_7A4F_FDA5L, 0x2673_4473_F7D0_5DE8L, > + /* -274 */ 0x6ECA_98BF_98E3_FD0EL, 0x5010_1590_F5C4_7561L, > + /* -273 */ 0x453E_9F77_BF8E_7E29L, 0x120A_0D7A_999A_C95DL, > + /* -272 */ 0x568E_4755_AF72_1DB3L, 0x368C_90D9_4001_7BB4L, > + /* -271 */ 0x6C31_D92B_1B4E_A520L, 0x242F_B50F_9001_DAA1L, > + /* -270 */ 0x439F_27BA_F111_2734L, 0x169D_D129_BA01_28A5L, > + /* -269 */ 0x5486_F1A9_AD55_7101L, 0x1C45_4574_2881_72CEL, > + /* -268 */ 0x69A8_AE14_18AA_CD41L, 0x4356_96D1_32A1_CF81L, > + /* -267 */ 0x4209_6CCC_8F6A_C048L, 0x7A16_1E42_BFA5_21B1L, > + /* -266 */ 0x528B_C7FF_B345_705BL, 0x189B_A5D3_6F8E_6A1DL, > + /* -265 */ 0x672E_B9FF_A016_CC71L, 0x7EC2_8F48_4B72_04A4L, > + /* -264 */ 0x407D_343F_C40E_3FC7L, 0x1F39_998D_2F27_42E7L, > + /* -263 */ 0x509C_814F_B511_CFB9L, 0x0707_FFF0_7AF1_13A1L, > + /* -262 */ 0x64C3_A1A3_A256_43A7L, 0x28C9_FFEC_99AD_5889L, > + /* -261 */ 0x7DF4_8A0C_8AEB_D491L, 0x12FC_7FE7_C018_AEABL, > + /* -260 */ 0x4EB8_D647_D6D3_64DAL, 0x5BDD_CFF0_D80F_6D2BL, > + /* -259 */ 0x6267_0BD9_CC88_3E11L, 0x32D5_43ED_0E13_4875L, > + /* -258 */ 0x7B00_CED0_3FAA_4D95L, 0x5F8A_94E8_5198_1A93L, > + /* -257 */ 0x4CE0_8142_27CA_707DL, 0x4BB6_9D11_32FF_109CL, > + /* -256 */ 0x6018_A192_B1BD_0C9CL, 0x7EA4_4455_7FBE_D4C3L, > + /* -255 */ 0x781E_C9F7_5E2C_4FC4L, 0x1E4D_556A_DFAE_89F3L, > + /* -254 */ 0x4B13_3E3A_9ADB_B1DAL, 0x52F0_5562_CBCD_1638L, > + /* -253 */ 0x5DD8_0DC9_4192_9E51L, 0x27AC_6ABB_7EC0_5BC6L, > + /* -252 */ 0x754E_113B_91F7_45E5L, 0x5197_856A_5E70_72B8L, > + /* -251 */ 0x4950_CAC5_3B3A_8BAFL, 0x42FE_B362_7B06_47B3L, > + /* -250 */ 0x5BA4_FD76_8A09_2E9BL, 0x33BE_603B_19C7_D99FL, > + /* -249 */ 0x728E_3CD4_2C8B_7A42L, 0x20AD_F849_E039_D007L, > + /* -248 */ 0x4798_E604_9BD7_2C69L, 0x346C_BB2E_2C24_2205L, > + /* -247 */ 0x597F_1F85_C2CC_F783L, 0x6187_E9F9_B72D_2A86L, > + /* -246 */ 0x6FDE_E767_3380_3564L, 0x59E9_E478_24F8_7527L, > + /* -245 */ 0x45EB_50A0_8030_215EL, 0x7832_2ECB_171B_4939L, > + /* -244 */ 0x5766_24C8_A03C_29B6L, 0x563E_BA7D_DCE2_1B87L, > + /* -243 */ 0x6D3F_ADFA_C84B_3424L, 0x2BCE_691D_541A_A268L, > + /* -242 */ 0x4447_CCBC_BD2F_0096L, 0x5B61_01B2_5490_A581L, > + /* -241 */ 0x5559_BFEB_EC7A_C0BCL, 0x3239_421E_E9B4_CEE1L, > + /* -240 */ 0x6AB0_2FE6_E799_70EBL, 0x3EC7_92A6_A422_029AL, > + /* -239 */ 0x42AE_1DF0_50BF_E693L, 0x173C_BBA8_2695_41A0L, > + /* -238 */ 0x5359_A56C_64EF_E037L, 0x7D0B_EA92_303A_9208L, > + /* -237 */ 0x6830_0EC7_7E2B_D845L, 0x7C4E_E536_BC49_368AL, > + /* -236 */ 0x411E_093C_AEDB_672BL, 0x5DB1_4F42_35AD_C217L, > + /* -235 */ 0x5165_8B8B_DA92_40F6L, 0x551D_A312_C319_329CL, > + /* -234 */ 0x65BE_EE6E_D136_D134L, 0x2A65_0BD7_73DF_7F43L, > + /* -233 */ 0x7F2E_AA0A_8584_8581L, 0x34FE_4ECD_50D7_5F14L, > + /* -232 */ 0x4F7D_2A46_9372_D370L, 0x711E_F140_5286_9B6CL, > + /* -231 */ 0x635C_74D8_384F_884DL, 0x0D66_AD90_6728_4247L, > + /* -230 */ 0x7C33_920E_4663_6A60L, 0x30C0_58F4_80F2_52D9L, > + /* -229 */ 0x4DA0_3B48_EBFE_227CL, 0x1E78_3798_D097_73C8L, > + /* -228 */ 0x6108_4A1B_26FD_AB1BL, 0x2616_457F_04BD_50BAL, > + /* -227 */ 0x794A_5CA1_F0BD_15E2L, 0x0F9B_D6DE_C5EC_A4E8L, > + /* -226 */ 0x4BCE_79E5_3676_2DADL, 0x29C1_664B_3BB3_E711L, > + /* -225 */ 0x5EC2_185E_8413_B918L, 0x5431_BFDE_0AA0_E0D5L, > + /* -224 */ 0x7672_9E76_2518_A75EL, 0x693E_2FD5_8D49_190BL, > + /* -223 */ 0x4A07_A309_D72F_689BL, 0x21C6_DDE5_784D_AFA7L, > + /* -222 */ 0x5C89_8BCC_4CFB_42C2L, 0x0A38_955E_D661_1B90L, > + /* -221 */ 0x73AB_EEBF_603A_1372L, 0x4CC6_BAB6_8BF9_6274L, > + /* -220 */ 0x484B_7537_9C24_4C27L, 0x4FFC_34B2_177B_DD89L, > + /* -219 */ 0x5A5E_5285_832D_5F31L, 0x43FB_41DE_9D5A_D4EBL, > + /* -218 */ 0x70F5_E726_E3F8_B6FDL, 0x74FA_1256_44B1_8A26L, > + /* -217 */ 0x4699_B078_4E7B_725EL, 0x591C_4B75_EAEE_F658L, > + /* -216 */ 0x5840_1C96_621A_4EF6L, 0x2F63_5E53_65AA_B3EDL, > + /* -215 */ 0x6E50_23BB_FAA0_E2B3L, 0x7B3C_35E8_3F15_60E9L, > + /* -214 */ 0x44F2_1655_7CA4_8DB0L, 0x3D05_A1B1_276D_5C92L, > + /* -213 */ 0x562E_9BEA_DBCD_B11CL, 0x4C47_0A1D_7148_B3B6L, > + /* -212 */ 0x6BBA_42E5_92C1_1D63L, 0x5F58_CCA4_CD9A_E0A3L, > + /* -211 */ 0x4354_69CF_7BB8_B25EL, 0x2B97_7FE7_0080_CC66L, > + /* -210 */ 0x5429_8443_5AA6_DEF5L, 0x767D_5FE0_C0A0_FF80L, > + /* -209 */ 0x6933_E554_3150_96B3L, 0x341C_B7D8_F0C9_3F5FL, > + /* -208 */ 0x41C0_6F54_9ED2_5E30L, 0x1091_F2E7_967D_C79CL, > + /* -207 */ 0x5230_8B29_C686_F5BCL, 0x14B6_6FA1_7C1D_3983L, > + /* -206 */ 0x66BC_ADF4_3828_B32BL, 0x19E4_0B89_DB24_87E3L, > + /* -205 */ 0x4035_ECB8_A319_6FFBL, 0x002E_8736_28F6_D4EEL, > + /* -204 */ 0x5043_67E6_CBDF_CBF9L, 0x603A_2903_B334_8A2AL, > + /* -203 */ 0x6454_41E0_7ED7_BEF8L, 0x1848_B344_A001_ACB4L, > + /* -202 */ 0x7D69_5258_9E8D_AEB6L, 0x1E5A_E015_C802_17E1L, > + /* -201 */ 0x4E61_D377_6318_8D31L, 0x72F8_CC0D_9D01_4EEDL, > + /* -200 */ 0x61FA_4855_3BDE_B07EL, 0x2FB6_FF11_0441_A2A8L, > + /* -199 */ 0x7A78_DA6A_8AD6_5C9DL, 0x7BA4_BED5_4552_0B52L, > + /* -198 */ 0x4C8B_8882_96C5_F9E2L, 0x5D46_F745_4B53_4713L, > + /* -197 */ 0x5FAE_6AA3_3C77_785BL, 0x3498_B516_9E28_18D8L, > + /* -196 */ 0x779A_054C_0B95_5672L, 0x21BE_E25C_45B2_1F0EL, > + /* -195 */ 0x4AC0_434F_873D_5607L, 0x3517_4D79_AB8F_5369L, > + /* -194 */ 0x5D70_5423_690C_AB89L, 0x225D_20D8_1673_2843L, > + /* -193 */ 0x74CC_692C_434F_D66BL, 0x4AF4_690E_1C0F_F253L, > + /* -192 */ 0x48FF_C1BB_AA11_E603L, 0x1ED8_C1A8_D189_F774L, > + /* -191 */ 0x5B3F_B22A_9496_5F84L, 0x068E_F213_05EC_7551L, > + /* -190 */ 0x720F_9EB5_39BB_F765L, 0x0832_AE97_C767_92A5L, > + /* -189 */ 0x4749_C331_4415_7A9FL, 0x151F_AD1E_DCA0_BBA8L, > + /* -188 */ 0x591C_33FD_951A_D946L, 0x7A67_9866_93C8_EA91L, > + /* -187 */ 0x6F63_40FC_FA61_8F98L, 0x5901_7E80_38BB_2536L, > + /* -186 */ 0x459E_089E_1C7C_F9BFL, 0x37A0_EF10_2374_F742L, > + /* -185 */ 0x5705_8AC5_A39C_382FL, 0x2589_2AD4_2C52_3512L, > + /* -184 */ 0x6CC6_ED77_0C83_463BL, 0x0EEB_7589_3766_C256L, > + /* -183 */ 0x43FC_546A_67D2_0BE4L, 0x7953_2975_C2A0_3976L, > + /* -182 */ 0x54FB_6985_01C6_8EDEL, 0x17A7_F3D3_3348_47D4L, > + /* -181 */ 0x6A3A_43E6_4238_3295L, 0x5D91_F0C8_001A_59C8L, > + /* -180 */ 0x4264_6A6F_E963_1F9DL, 0x4A7B_367D_0010_781DL, > + /* -179 */ 0x52FD_850B_E3BB_E784L, 0x7D1A_041C_4014_9625L, > + /* -178 */ 0x67BC_E64E_DCAA_E166L, 0x1C60_8523_5019_BBAEL, > + /* -177 */ 0x40D6_0FF1_49EA_CCDFL, 0x71BC_5336_1210_154DL, > + /* -176 */ 0x510B_93ED_9C65_8017L, 0x6E2B_6803_9694_1AA0L, > + /* -175 */ 0x654E_78E9_037E_E01DL, 0x69B6_4204_7C39_2148L, > + /* -174 */ 0x7EA2_1723_445E_9825L, 0x2423_D285_9B47_6999L, > + /* -173 */ 0x4F25_4E76_0ABB_1F17L, 0x2696_6393_810C_A200L, > + /* -172 */ 0x62EE_A213_8D69_E6DDL, 0x103B_FC78_614F_CA80L, > + /* -171 */ 0x7BAA_4A98_70C4_6094L, 0x344A_FB96_79A3_BD20L, > + /* -170 */ 0x4D4A_6E9F_467A_BC5CL, 0x60AE_DD3E_0C06_5634L, > + /* -169 */ 0x609D_0A47_1819_6B73L, 0x78DA_948D_8F07_EBC1L, > + /* -168 */ 0x78C4_4CD8_DE1F_C650L, 0x7711_39B0_F2C9_E6B1L, > + /* -167 */ 0x4B7A_B007_8AD3_DBF2L, 0x4A6A_C40E_97BE_302FL, > + /* -166 */ 0x5E59_5C09_6D88_D2EFL, 0x1D05_7512_3DAD_BC3AL, > + /* -165 */ 0x75EF_B30B_C8EB_07ABL, 0x0446_D256_CD19_2B49L, > + /* -164 */ 0x49B5_CFE7_5D92_E4CAL, 0x72AC_4376_402F_BB0EL, > + /* -163 */ 0x5C23_43E1_34F7_9DFDL, 0x4F57_5453_D03B_A9D1L, > + /* -162 */ 0x732C_14D9_8235_857DL, 0x032D_2968_C44A_9445L, > + /* -161 */ 0x47FB_8D07_F161_736EL, 0x11FC_39E1_7AAE_9CABL, > + /* -160 */ 0x59FA_7049_EDB9_D049L, 0x567B_4859_D95A_43D6L, > + /* -159 */ 0x7079_0C5C_6928_445CL, 0x0C1A_1A70_4FB0_D4CCL, > + /* -158 */ 0x464B_A7B9_C1B9_2AB9L, 0x4790_5086_31CE_84FFL, > + /* -157 */ 0x57DE_91A8_3227_7567L, 0x7974_64A7_BE42_263FL, > + /* -156 */ 0x6DD6_3612_3EB1_52C1L, 0x77D1_7DD1_ADD2_AFCFL, > + /* -155 */ 0x44A5_E1CB_672E_D3B9L, 0x1AE2_EEA3_0CA3_ADE1L, > + /* -154 */ 0x55CF_5A3E_40FA_88A7L, 0x419B_AA4B_CFCC_995AL, > + /* -153 */ 0x6B43_30CD_D139_2AD1L, 0x3202_94DE_C3BF_BFB0L, > + /* -152 */ 0x4309_FE80_A2C3_BAC2L, 0x6F41_9D0B_3A57_D7CEL, > + /* -151 */ 0x53CC_7E20_CB74_A973L, 0x4B12_044E_08ED_CDC2L, > + /* -150 */ 0x68BF_9DA8_FE51_D3D0L, 0x3DD6_8561_8B29_4132L, > + /* -149 */ 0x4177_C289_9EF3_2462L, 0x26A6_135C_F6F9_C8BFL, > + /* -148 */ 0x51D5_B32C_06AF_ED7AL, 0x704F_9834_34B8_3AEFL, > + /* -147 */ 0x664B_1FF7_085B_E8D9L, 0x4C63_7E41_41E6_49ABL, > + /* -146 */ 0x7FDD_E7F4_CA72_E30FL, 0x7F7C_5DD1_925F_DC15L, > + /* -145 */ 0x4FEA_B0F8_FE87_CDE9L, 0x7FAD_BAA2_FB7B_E98DL, > + /* -144 */ 0x63E5_5D37_3E29_C164L, 0x3F99_294B_BA5A_E3F1L, > + /* -143 */ 0x7CDE_B485_0DB4_31BDL, 0x4F7F_739E_A8F1_9CEDL, > + /* -142 */ 0x4E0B_30D3_2890_9F16L, 0x41AF_A843_2997_0214L, > + /* -141 */ 0x618D_FD07_F2B4_C6DCL, 0x121B_9253_F3FC_C299L, > + /* -140 */ 0x79F1_7C49_EF61_F893L, 0x16A2_76E8_F0FB_F33FL, > + /* -139 */ 0x4C36_EDAE_359D_3B5BL, 0x7E25_8A51_969D_7808L, > + /* -138 */ 0x5F44_A919_C304_8A32L, 0x7DAE_ECE5_FC44_D609L, > + /* -137 */ 0x7715_D360_33C5_ACBFL, 0x5D1A_A81F_7B56_0B8CL, > + /* -136 */ 0x4A6D_A41C_205B_8BF7L, 0x6A30_A913_AD15_C738L, > + /* -135 */ 0x5D09_0D23_2872_6EF5L, 0x64BC_D358_985B_3905L, > + /* -134 */ 0x744B_506B_F28F_0AB3L, 0x1DEC_082E_BE72_0746L, > + /* -133 */ 0x48AF_1243_7799_66B0L, 0x02B3_851D_3707_448CL, > + /* -132 */ 0x5ADA_D6D4_557F_C05CL, 0x0360_6664_84C9_15AFL, > + /* -131 */ 0x7191_8C89_6ADF_B073L, 0x0438_7FFD_A5FB_5B1BL, > + /* -130 */ 0x46FA_F7D5_E2CB_CE47L, 0x72A3_4FFE_87BD_18F1L, > + /* -129 */ 0x58B9_B5CB_5B7E_C1D9L, 0x6F4C_23FE_29AC_5F2DL, > + /* -128 */ 0x6EE8_233E_325E_7250L, 0x2B1F_2CFD_B417_76F8L, > + /* -127 */ 0x4551_1606_DF7B_0772L, 0x1AF3_7C1E_908E_AA5BL, > + /* -126 */ 0x56A5_5B88_9759_C94EL, 0x61B0_5B26_34B2_54F2L, > + /* -125 */ 0x6C4E_B26A_BD30_3BA2L, 0x3A1C_71EF_C1DE_EA2EL, > + /* -124 */ 0x43B1_2F82_B63E_2545L, 0x4451_C735_D92B_525DL, > + /* -123 */ 0x549D_7B63_63CD_AE96L, 0x7566_3903_4F76_26F4L, > + /* -122 */ 0x69C4_DA3C_3CC1_1A3CL, 0x52BF_C744_2353_B0B1L, > + /* -121 */ 0x421B_0865_A5F8_B065L, 0x73B7_DC8A_9614_4E6FL, > + /* -120 */ 0x52A1_CA7F_0F76_DC7FL, 0x30A5_D3AD_3B99_620BL, > + /* -119 */ 0x674A_3D1E_D354_939FL, 0x1CCF_4898_8A7F_BA8DL, > + /* -118 */ 0x408E_6633_4414_DC43L, 0x4201_8D5F_568F_D498L, > + /* -117 */ 0x50B1_FFC0_151A_1354L, 0x3281_F0B7_2C33_C9BEL, > + /* -116 */ 0x64DE_7FB0_1A60_9829L, 0x3F22_6CE4_F740_BC2EL, > + /* -115 */ 0x7E16_1F9C_20F8_BE33L, 0x6EEB_081E_3510_EB39L, > + /* -114 */ 0x4ECD_D3C1_949B_76E0L, 0x3552_E512_E12A_9304L, > + /* -113 */ 0x6281_48B1_F9C2_5498L, 0x42A7_9E57_9975_37C5L, > + /* -112 */ 0x7B21_9ADE_7832_E9BEL, 0x5351_85ED_7FD2_85B6L, > + /* -111 */ 0x4CF5_00CB_0B1F_D217L, 0x1412_F3B4_6FE3_9392L, > + /* -110 */ 0x6032_40FD_CDE7_C69CL, 0x7917_B0A1_8BDC_7876L, > + /* -109 */ 0x783E_D13D_4161_B844L, 0x175D_9CC9_EED3_9694L, > + /* -108 */ 0x4B27_42C6_48DD_132AL, 0x4E9A_81FE_3544_3E1CL, > + /* -107 */ 0x5DF1_1377_DB14_57F5L, 0x2241_227D_C295_4DA3L, > + /* -106 */ 0x756D_5855_D1D9_6DF2L, 0x4AD1_6B1D_333A_A10CL, > + /* -105 */ 0x4964_5735_A327_E4B7L, 0x4EC2_E2F2_4004_A4A8L, > + /* -104 */ 0x5BBD_6D03_0BF1_DDE5L, 0x4273_9BAE_D005_CDD2L, > + /* -103 */ 0x72AC_C843_CEEE_555EL, 0x7310_829A_8407_4146L, > + /* -102 */ 0x47AB_FD2A_6154_F55BL, 0x27EA_51A0_9284_88CCL, > + /* -101 */ 0x5996_FC74_F9AA_32B2L, 0x11E4_E608_B725_AAFFL, > + /* -100 */ 0x6FFC_BB92_3814_BF5EL, 0x565E_1F8A_E4EF_15BEL, > + /* -99 */ 0x45FD_F53B_630C_F79BL, 0x15FA_D3B6_CF15_6D97L, > + /* -98 */ 0x577D_728A_3BD0_3581L, 0x7B79_88A4_82DA_C8FDL, > + /* -97 */ 0x6D5C_CF2C_CAC4_42E2L, 0x3A57_EACD_A391_7B3CL, > + /* -96 */ 0x445A_017B_FEBA_A9CDL, 0x4476_F2C0_863A_ED06L, > + /* -95 */ 0x5570_81DA_FE69_5440L, 0x7594_AF70_A7C9_A847L, > + /* -94 */ 0x6ACC_A251_BE03_A951L, 0x12F9_DB4C_D1BC_1258L, > + /* -93 */ 0x42BF_E573_16C2_49D2L, 0x5BDC_2910_0315_8B77L, > + /* -92 */ 0x536F_DECF_DC72_DC47L, 0x32D3_3354_03DA_EE55L, > + /* -91 */ 0x684B_D683_D38F_9359L, 0x1F88_0029_04D1_A9EAL, > + /* -90 */ 0x412F_6612_6439_BC17L, 0x63B5_0019_A303_0A33L, > + /* -89 */ 0x517B_3F96_FD48_2B1DL, 0x5CA2_4020_0BC3_CCBFL, > + /* -88 */ 0x65DA_0F7C_BC9A_35E5L, 0x13CA_D028_0EB4_BFEFL, > + /* -87 */ 0x7F50_935B_EBC0_C35EL, 0x38BD_8432_1261_EFEBL, > + /* -86 */ 0x4F92_5C19_7358_7A1BL, 0x0376_729F_4B7D_35F3L, > + /* -85 */ 0x6376_F31F_D02E_98A1L, 0x6454_0F47_1E5C_836FL, > + /* -84 */ 0x7C54_AFE7_C43A_3ECAL, 0x1D69_1318_E5F3_A44BL, > + /* -83 */ 0x4DB4_EDF0_DAA4_673EL, 0x3261_ABEF_8FB8_46AFL, > + /* -82 */ 0x6122_296D_114D_810DL, 0x7EFA_16EB_73A6_585BL, > + /* -81 */ 0x796A_B3C8_55A0_E151L, 0x3EB8_9CA6_508F_EE71L, > + /* -80 */ 0x4BE2_B05D_3584_8CD2L, 0x7733_61E7_F259_F507L, > + /* -79 */ 0x5EDB_5C74_82E5_B007L, 0x5500_3A61_EEF0_7249L, > + /* -78 */ 0x7692_3391_A39F_1C09L, 0x4A40_48FA_6AAC_8EDBL, > + /* -77 */ 0x4A1B_603B_0643_7185L, 0x7E68_2D9C_82AB_D949L, > + /* -76 */ 0x5CA2_3849_C7D4_4DE7L, 0x3E02_3903_A356_CF9BL, > + /* -75 */ 0x73CA_C65C_39C9_6161L, 0x2D82_C744_8C2C_8382L, > + /* -74 */ 0x485E_BBF9_A41D_DCDCL, 0x6C71_BC8A_D79B_D231L, > + /* -73 */ 0x5A76_6AF8_0D25_5414L, 0x078E_2BAD_8D82_C6BDL, > + /* -72 */ 0x7114_05B6_106E_A919L, 0x0971_B698_F0E3_786DL, > + /* -71 */ 0x46AC_8391_CA45_29AFL, 0x55E7_121F_968E_2B44L, > + /* -70 */ 0x5857_A476_3CD6_741BL, 0x4B60_D6A7_7C31_B615L, > + /* -69 */ 0x6E6D_8D93_CC0C_1122L, 0x3E39_0C51_5B3E_239AL, > + /* -68 */ 0x4504_787C_5F87_8AB5L, 0x46E3_A7B2_D906_D640L, > + /* -67 */ 0x5645_969B_7769_6D62L, 0x789C_919F_8F48_8BD0L, > + /* -66 */ 0x6BD6_FC42_5543_C8BBL, 0x56C3_B607_731A_AEC4L, > + /* -65 */ 0x4366_5DA9_754A_5D75L, 0x263A_51C4_A7F0_AD3BL, > + /* -64 */ 0x543F_F513_D29C_F4D2L, 0x4FC8_E635_D1EC_D88AL, > + /* -63 */ 0x694F_F258_C744_3207L, 0x23BB_1FC3_4668_0EACL, > + /* -62 */ 0x41D1_F777_7C8A_9F44L, 0x4654_F3DA_0C01_092CL, > + /* -61 */ 0x5246_7555_5BAD_4715L, 0x57EA_30D0_8F01_4B76L, > + /* -60 */ 0x66D8_12AA_B298_98DBL, 0x0DE4_BD04_B2C1_9E54L, > + /* -59 */ 0x4047_0BAA_AF9F_5F88L, 0x78AE_F622_EFB9_02F5L, > + /* -58 */ 0x5058_CE95_5B87_376BL, 0x16DA_B3AB_ABA7_43B2L, > + /* -57 */ 0x646F_023A_B269_0545L, 0x7C91_6096_9691_149EL, > + /* -56 */ 0x7D8A_C2C9_5F03_4697L, 0x3BB5_B8BC_3C35_59C5L, > + /* -55 */ 0x4E76_B9BD_DB62_0C1EL, 0x5551_9375_A5A1_581BL, > + /* -54 */ 0x6214_682D_523A_8F26L, 0x2AA5_F853_0F09_AE22L, > + /* -53 */ 0x7A99_8238_A6C9_32EFL, 0x754F_7667_D2CC_19ABL, > + /* -52 */ 0x4C9F_F163_683D_BFD5L, 0x7951_AA00_E3BF_900BL, > + /* -51 */ 0x5FC7_EDBC_424D_2FCBL, 0x37A6_1481_1CAF_740DL, > + /* -50 */ 0x77B9_E92B_52E0_7BBEL, 0x258F_99A1_63DB_5111L, > + /* -49 */ 0x4AD4_31BB_13CC_4D56L, 0x7779_C004_DE69_12ABL, > + /* -48 */ 0x5D89_3E29_D8BF_60ACL, 0x5558_3006_1603_5755L, > + /* -47 */ 0x74EB_8DB4_4EEF_38D7L, 0x6AAE_3C07_9B84_2D2AL, > + /* -46 */ 0x4913_3890_B155_8386L, 0x72AC_E584_C132_9C3BL, > + /* -45 */ 0x5B58_06B4_DDAA_E468L, 0x4F58_1EE5_F17F_4349L, > + /* -44 */ 0x722E_0862_1515_9D82L, 0x632E_269F_6DDF_141BL, > + /* -43 */ 0x475C_C53D_4D2D_8271L, 0x5DFC_D823_A4AB_6C91L, > + /* -42 */ 0x5933_F68C_A078_E30EL, 0x157C_0E2C_8DD6_47B5L, > + /* -41 */ 0x6F80_F42F_C897_1BD1L, 0x5ADB_11B7_B14B_D9A3L, > + /* -40 */ 0x45B0_989D_DD5E_7163L, 0x08C8_EB12_CECF_6806L, > + /* -39 */ 0x571C_BEC5_54B6_0DBBL, 0x6AFB_25D7_8283_4207L, > + /* -38 */ 0x6CE3_EE76_A9E3_912AL, 0x65B9_EF4D_6324_1289L, > + /* -37 */ 0x440E_750A_2A2E_3ABAL, 0x5F94_3590_5DF6_8B96L, > + /* -36 */ 0x5512_124C_B4B9_C969L, 0x3779_42F4_7574_2E7BL, > + /* -35 */ 0x6A56_96DF_E1E8_3BC3L, 0x6557_93B1_92D1_3A1AL, > + /* -34 */ 0x4276_1E4B_ED31_255AL, 0x2F56_BC4E_FBC2_C450L, > + /* -33 */ 0x5313_A5DE_E87D_6EB0L, 0x7B2C_6B62_BAB3_7564L, > + /* -32 */ 0x67D8_8F56_A29C_CA5DL, 0x19F7_863B_6960_52BDL, > + /* -31 */ 0x40E7_5996_25A1_FE7AL, 0x203A_B3E5_21DC_33B6L, > + /* -30 */ 0x5121_2FFB_AF0A_7E18L, 0x6849_60DE_6A53_40A4L, > + /* -29 */ 0x6569_7BFA_9ACD_1D9FL, 0x025B_B916_04E8_10CDL, > + /* -28 */ 0x7EC3_DAF9_4180_6506L, 0x62F2_A75B_8622_1500L, > + /* -27 */ 0x4F3A_68DB_C8F0_3F24L, 0x1DD7_A899_33D5_4D20L, > + /* -26 */ 0x6309_0312_BB2C_4EEDL, 0x254D_92BF_80CA_A068L, > + /* -25 */ 0x7BCB_43D7_69F7_62A8L, 0x4EA0_F76F_60FD_4882L, > + /* -24 */ 0x4D5F_0A66_A23A_9DA9L, 0x3124_9AA5_9C9E_4D51L, > + /* -23 */ 0x60B6_CD00_4AC9_4513L, 0x5D6D_C14F_03C5_E0A5L, > + /* -22 */ 0x78E4_8040_5D7B_9658L, 0x54C9_31A2_C4B7_58CFL, > + /* -21 */ 0x4B8E_D028_3A6D_3DF7L, 0x34FD_BF05_BAF2_9781L, > + /* -20 */ 0x5E72_8432_4908_8D75L, 0x223D_2EC7_29AF_3D62L, > + /* -19 */ 0x760F_253E_DB4A_B0D2L, 0x4ACC_7A78_F41B_0CBAL, > + /* -18 */ 0x49C9_7747_490E_AE83L, 0x4EBF_CC8B_9890_E7F4L, > + /* -17 */ 0x5C3B_D519_1B52_5A24L, 0x426F_BFAE_7EB5_21F1L, > + /* -16 */ 0x734A_CA5F_6226_F0ADL, 0x530B_AF9A_1E62_6A6DL, > + /* -15 */ 0x480E_BE7B_9D58_566CL, 0x43E7_4DC0_52FD_8285L, > + /* -14 */ 0x5A12_6E1A_84AE_6C07L, 0x54E1_2130_67BC_E326L, > + /* -13 */ 0x7097_09A1_25DA_0709L, 0x4A19_697C_81AC_1BEFL, > + /* -12 */ 0x465E_6604_B7A8_4465L, 0x7E4F_E1ED_D10B_9175L, > + /* -11 */ 0x57F5_FF85_E592_557FL, 0x3DE3_DA69_454E_75D3L, > + /* -10 */ 0x6DF3_7F67_5EF6_EADFL, 0x2D5C_D103_96A2_1347L, > + /* -9 */ 0x44B8_2FA0_9B5A_52CBL, 0x4C5A_02A2_3E25_4C0DL, > + /* -8 */ 0x55E6_3B88_C230_E77EL, 0x3F70_834A_CDAE_9F10L, > + /* -7 */ 0x6B5F_CA6A_F2BD_215EL, 0x0F4C_A41D_811A_46D4L, > + /* -6 */ 0x431B_DE82_D7B6_34DAL, 0x698F_E692_70B0_6C44L, > + /* -5 */ 0x53E2_D623_8DA3_C211L, 0x43F3_E037_0CDC_8755L, > + /* -4 */ 0x68DB_8BAC_710C_B295L, 0x74F0_D844_D013_A92BL, > + /* -3 */ 0x4189_374B_C6A7_EF9DL, 0x5916_872B_020C_49BBL, > + /* -2 */ 0x51EB_851E_B851_EB85L, 0x0F5C_28F5_C28F_5C29L, > + /* -1 */ 0x6666_6666_6666_6666L, 0x3333_3333_3333_3334L, > + /* 0 */ 0x4000_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 1 */ 0x5000_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 2 */ 0x6400_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 3 */ 0x7D00_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 4 */ 0x4E20_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 5 */ 0x61A8_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 6 */ 0x7A12_0000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 7 */ 0x4C4B_4000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 8 */ 0x5F5E_1000_0000_0000L, 0x0000_0000_0000_0000L, > + /* 9 */ 0x7735_9400_0000_0000L, 0x0000_0000_0000_0000L, > + /* 10 */ 0x4A81_7C80_0000_0000L, 0x0000_0000_0000_0000L, > + /* 11 */ 0x5D21_DBA0_0000_0000L, 0x0000_0000_0000_0000L, > + /* 12 */ 0x746A_5288_0000_0000L, 0x0000_0000_0000_0000L, > + /* 13 */ 0x48C2_7395_0000_0000L, 0x0000_0000_0000_0000L, > + /* 14 */ 0x5AF3_107A_4000_0000L, 0x0000_0000_0000_0000L, > + /* 15 */ 0x71AF_D498_D000_0000L, 0x0000_0000_0000_0000L, > + /* 16 */ 0x470D_E4DF_8200_0000L, 0x0000_0000_0000_0000L, > + /* 17 */ 0x58D1_5E17_6280_0000L, 0x0000_0000_0000_0000L, > + /* 18 */ 0x6F05_B59D_3B20_0000L, 0x0000_0000_0000_0000L, > + /* 19 */ 0x4563_9182_44F4_0000L, 0x0000_0000_0000_0000L, > + /* 20 */ 0x56BC_75E2_D631_0000L, 0x0000_0000_0000_0000L, > + /* 21 */ 0x6C6B_935B_8BBD_4000L, 0x0000_0000_0000_0000L, > + /* 22 */ 0x43C3_3C19_3756_4800L, 0x0000_0000_0000_0000L, > + /* 23 */ 0x54B4_0B1F_852B_DA00L, 0x0000_0000_0000_0000L, > + /* 24 */ 0x69E1_0DE7_6676_D080L, 0x0000_0000_0000_0000L, > + /* 25 */ 0x422C_A8B0_A00A_4250L, 0x0000_0000_0000_0000L, > + /* 26 */ 0x52B7_D2DC_C80C_D2E4L, 0x0000_0000_0000_0000L, > + /* 27 */ 0x6765_C793_FA10_079DL, 0x0000_0000_0000_0000L, > + /* 28 */ 0x409F_9CBC_7C4A_04C2L, 0x1000_0000_0000_0000L, > + /* 29 */ 0x50C7_83EB_9B5C_85F2L, 0x5400_0000_0000_0000L, > + /* 30 */ 0x64F9_64E6_8233_A76FL, 0x2900_0000_0000_0000L, > + /* 31 */ 0x7E37_BE20_22C0_914BL, 0x1340_0000_0000_0000L, > + /* 32 */ 0x4EE2_D6D4_15B8_5ACEL, 0x7C08_0000_0000_0000L, > + /* 33 */ 0x629B_8C89_1B26_7182L, 0x5B0A_0000_0000_0000L, > + /* 34 */ 0x7B42_6FAB_61F0_0DE3L, 0x31CC_8000_0000_0000L, > + /* 35 */ 0x4D09_85CB_1D36_08AEL, 0x0F1F_D000_0000_0000L, > + /* 36 */ 0x604B_E73D_E483_8AD9L, 0x52E7_C400_0000_0000L, > + /* 37 */ 0x785E_E10D_5DA4_6D90L, 0x07A1_B500_0000_0000L, > + /* 38 */ 0x4B3B_4CA8_5A86_C47AL, 0x04C5_1120_0000_0000L, > + /* 39 */ 0x5E0A_1FD2_7128_7598L, 0x45F6_5568_0000_0000L, > + /* 40 */ 0x758C_A7C7_0D72_92FEL, 0x5773_EAC2_0000_0000L, > + /* 41 */ 0x4977_E8DC_6867_9BDFL, 0x16A8_72B9_4000_0000L, > + /* 42 */ 0x5BD5_E313_8281_82D6L, 0x7C52_8F67_9000_0000L, > + /* 43 */ 0x72CB_5BD8_6321_E38CL, 0x5B67_3341_7400_0000L, > + /* 44 */ 0x47BF_1967_3DF5_2E37L, 0x7920_8008_E880_0000L, > + /* 45 */ 0x59AE_DFC1_0D72_79C5L, 0x7768_A00B_22A0_0000L, > + /* 46 */ 0x701A_97B1_50CF_1837L, 0x3542_C80D_EB48_0000L, > + /* 47 */ 0x4610_9ECE_D281_6F22L, 0x5149_BD08_B30D_0000L, > + /* 48 */ 0x5794_C682_8721_CAEBL, 0x259C_2C4A_DFD0_4000L, > + /* 49 */ 0x6D79_F823_28EA_3DA6L, 0x0F03_375D_97C4_5000L, > + /* 50 */ 0x446C_3B15_F992_6687L, 0x6962_029A_7EDA_B200L, > + /* 51 */ 0x5587_49DB_77F7_0029L, 0x63BA_8341_1E91_5E80L, > + /* 52 */ 0x6AE9_1C52_55F4_C034L, 0x1CA9_2411_6635_B620L, > + /* 53 */ 0x42D1_B1B3_75B8_F820L, 0x51E9_B68A_DFE1_91D4L, > + /* 54 */ 0x5386_1E20_5327_3628L, 0x6664_242D_97D9_F649L, > + /* 55 */ 0x6867_A5A8_67F1_03B2L, 0x7FFD_2D38_FDD0_73DCL, > + /* 56 */ 0x4140_C789_40F6_A24FL, 0x6FFE_3C43_9EA2_486AL, > + /* 57 */ 0x5190_F96B_9134_4AE3L, 0x6BFD_CB54_864A_DA84L, > + /* 58 */ 0x65F5_37C6_7581_5D9CL, 0x66FD_3E29_A7DD_9125L, > + /* 59 */ 0x7F72_85B8_12E1_B504L, 0x00BC_8DB4_11D4_F56EL, > + /* 60 */ 0x4FA7_9393_0BCD_1122L, 0x4075_D890_8B25_1965L, > + /* 61 */ 0x6391_7877_CEC0_556BL, 0x1093_4EB4_ADEE_5FBEL, > + /* 62 */ 0x7C75_D695_C270_6AC5L, 0x74B8_2261_D969_F7ADL, > + /* 63 */ 0x4DC9_A61D_9986_42BBL, 0x58F3_157D_27E2_3ACCL, > + /* 64 */ 0x613C_0FA4_FFE7_D36AL, 0x4F2F_DADC_71DA_C97FL, > + /* 65 */ 0x798B_138E_3FE1_C845L, 0x22FB_D193_8E51_7BDFL, > + /* 66 */ 0x4BF6_EC38_E7ED_1D2BL, 0x25DD_62FC_38F2_ED6CL, > + /* 67 */ 0x5EF4_A747_21E8_6476L, 0x0F54_BBBB_472F_A8C6L, > + /* 68 */ 0x76B1_D118_EA62_7D93L, 0x5329_EAAA_18FB_92F8L, > + /* 69 */ 0x4A2F_22AF_927D_8E7CL, 0x23FA_32AA_4F9D_3BDBL, > + /* 70 */ 0x5CBA_EB5B_771C_F21BL, 0x2CF8_BF54_E384_8AD2L, > + /* 71 */ 0x73E9_A632_54E4_2EA2L, 0x1836_EF2A_1C65_AD86L, > + /* 72 */ 0x4872_07DF_750E_9D25L, 0x2F22_557A_51BF_8C74L, > + /* 73 */ 0x5A8E_89D7_5252_446EL, 0x5AEA_EAD8_E62F_6F91L, > + /* 74 */ 0x7132_2C4D_26E6_D58AL, 0x31A5_A58F_1FBB_4B75L, > + /* 75 */ 0x46BF_5BB0_3850_4576L, 0x3F07_8779_73D5_0F29L, > + /* 76 */ 0x586F_329C_4664_56D4L, 0x0EC9_6957_D0CA_52F3L, > + /* 77 */ 0x6E8A_FF43_57FD_6C89L, 0x127B_C3AD_C4FC_E7B0L, > + /* 78 */ 0x4516_DF8A_16FE_63D5L, 0x5B8D_5A4C_9B1E_10CEL, > + /* 79 */ 0x565C_976C_9CBD_FCCBL, 0x1270_B0DF_C1E5_9502L, > + /* 80 */ 0x6BF3_BD47_C3ED_7BFDL, 0x770C_DD17_B25E_FA42L, > + /* 81 */ 0x4378_564C_DA74_6D7EL, 0x5A68_0A2E_CF7B_5C69L, > + /* 82 */ 0x5456_6BE0_1111_88DEL, 0x3102_0CBA_835A_3384L, > + /* 83 */ 0x696C_06D8_1555_EB15L, 0x7D42_8FE9_2430_C065L, > + /* 84 */ 0x41E3_8447_0D55_B2EDL, 0x5E49_99F1_B69E_783FL, > + /* 85 */ 0x525C_6558_D0AB_1FA9L, 0x15DC_006E_2446_164FL, > + /* 86 */ 0x66F3_7EAF_04D5_E793L, 0x3B53_0089_AD57_9BE2L, > + /* 87 */ 0x4058_2F2D_6305_B0BCL, 0x1513_E056_0C56_C16EL, > + /* 88 */ 0x506E_3AF8_BBC7_1CEBL, 0x1A58_D86B_8F6C_71C9L, > + /* 89 */ 0x6489_C9B6_EAB8_E426L, 0x00EF_0E86_7347_8E3BL, > + /* 90 */ 0x7DAC_3C24_A567_1D2FL, 0x412A_D228_1019_71C9L, > + /* 91 */ 0x4E8B_A596_E760_723DL, 0x58BA_C359_0A0F_E71EL, > + /* 92 */ 0x622E_8EFC_A138_8ECDL, 0x0EE9_742F_4C93_E0E6L, > + /* 93 */ 0x7ABA_32BB_C986_B280L, 0x32A3_D13B_1FB8_D91FL, > + /* 94 */ 0x4CB4_5FB5_5DF4_2F90L, 0x1FA6_62C4_F3D3_87B3L, > + /* 95 */ 0x5FE1_77A2_B571_3B74L, 0x278F_FB76_30C8_69A0L, > + /* 96 */ 0x77D9_D58B_62CD_8A51L, 0x3173_FA53_BCFA_8408L, > + /* 97 */ 0x4AE8_2577_1DC0_7672L, 0x6EE8_7C74_561C_9285L, > + /* 98 */ 0x5DA2_2ED4_E530_940FL, 0x4AA2_9B91_6BA3_B726L, > + /* 99 */ 0x750A_BA8A_1E7C_B913L, 0x3D4B_4275_C68C_A4F0L, > + /* 100 */ 0x4926_B496_530D_F3ACL, 0x164F_0989_9C17_E716L, > + /* 101 */ 0x5B70_61BB_E7D1_7097L, 0x1BE2_CBEC_031D_E0DCL, > + /* 102 */ 0x724C_7A2A_E1C5_CCBDL, 0x02DB_7EE7_03E5_5912L, > + /* 103 */ 0x476F_CC5A_CD1B_9FF6L, 0x11C9_2F50_626F_57ACL, > + /* 104 */ 0x594B_BF71_8062_87F3L, 0x563B_7B24_7B0B_2D96L, > + /* 105 */ 0x6F9E_AF4D_E07B_29F0L, 0x4BCA_59ED_99CD_F8FCL, > + /* 106 */ 0x45C3_2D90_AC4C_FA36L, 0x2F5E_7834_8020_BB9EL, > + /* 107 */ 0x5733_F8F4_D760_38C3L, 0x7B36_1641_A028_EA85L, > + /* 108 */ 0x6D00_F732_0D38_46F4L, 0x7A03_9BD2_0833_2526L, > + /* 109 */ 0x4420_9A7F_4843_2C59L, 0x0C42_4163_451F_F738L, > + /* 110 */ 0x5528_C11F_1A53_F76FL, 0x2F52_D1BC_1667_F506L, > + /* 111 */ 0x6A72_F166_E0E8_F54BL, 0x1B27_862B_1C01_F247L, > + /* 112 */ 0x4287_D6E0_4C91_994FL, 0x00F8_B3DA_F181_376DL, > + /* 113 */ 0x5329_CC98_5FB5_FFA2L, 0x6136_E0D1_ADE1_8548L, > + /* 114 */ 0x67F4_3FBE_77A3_7F8BL, 0x3984_9906_1959_E699L, > + /* 115 */ 0x40F8_A7D7_0AC6_2FB7L, 0x13F2_DFA3_CFD8_3020L, > + /* 116 */ 0x5136_D1CC_CD77_BBA4L, 0x78EF_978C_C3CE_3C28L, > + /* 117 */ 0x6584_8640_00D5_AA8EL, 0x172B_7D6F_F4C1_CB32L, > + /* 118 */ 0x7EE5_A7D0_010B_1531L, 0x5CF6_5CCB_F1F2_3DFEL, > + /* 119 */ 0x4F4F_88E2_00A6_ED3FL, 0x0A19_F9FF_7737_66BFL, > + /* 120 */ 0x6323_6B1A_80D0_A88EL, 0x6CA0_787F_5505_406FL, > + /* 121 */ 0x7BEC_45E1_2104_D2B2L, 0x47C8_969F_2A46_908AL, > + /* 122 */ 0x4D73_ABAC_B4A3_03AFL, 0x4CDD_5E23_7A6C_1A57L, > + /* 123 */ 0x60D0_9697_E1CB_C49BL, 0x4014_B5AC_5907_20ECL, > + /* 124 */ 0x7904_BC3D_DA3E_B5C2L, 0x3019_E317_6F48_E927L, > + /* 125 */ 0x4BA2_F5A6_A867_3199L, 0x3E10_2DEE_A58D_91B9L, > + /* 126 */ 0x5E8B_B310_5280_FDFFL, 0x6D94_396A_4EF0_F627L, > + /* 127 */ 0x762E_9FD4_6721_3D7FL, 0x68F9_47C4_E2AD_33B0L, > + /* 128 */ 0x49DD_23E4_C074_C66FL, 0x719B_CCDB_0DAC_404EL, > + /* 129 */ 0x5C54_6CDD_F091_F80BL, 0x6E02_C011_D117_5062L, > + /* 130 */ 0x7369_8815_6CB6_760EL, 0x6983_7016_455D_247AL, > + /* 131 */ 0x4821_F50D_63F2_09C9L, 0x21F2_260D_EB5A_36CCL, > + /* 132 */ 0x5A2A_7250_BCEE_8C3BL, 0x4A6E_AF91_6630_C47FL, > + /* 133 */ 0x70B5_0EE4_EC2A_2F4AL, 0x3D0A_5B75_BFBC_F59FL, > + /* 134 */ 0x4671_294F_139A_5D8EL, 0x4626_7929_97D6_1984L, > + /* 135 */ 0x580D_73A2_D880_F4F2L, 0x17B0_1773_FDCB_9FE4L, > + /* 136 */ 0x6E10_D08B_8EA1_322EL, 0x5D9C_1D50_FD3E_87DDL, > + /* 137 */ 0x44CA_8257_3924_BF5DL, 0x1A81_9252_9E47_14EBL, > + /* 138 */ 0x55FD_22ED_076D_EF34L, 0x4121_F6E7_45D8_DA25L, > + /* 139 */ 0x6B7C_6BA8_4949_6B01L, 0x516A_74A1_174F_10AEL, > + /* 140 */ 0x432D_C349_2DCD_E2E1L, 0x02E2_88E4_AE91_6A6DL, > + /* 141 */ 0x53F9_341B_7941_5B99L, 0x239B_2B1D_DA35_C508L, > + /* 142 */ 0x68F7_8122_5791_B27FL, 0x4C81_F5E5_50C3_364AL, > + /* 143 */ 0x419A_B0B5_76BB_0F8FL, 0x5FD1_39AF_527A_01EFL, > + /* 144 */ 0x5201_5CE2_D469_D373L, 0x57C5_881B_2718_826AL, > + /* 145 */ 0x6681_B41B_8984_4850L, 0x4DB6_EA21_F0DE_A304L, > + /* 146 */ 0x4011_1091_35F2_AD32L, 0x3092_5255_368B_25E3L, > + /* 147 */ 0x5015_54B5_836F_587EL, 0x7CB6_E6EA_842D_EF5CL, > + /* 148 */ 0x641A_A9E2_E44B_2E9EL, 0x5BE4_A0A5_2539_6B32L, > + /* 149 */ 0x7D21_545B_9D5D_FA46L, 0x32DD_C8CE_6E87_C5FFL, > + /* 150 */ 0x4E34_D4B9_425A_BC6BL, 0x7FCA_9D81_0514_DBBFL, > + /* 151 */ 0x61C2_09E7_92F1_6B86L, 0x7FBD_44E1_465A_12AFL, > + /* 152 */ 0x7A32_8C61_77AD_C668L, 0x5FAC_9619_97F0_975BL, > + /* 153 */ 0x4C5F_97BC_EACC_9C01L, 0x3BCB_DDCF_FEF6_5E99L, > + /* 154 */ 0x5F77_7DAC_257F_C301L, 0x6ABE_D543_FEB3_F63FL, > + /* 155 */ 0x7755_5D17_2EDF_B3C2L, 0x256E_8A94_FE60_F3CFL, > + /* 156 */ 0x4A95_5A2E_7D4B_D059L, 0x3765_169D_1EFC_9861L, > + /* 157 */ 0x5D3A_B0BA_1C9E_C46FL, 0x653E_5C44_66BB_BE7AL, > + /* 158 */ 0x7489_5CE8_A3C6_758BL, 0x5E8D_F355_806A_AE18L, > + /* 159 */ 0x48D5_DA11_665C_0977L, 0x2B18_B815_7042_ACCFL, > + /* 160 */ 0x5B0B_5095_BFF3_0BD5L, 0x15DE_E61A_CC53_5803L, > + /* 161 */ 0x71CE_24BB_2FEF_CECAL, 0x3B56_9FA1_7F68_2E03L, > + /* 162 */ 0x4720_D6F4_FDF5_E13EL, 0x4516_23C4_EFA1_1CC2L, > + /* 163 */ 0x58E9_0CB2_3D73_598EL, 0x165B_ACB6_2B89_63F3L, > + /* 164 */ 0x6F23_4FDE_CCD0_2FF1L, 0x5BF2_97E3_B66B_BCEFL, > + /* 165 */ 0x4576_11EB_4002_1DF7L, 0x0977_9EEE_5203_5616L, > + /* 166 */ 0x56D3_9666_1002_A574L, 0x6BD5_86A9_E684_2B9BL, > + /* 167 */ 0x6C88_7BFF_9403_4ED2L, 0x06CA_E854_6025_3682L, > + /* 168 */ 0x43D5_4D7F_BC82_1143L, 0x243E_D134_BC17_4211L, > + /* 169 */ 0x54CA_A0DF_ABA2_9594L, 0x0D4E_8581_EB1D_1295L, > + /* 170 */ 0x69FD_4917_968B_3AF9L, 0x10A2_26E2_65E4_573BL, > + /* 171 */ 0x423E_4DAE_BE17_04DBL, 0x5A65_584D_7FAE_B685L, > + /* 172 */ 0x52CD_E11A_6D9C_C612L, 0x50FE_AE60_DF9A_6426L, > + /* 173 */ 0x6781_5961_0903_F797L, 0x253E_59F9_1780_FD2FL, > + /* 174 */ 0x40B0_D7DC_A5A2_7ABEL, 0x4746_F83B_AEB0_9E3EL, > + /* 175 */ 0x50DD_0DD3_CF0B_196EL, 0x1918_B64A_9A5C_C5CDL, > + /* 176 */ 0x6514_5148_C2CD_DFC9L, 0x5F5E_E3DD_40F3_F740L, > + /* 177 */ 0x7E59_659A_F381_57BCL, 0x1736_9CD4_9130_F510L, > + /* 178 */ 0x4EF7_DF80_D830_D6D5L, 0x4E82_2204_DABE_992AL, > + /* 179 */ 0x62B5_D761_0E3D_0C8BL, 0x0222_AA86_116E_3F75L, > + /* 180 */ 0x7B63_4D39_51CC_4FADL, 0x62AB_5527_95C9_CF52L, > + /* 181 */ 0x4D1E_1043_D31F_B1CCL, 0x4DAB_1538_BD9E_2193L, > + /* 182 */ 0x6065_9454_C7E7_9E3FL, 0x6115_DA86_ED05_A9F8L, > + /* 183 */ 0x787E_F969_F9E1_85CFL, 0x595B_5128_A847_1476L, > + /* 184 */ 0x4B4F_5BE2_3C2C_F3A1L, 0x67D9_12B9_692C_6CCAL, > + /* 185 */ 0x5E23_32DA_CB38_308AL, 0x21CF_5767_C377_87FCL, > + /* 186 */ 0x75AB_FF91_7E06_3CACL, 0x6A43_2D41_B455_69FBL, > + /* 187 */ 0x498B_7FBA_EEC3_E5ECL, 0x0269_FC49_10B5_623DL, > + /* 188 */ 0x5BEE_5FA9_AA74_DF67L, 0x0304_7B5B_54E2_BACCL, > + /* 189 */ 0x72E9_F794_1512_1740L, 0x63C5_9A32_2A1B_697FL, > + /* 190 */ 0x47D2_3ABC_8D2B_4E88L, 0x3E5B_805F_5A51_21F0L, > + /* 191 */ 0x59C6_C96B_B076_222AL, 0x4DF2_6077_30E5_6A6CL, > + /* 192 */ 0x7038_7BC6_9C93_AAB5L, 0x216E_F894_FD1E_C506L, > + /* 193 */ 0x4623_4D5C_21DC_4AB1L, 0x24E5_5B5D_1E33_3B24L, > + /* 194 */ 0x57AC_20B3_2A53_5D5DL, 0x4E1E_B234_65C0_09EDL, > + /* 195 */ 0x6D97_28DF_F4E8_34B5L, 0x01A6_5EC1_7F30_0C68L, > + /* 196 */ 0x447E_798B_F911_20F1L, 0x1107_FB38_EF7E_07C1L, > + /* 197 */ 0x559E_17EE_F755_692DL, 0x3549_FA07_2B5D_89B1L, > + /* 198 */ 0x6B05_9DEA_B52A_C378L, 0x629C_7888_F634_EC1EL, > + /* 199 */ 0x42E3_82B2_B13A_BA2BL, 0x3DA1_CB55_99E1_1393L, > + /* 200 */ 0x539C_635F_5D89_68B6L, 0x2D0A_3E2B_0059_5877L, > + /* 201 */ 0x6883_7C37_34EB_C2E3L, 0x784C_CDB5_C06F_AE95L, > + /* 202 */ 0x4152_2DA2_8113_59CEL, 0x3B30_0091_9845_CD1DL, > + /* 203 */ 0x51A6_B90B_2158_3042L, 0x09FC_00B5_FE57_4065L, > + /* 204 */ 0x6610_674D_E9AE_3C52L, 0x4C7B_00E3_7DED_107EL, > + /* 205 */ 0x7F94_8121_6419_CB67L, 0x1F99_C11C_5D68_549DL, > + /* 206 */ 0x4FBC_D0B4_DE90_1F20L, 0x43C0_18B1_BA61_34E2L, > + /* 207 */ 0x63AC_04E2_1634_26E8L, 0x54B0_1EDE_28F9_821BL, > + /* 208 */ 0x7C97_061A_9BC1_30A2L, 0x69DC_2695_B337_E2A1L, > + /* 209 */ 0x4DDE_63D0_A158_BE65L, 0x6229_981D_9002_EDA5L, > + /* 210 */ 0x6155_FCC4_C9AE_EDFFL, 0x1AB3_FE24_F403_A90EL, > + /* 211 */ 0x79AB_7BF5_FC1A_A97FL, 0x0160_FDAE_3104_9351L, > + /* 212 */ 0x4C0B_2D79_BD90_A9EFL, 0x30DC_9E8C_DEA2_DC13L, > + /* 213 */ 0x5F0D_F8D8_2CF4_D46BL, 0x1D13_C630_164B_9318L, > + /* 214 */ 0x76D1_770E_3832_0986L, 0x0458_B7BC_1BDE_77DDL, > + /* 215 */ 0x4A42_EA68_E31F_45F3L, 0x62B7_72D5_916B_0AEBL, > + /* 216 */ 0x5CD3_A503_1BE7_1770L, 0x5B65_4F8A_F5C5_CDA5L, > + /* 217 */ 0x7408_8E43_E2E0_DD4CL, 0x723E_A36D_B337_410EL, > + /* 218 */ 0x4885_58EA_6DCC_8A50L, 0x0767_2624_9002_88A9L, > + /* 219 */ 0x5AA6_AF25_093F_ACE4L, 0x0940_EFAD_B403_2AD3L, > + /* 220 */ 0x7150_5AEE_4B8F_981DL, 0x0B91_2B99_2103_F588L, > + /* 221 */ 0x46D2_38D4_EF39_BF12L, 0x173A_BB3F_B4A2_7975L, > + /* 222 */ 0x5886_C70A_2B08_2ED6L, 0x5D09_6A0F_A1CB_17D2L, > + /* 223 */ 0x6EA8_78CC_B5CA_3A8CL, 0x344B_C493_8A3D_DDC7L, > + /* 224 */ 0x4529_4B7F_F19E_6497L, 0x60AF_5ADC_3666_AA9CL, > + /* 225 */ 0x5673_9E5F_EE05_FDBDL, 0x58DB_3193_4400_5543L, > + /* 226 */ 0x6C10_85F7_E987_7D2DL, 0x0F11_FDF8_1500_6A94L, > + /* 227 */ 0x438A_53BA_F1F4_AE3CL, 0x196B_3EBB_0D20_429DL, > + /* 228 */ 0x546C_E8A9_AE71_D9CBL, 0x1FC6_0E69_D068_5344L, > + /* 229 */ 0x6988_22D4_1A0E_503EL, 0x07B7_9204_4482_6815L, > + /* 230 */ 0x41F5_15C4_9048_F226L, 0x64D2_BB42_AAD1_810DL, > + /* 231 */ 0x5272_5B35_B45B_2EB0L, 0x3E07_6A13_5585_E150L, > + /* 232 */ 0x670E_F203_2171_FA5CL, 0x4D89_4498_2AE7_59A4L, > + /* 233 */ 0x4069_5741_F4E7_3C79L, 0x7075_CADF_1AD0_9807L, > + /* 234 */ 0x5083_AD12_7221_0B98L, 0x2C93_3D96_E184_BE08L, > + /* 235 */ 0x64A4_9857_0EA9_4E7EL, 0x37B8_0CFC_99E5_ED8AL, > + /* 236 */ 0x7DCD_BE6C_D253_A21EL, 0x05A6_103B_C05F_68EDL, > + /* 237 */ 0x4EA0_9704_0374_4552L, 0x6387_CA25_583B_A194L, > + /* 238 */ 0x6248_BCC5_0451_56A7L, 0x3C69_BCAE_AE4A_89F9L, > + /* 239 */ 0x7ADA_EBF6_4565_AC51L, 0x2B84_2BDA_59DD_2C77L, > + /* 240 */ 0x4CC8_D379_EB5F_8BB2L, 0x6B32_9B68_782A_3BCBL, > + /* 241 */ 0x5FFB_0858_6637_6E9FL, 0x45FF_4242_9634_CABDL, > + /* 242 */ 0x77F9_CA6E_7FC5_4A47L, 0x377F_12D3_3BC1_FD6DL, > + /* 243 */ 0x4AFC_1E85_0FDB_4E6CL, 0x52AF_6BC4_0559_3E64L, > + /* 244 */ 0x5DBB_2626_53D2_2207L, 0x675B_46B5_06AF_8DFDL, > + /* 245 */ 0x7529_EFAF_E8C6_AA89L, 0x6132_1862_485B_717CL, > + /* 246 */ 0x493A_35CD_F17C_2A96L, 0x0CBF_4F3D_6D39_26EEL, > + /* 247 */ 0x5B88_C341_6DDB_353BL, 0x4FEF_230C_C887_70A9L, > + /* 248 */ 0x726A_F411_C952_028AL, 0x43EA_EBCF_FAA9_4CD3L, > + /* 249 */ 0x4782_D88B_1DD3_4196L, 0x4A72_D361_FCA9_D004L, > + /* 250 */ 0x5963_8EAD_E548_11FCL, 0x1D0F_883A_7BD4_4405L, > + /* 251 */ 0x6FBC_7259_5E9A_167BL, 0x2453_6A49_1AC9_5506L, > + /* 252 */ 0x45D5_C777_DB20_4E0DL, 0x06B4_226D_B0BD_D524L, > + /* 253 */ 0x574B_3955_D1E8_6190L, 0x2861_2B09_1CED_4A6DL, > + /* 254 */ 0x6D1E_07AB_4662_79F4L, 0x3279_75CB_6428_9D08L, > + /* 255 */ 0x4432_C4CB_0BFD_8C38L, 0x5F8B_E99F_1E99_6225L, > + /* 256 */ 0x553F_75FD_CEFC_EF46L, 0x776E_E406_E63F_BAAEL, > + /* 257 */ 0x6A8F_537D_42BC_2B18L, 0x554A_9D08_9FCF_A95AL, > + /* 258 */ 0x4299_942E_49B5_9AEFL, 0x354E_A225_63E1_C9D8L, > + /* 259 */ 0x533F_F939_DC23_01ABL, 0x22A2_4AAE_BCDA_3C4EL, > + /* 260 */ 0x680F_F788_532B_C216L, 0x0B4A_DD5A_6C10_CB62L, > + /* 261 */ 0x4109_FAB5_33FB_594DL, 0x670E_CA58_838A_7F1DL, > + /* 262 */ 0x514C_7962_80FA_2FA1L, 0x20D2_7CEE_A46D_1EE4L, > + /* 263 */ 0x659F_97BB_2138_BB89L, 0x4907_1C2A_4D88_669DL, > + /* 264 */ 0x7F07_7DA9_E986_EA6BL, 0x7B48_E334_E0EA_8045L, > + /* 265 */ 0x4F64_AE8A_31F4_5283L, 0x3D0D_8E01_0C92_902BL, > + /* 266 */ 0x633D_DA2C_BE71_6724L, 0x2C50_F181_4FB7_3436L, > + /* 267 */ 0x7C0D_50B7_EE0D_C0EDL, 0x3765_2DE1_A3A5_0143L, > + /* 268 */ 0x4D88_5272_F4C8_9894L, 0x329F_3CAD_0647_20CAL, > + /* 269 */ 0x60EA_670F_B1FA_BEB9L, 0x3F47_0BD8_47D8_E8FDL, > + /* 270 */ 0x7925_00D3_9E79_6E67L, 0x6F18_CECE_59CF_233CL, > + /* 271 */ 0x4BB7_2084_430B_E500L, 0x756F_8140_F821_7605L, > + /* 272 */ 0x5EA4_E8A5_53CE_DE41L, 0x12CB_6191_3629_D387L, > + /* 273 */ 0x764E_22CE_A8C2_95D1L, 0x377E_39F5_83B4_4868L, > + /* 274 */ 0x49F0_D5C1_2979_9DA2L, 0x72AE_E439_7250_AD41L, > + /* 275 */ 0x5C6D_0B31_73D8_050BL, 0x4F5A_9D47_CEE4_D891L, > + /* 276 */ 0x7388_4DFD_D0CE_064EL, 0x4331_4499_C29E_0EB6L, > + /* 277 */ 0x4835_30BE_A280_C3F1L, 0x09FE_CAE0_19A2_C932L, > + /* 278 */ 0x5A42_7CEE_4B20_F4EDL, 0x2C7E_7D98_200B_7B7EL, > + /* 279 */ 0x70D3_1C29_DDE9_3228L, 0x579E_1CFE_280E_5A5DL, > + /* 280 */ 0x4683_F19A_2AB1_BF59L, 0x36C2_D21E_D908_F87BL, > + /* 281 */ 0x5824_EE00_B55E_2F2FL, 0x6473_86A6_8F4B_3699L, > + /* 282 */ 0x6E2E_2980_E2B5_BAFBL, 0x5D90_6850_331E_043FL, > + /* 283 */ 0x44DC_D9F0_8DB1_94DDL, 0x2A7A_4132_1FF2_C2A8L, > + /* 284 */ 0x5614_106C_B11D_FA14L, 0x5518_D17E_A7EF_7352L, > + /* 285 */ 0x6B99_1487_DD65_7899L, 0x6A5F_05DE_51EB_5026L, > + /* 286 */ 0x433F_ACD4_EA5F_6B60L, 0x127B_63AA_F333_1218L, > + /* 287 */ 0x540F_980A_24F7_4638L, 0x171A_3C95_AFFF_D69EL, > + /* 288 */ 0x6913_7E0C_AE35_17C6L, 0x1CE0_CBBB_1BFF_CC45L, > + /* 289 */ 0x41AC_2EC7_ECE1_2EDBL, 0x720C_7F54_F17F_DFABL, > + /* 290 */ 0x5217_3A79_E819_7A92L, 0x6E8F_9F2A_2DDF_D796L, > + /* 291 */ 0x669D_0918_621F_D937L, 0x4A33_86F4_B957_CD7BL, > + /* 292 */ 0x4022_25AF_3D53_E7C2L, 0x5E60_3458_F3D6_E06DL, > + /* 293 */ 0x502A_AF1B_0CA8_E1B3L, 0x35F8_416F_30CC_9888L, > + /* 294 */ 0x6435_5AE1_CFD3_1A20L, 0x2376_51CA_FCFF_BEAAL, > + /* 295 */ 0x7D42_B19A_43C7_E0A8L, 0x2C53_E63D_BC3F_AE55L, > + /* 296 */ 0x4E49_AF00_6A5C_EC69L, 0x1BB4_6FE6_95A7_CCF5L, > + /* 297 */ 0x61DC_1AC0_84F4_2783L, 0x42A1_8BE0_3B11_C033L, > + /* 298 */ 0x7A53_2170_A631_3164L, 0x3349_EED8_49D6_303FL, > + /* 299 */ 0x4C73_F4E6_67DE_BEDEL, 0x600E_3547_2E25_DE28L, > + /* 300 */ 0x5F90_F220_01D6_6E96L, 0x3811_C298_F9AF_55B1L, > + /* 301 */ 0x7775_2EA8_024C_0A3CL, 0x0616_333F_381B_2B1EL, > + /* 302 */ 0x4AA9_3D29_016F_8665L, 0x43CD_E007_8310_FAF3L, > + /* 303 */ 0x5D53_8C73_41CB_67FEL, 0x74C1_5809_63D5_39AFL, > + /* 304 */ 0x74A8_6F90_123E_41FEL, 0x51F1_AE0B_BCCA_881BL, > + /* 305 */ 0x48E9_45BA_0B66_E93FL, 0x1337_0CC7_55FE_9511L, > + /* 306 */ 0x5B23_9728_8E40_A38EL, 0x7804_CFF9_2B7E_3A55L, > + /* 307 */ 0x71EC_7CF2_B1D0_CC72L, 0x5606_03F7_765D_C8EAL, > + /* 308 */ 0x4733_CE17_AF22_7FC7L, 0x55C3_C27A_A9FA_9D93L, > + /* 309 */ 0x5900_C19D_9AEB_1FB9L, 0x4B34_B319_5479_44F7L, > + /* 310 */ 0x6F40_F205_01A5_E7A7L, 0x7E01_DFDF_A997_9635L, > + /* 311 */ 0x4588_9743_2107_B0C8L, 0x7EC1_2BEB_C9FE_BDE1L, > + /* 312 */ 0x56EA_BD13_E949_9CFBL, 0x1E71_76E6_BC7E_6D59L, > + /* 313 */ 0x6CA5_6C58_E39C_043AL, 0x060D_D4A0_6B9E_08B0L, > + /* 314 */ 0x43E7_63B7_8E41_82A4L, 0x23C8_A4E4_4342_C56EL, > + /* 315 */ 0x54E1_3CA5_71D1_E34DL, 0x2CBA_CE1D_5413_76C9L, > + /* 316 */ 0x6A19_8BCE_CE46_5C20L, 0x57E9_81A4_A918_547BL, > + /* 317 */ 0x424F_F761_40EB_F994L, 0x36F1_F106_E9AF_34CDL, > + /* 318 */ 0x52E3_F539_9126_F7F9L, 0x44AE_6D48_A41B_0201L, > + /* 319 */ 0x679C_F287_F570_B5F7L, 0x75DA_089A_CD21_C281L, > + /* 320 */ 0x40C2_1794_F966_71BAL, 0x79A8_4560_C035_1991L, > + /* 321 */ 0x50F2_9D7A_37C0_0E29L, 0x5812_56B8_F042_5FF5L, > + /* 322 */ 0x652F_44D8_C5B0_11B4L, 0x0E16_EC67_2C52_F7F2L, > + /* 323 */ 0x7E7B_160E_F71C_1621L, 0x119C_A780_F767_B5EEL, > + /* 324 */ 0x4F0C_EDC9_5A71_8DD4L, 0x5B01_E8B0_9AA0_D1B5L, > + }; > + > +} > diff --git a/test/jdk/java/lang/Floating/DoubleToDecString.java > b/test/jdk/java/lang/Floating/DoubleToDecString.java > new file mode 100644 > --- /dev/null > +++ b/test/jdk/java/lang/Floating/DoubleToDecString.java > @@ -0,0 +1,312 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +import java.util.Random; > + > +import static java.lang.Math.*; > +import static java.lang.Double.*; > + > +/* > + * @test > + * @bug 8202555 > + > + * @author Raffaello Giulietti > + */ > +public class DoubleToDecString { > + > + private static final boolean FAILURE_THROWS_EXCEPTION = true; > + > + private static void assertTrue(boolean ok, double v, String s) { > + if (ok) { > + return; > + } > + String message = "Double::toString applied to " + > + "Double.longBitsToDouble(" + > + "0x" + Long.toHexString(doubleToRawLongBits(v)) + "L" + > + ")" + > + " returns " + > + "\"" + s + "\"" + > + ", which is not correct according to the specification."; > + if (FAILURE_THROWS_EXCEPTION) { > + throw new RuntimeException(message); > + } > + System.err.println(message); > + } > + > + private static void toDec(double v) { > + String s = Double.toString(v); > + assertTrue(new DoubleToStringChecker(v, s).isOK(), v, s); > + } > + > + private static void testExtremeValues() { > + toDec(NEGATIVE_INFINITY); > + toDec(-MAX_VALUE); > + toDec(-MIN_NORMAL); > + toDec(-MIN_VALUE); > + toDec(-0.0); > + toDec(0.0); > + toDec(MIN_VALUE); > + toDec(MIN_NORMAL); > + toDec(MAX_VALUE); > + toDec(POSITIVE_INFINITY); > + toDec(NaN); > + /* > + Quiet NaNs have the most significant bit of the mantissa as 1, > + while signaling NaNs have it as 0. > + Exercise 4 combinations of quiet/signaling NaNs and > + "positive/negative" NaNs > + */ > + toDec(longBitsToDouble(0x7FF8_0000_0000_0001L)); > + toDec(longBitsToDouble(0x7FF0_0000_0000_0001L)); > + toDec(longBitsToDouble(0xFFF8_0000_0000_0001L)); > + toDec(longBitsToDouble(0xFFF0_0000_0000_0001L)); > + } > + > + /* > + A few "powers of 10" are incorrectly rendered by the JDK. > + The rendering is either too long or it is not the closest decimal. > + */ > + private static void testPowersOf10() { > + for (int e = -323; e <= 309; ++e) { > + toDec(parseDouble("1e" + e)); > + } > + } > + > + /* > + Many powers of 2 are incorrectly rendered by the JDK. > + The rendering is either too long or it is not the closest decimal. > + */ > + private static void testPowersOf2() { > + for (double v = MIN_VALUE; v <= MAX_VALUE; v *= 2.0) { > + toDec(v); > + } > + } > + > + /* > + There are tons of doubles that are rendered incorrectly by the JDK. > + While the renderings correctly round back to the original value, > + they are longer than needed or are not the closest decimal to the > double. > + Here are just a very few examples. > + */ > + private static final String[] Anomalies = { > + // JDK renders these, and others, with 18 digits! > + "2.82879384806159E17", "1.387364135037754E18", > + "1.45800632428665E17", > + > + // JDK renders these longer than needed. > + "1.6E-322", "6.3E-322", > + "7.3879E20", "2.0E23", "7.0E22", "9.2E22", > + "9.5E21", "3.1E22", "5.63E21", "8.41E21", > + > + // JDK does not render these, and many others, as the closest. > + "9.9E-324", "9.9E-323", > + "1.9400994884341945E25", "3.6131332396758635E25", > + "2.5138990223946153E25", > + }; > + > + private static void testSomeAnomalies() { > + for (String dec : Anomalies) { > + toDec(parseDouble(dec)); > + } > + } > + > + /* > + Values are from > + Paxson V, "A Program for Testing IEEE Decimal?Binary Conversion" > + */ > + private static final double[] PaxsonSignificands = { > + 8_511_030_020_275_656L, > + 5_201_988_407_066_741L, > + 6_406_892_948_269_899L, > + 8_431_154_198_732_492L, > + 6_475_049_196_144_587L, > + 8_274_307_542_972_842L, > + 5_381_065_484_265_332L, > + 6_761_728_585_499_734L, > + 7_976_538_478_610_756L, > + 5_982_403_858_958_067L, > + 5_536_995_190_630_837L, > + 7_225_450_889_282_194L, > + 7_225_450_889_282_194L, > + 8_703_372_741_147_379L, > + 8_944_262_675_275_217L, > + 7_459_803_696_087_692L, > + 6_080_469_016_670_379L, > + 8_385_515_147_034_757L, > + 7_514_216_811_389_786L, > + 8_397_297_803_260_511L, > + 6_733_459_239_310_543L, > + 8_091_450_587_292_794L, > + > + 6_567_258_882_077_402L, > + 6_712_731_423_444_934L, > + 6_712_731_423_444_934L, > + 5_298_405_411_573_037L, > + 5_137_311_167_659_507L, > + 6_722_280_709_661_868L, > + 5_344_436_398_034_927L, > + 8_369_123_604_277_281L, > + 8_995_822_108_487_663L, > + 8_942_832_835_564_782L, > + 8_942_832_835_564_782L, > + 8_942_832_835_564_782L, > + 6_965_949_469_487_146L, > + 6_965_949_469_487_146L, > + 6_965_949_469_487_146L, > + 7_487_252_720_986_826L, > + 5_592_117_679_628_511L, > + 8_887_055_249_355_788L, > + 6_994_187_472_632_449L, > + 8_797_576_579_012_143L, > + 7_363_326_733_505_337L, > + 8_549_497_411_294_502L, > + }; > + > + private static final int[] PaxsonExponents = { > + -342, > + -824, > + 237, > + 72, > + 99, > + 726, > + -456, > + -57, > + 376, > + 377, > + 93, > + 710, > + 709, > + 117, > + -1, > + -707, > + -381, > + 721, > + -828, > + -345, > + 202, > + -473, > + > + 952, > + 535, > + 534, > + -957, > + -144, > + 363, > + -169, > + -853, > + -780, > + -383, > + -384, > + -385, > + -249, > + -250, > + -251, > + 548, > + 164, > + 665, > + 690, > + 588, > + 272, > + -448, > + }; > + > + private static void testPaxson() { > + for (int i = 0; i < PaxsonSignificands.length; ++i) { > + toDec(scalb(PaxsonSignificands[i], PaxsonExponents[i])); > + } > + } > + > + /* > + Tests all integers of the form yx_xxx_000_000_000_000_000, y != 0. > + These are all exact doubles. > + */ > + private static void testLongs() { > + for (int i = 10_000; i < 100_000; ++i) { > + toDec(i * 1e15); > + } > + } > + > + /* > + Tests all integers up to 100_000. > + These are all exact doubles. > + */ > + private static void testInts() { > + for (int i = 0; i <= 1_000_000; ++i) { > + toDec(i); > + } > + } > + > + /* > + Random doubles over the whole range > + */ > + private static void testRandom() { > + Random r = new Random(); > + for (int i = 0; i < 1_000_000; ++i) { > + toDec(longBitsToDouble(r.nextLong())); > + } > + } > + > + /* > + Random doubles over the integer range [0, 10^15). > + These integers are all exact doubles. > + */ > + private static void testRandomUnit() { > + Random r = new Random(); > + for (int i = 0; i < 100_000; ++i) { > + toDec(r.nextLong() % 1_000_000_000_000_000L); > + } > + } > + > + /* > + Random doubles over the range [0, 10^15) as "multiples" of 1e-3 > + */ > + private static void testRandomMilli() { > + Random r = new Random(); > + for (int i = 0; i < 100_000; ++i) { > + toDec(r.nextLong() % 1_000_000_000_000_000_000L / 1e3); > + } > + } > + > + /* > + Random doubles over the range [0, 10^15) as "multiples" of 1e-6 > + */ > + private static void testRandomMicro() { > + Random r = new Random(); > + for (int i = 0; i < 100_000; ++i) { > + toDec((r.nextLong() & 0x7FFF_FFFF_FFFF_FFFFL) / 1e6); > + } > + } > + > + public static void main(String[] args) { > + testExtremeValues(); > + testSomeAnomalies(); > + testPowersOf2(); > + testPowersOf10(); > + testPaxson(); > + testInts(); > + testLongs(); > + testRandom(); > + testRandomUnit(); > + testRandomMilli(); > + testRandomMicro(); > + } > + > +} > diff --git a/test/jdk/java/lang/Floating/DoubleToStringChecker.java > b/test/jdk/java/lang/Floating/DoubleToStringChecker.java > new file mode 100644 > --- /dev/null > +++ b/test/jdk/java/lang/Floating/DoubleToStringChecker.java > @@ -0,0 +1,91 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +import java.math.BigDecimal; > + > +/** > + * @author Raffaello Giulietti > + */ > +class DoubleToStringChecker extends StringChecker { > + > + private double v; > + > + DoubleToStringChecker(double v, String s) { > + super(s); > + this.v = v; > + } > + > + @Override > + BigDecimal toBigDecimal() { > + return new BigDecimal(v); > + } > + > + @Override > + boolean recovers(BigDecimal b) { > + return b.doubleValue() == v; > + } > + > + @Override > + boolean recovers(String s) { > + return Double.parseDouble(s) == v; > + } > + > + @Override > + int maxExp() { > + return 309; > + } > + > + @Override > + int minExp() { > + return -323; > + } > + > + @Override > + int maxLen10() { > + return 17; > + } > + > + @Override > + boolean isZero() { > + return v == 0; > + } > + > + @Override > + boolean isInfinity() { > + return v == Double.POSITIVE_INFINITY; > + } > + > + @Override > + void invert() { > + v = -v; > + } > + > + @Override > + boolean isNegative() { > + return Double.doubleToRawLongBits(v) < 0; > + } > + > + @Override > + boolean isNaN() { > + return v != v; > + } > + > +} > diff --git a/test/jdk/java/lang/Floating/FloatToDecString.java > b/test/jdk/java/lang/Floating/FloatToDecString.java > new file mode 100644 > --- /dev/null > +++ b/test/jdk/java/lang/Floating/FloatToDecString.java > @@ -0,0 +1,144 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +import java.util.Random; > + > +import static java.lang.Float.*; > + > +/* > + * @test > + > + * @author Raffaello Giulietti > + */ > +public class FloatToDecString { > + > + private static final boolean FAILURE_THROWS_EXCEPTION = true; > + > + private static void assertTrue(boolean ok, float v, String s) { > + if (ok) { > + return; > + } > + String message = "Float::toString applied to " + > + "Float.intBitsToFloat(" + > + "0x" + Integer.toHexString(floatToRawIntBits(v)) + > + ")" + > + " returns " + > + "\"" + s + "\"" + > + ", which is not correct according to the specification."; > + if (FAILURE_THROWS_EXCEPTION) { > + throw new RuntimeException(message); > + } > + System.err.println(message); > + } > + > + private static void toDec(float v) { > + String s = Float.toString(v); > + assertTrue(new FloatToStringChecker(v, s).isOK(), v, s); > + } > + > + /* > + MIN_NORMAL is incorrectly rendered by the JDK. > + */ > + private static void testExtremeValues() { > + toDec(NEGATIVE_INFINITY); > + toDec(-MAX_VALUE); > + toDec(-MIN_NORMAL); > + toDec(-MIN_VALUE); > + toDec(-0.0f); > + toDec(0.0f); > + toDec(MIN_VALUE); > + toDec(MIN_NORMAL); > + toDec(MAX_VALUE); > + toDec(POSITIVE_INFINITY); > + toDec(NaN); > + /* > + Quiet NaNs have the most significant bit of the mantissa as 1, > + while signaling NaNs have it as 0. > + Exercise 4 combinations of quiet/signaling NaNs and > + "positive/negative" NaNs. > + */ > + toDec(intBitsToFloat(0x7FC0_0001)); > + toDec(intBitsToFloat(0x7F80_0001)); > + toDec(intBitsToFloat(0xFFC0_0001)); > + toDec(intBitsToFloat(0xFF80_0001)); > + } > + > + /* > + Many "powers of 10" are incorrectly rendered by the JDK. > + The rendering is either too long or it is not the closest decimal. > + */ > + private static void testPowersOf10() { > + for (int e = -44; e <= 39; ++e) { > + toDec(parseFloat("1e" + e)); > + } > + } > + > + /* > + Many powers of 2 are incorrectly rendered by the JDK. > + The rendering is either too long or it is not the closest decimal. > + */ > + private static void testPowersOf2() { > + for (float v = MIN_VALUE; v <= MAX_VALUE; v *= 2.0) { > + toDec(v); > + } > + } > + > + /* > + Tests all integers up to 1_000_000. > + These are all exact floats. > + */ > + private static void testInts() { > + for (int i = 0; i <= 1_000_000; ++i) { > + toDec(i); > + } > + } > + > + /* > + Random floats over the whole range. > + */ > + private static void testRandom() { > + Random r = new Random(); > + for (int i = 0; i < 1_000_000; ++i) { > + toDec(intBitsToFloat(r.nextInt())); > + } > + } > + > + /* > + All, really all, possible floats. Takes between 90 and 120 minutes. > + */ > + private static void testAll() { > + int bits = Integer.MIN_VALUE; > + for (; bits < Integer.MAX_VALUE; ++bits) { > + toDec(Float.intBitsToFloat(bits)); > + } > + toDec(Float.intBitsToFloat(bits)); > + } > + > + public static void main(String[] args) { > +// testAll(); > + testExtremeValues(); > + testPowersOf2(); > + testPowersOf10(); > + testInts(); > + testRandom(); > + } > + > +} > diff --git a/test/jdk/java/lang/Floating/FloatToStringChecker.java > b/test/jdk/java/lang/Floating/FloatToStringChecker.java > new file mode 100644 > --- /dev/null > +++ b/test/jdk/java/lang/Floating/FloatToStringChecker.java > @@ -0,0 +1,91 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +import java.math.BigDecimal; > + > +/** > + * @author Raffaello Giulietti > + */ > +class FloatToStringChecker extends StringChecker { > + > + private float v; > + > + FloatToStringChecker(float v, String s) { > + super(s); > + this.v = v; > + } > + > + @Override > + BigDecimal toBigDecimal() { > + return new BigDecimal(v); > + } > + > + @Override > + boolean recovers(BigDecimal b) { > + return b.floatValue() == v; > + } > + > + @Override > + boolean recovers(String s) { > + return Float.parseFloat(s) == v; > + } > + > + @Override > + int maxExp() { > + return 39; > + } > + > + @Override > + int minExp() { > + return -44; > + } > + > + @Override > + int maxLen10() { > + return 9; > + } > + > + @Override > + boolean isZero() { > + return v == 0; > + } > + > + @Override > + boolean isInfinity() { > + return v == Float.POSITIVE_INFINITY; > + } > + > + @Override > + void invert() { > + v = -v; > + } > + > + @Override > + boolean isNegative() { > + return Float.floatToRawIntBits(v) < 0; > + } > + > + @Override > + boolean isNaN() { > + return v != v; > + } > + > +} > diff --git a/test/jdk/java/lang/Floating/StringChecker.java > b/test/jdk/java/lang/Floating/StringChecker.java > new file mode 100644 > --- /dev/null > +++ b/test/jdk/java/lang/Floating/StringChecker.java > @@ -0,0 +1,348 @@ > +/* > + * Copyright (c) 2018, Raffaello Giulietti. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * This particular file is subject to the "Classpath" exception as > provided > + * in the LICENSE file that accompanied this code. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + */ > + > +import java.io.IOException; > +import java.io.StringReader; > +import java.math.BigDecimal; > + > +/** > + * @author Raffaello Giulietti > + */ > +abstract class StringChecker { > + > + private String s; > + private long c; > + private int q; > + private int len10; > + > + StringChecker(String s) { > + this.s = s; > + } > + > + /* > + Returns whether s syntactically meets the expected output of > + Double::toString. It is restricted to finite positive outputs. > + It is an unusually long method but rather straightforward, too. > + Many conditionals could be merged, but KISS here. > + */ > + private boolean parse() { > + try { > + // first determine interesting boundaries in the string > + StringReader r = new StringReader(s); > + int ch = r.read(); > + > + int i = 0; > + while (ch == '0') { > + ++i; > + ch = r.read(); > + } > + // i is just after zeroes starting the integer > + > + int p = i; > + while ('0' <= ch && ch <= '9') { > + c = 10 * c + (ch - '0'); > + if (c < 0) { > + return false; > + } > + ++len10; > + ++p; > + ch = r.read(); > + } > + // p is just after digits ending the integer > + > + int fz = p; > + if (ch == '.') { > + ++fz; > + ch = r.read(); > + } > + // fz is just after a decimal '.' > + > + int f = fz; > + while (ch == '0') { > + c = 10 * c + (ch - '0'); > + if (c < 0) { > + return false; > + } > + ++len10; > + ++f; > + ch = r.read(); > + } > + // f is just after zeroes starting the fraction > + > + if (c == 0) { > + len10 = 0; > + } > + int x = f; > + while ('0' <= ch && ch <= '9') { > + c = 10 * c + (ch - '0'); > + if (c < 0) { > + return false; > + } > + ++len10; > + ++x; > + ch = r.read(); > + } > + // x is just after digits ending the fraction > + > + int g = x; > + if (ch == 'E') { > + ++g; > + ch = r.read(); > + } > + // g is just after an exponent indicator 'E' > + > + int ez = g; > + if (ch == '-') { > + ++ez; > + ch = r.read(); > + } > + // ez is just after a '-' sign in the exponent > + > + int e = ez; > + while (ch == '0') { > + ++e; > + ch = r.read(); > + } > + // e is just after zeroes starting the exponent > + > + int z = e; > + while ('0' <= ch && ch <= '9') { > + q = 10 * q + (ch - '0'); > + if (q < 0) { > + return false; > + } > + ++z; > + ch = r.read(); > + } > + // z is just after digits ending the exponent > + > + // No other char after the number > + if (z != s.length()) { > + return false; > + } > + > + // The integer must be present > + if (p == 0) { > + return false; > + } > + > + // The decimal '.' must be present > + if (fz == p) { > + return false; > + } > + > + // The fraction must be present > + if (x == fz) { > + return false; > + } > + > + // The fraction is not 0 or it consists of exactly one 0 > + if (f == x && f - fz > 1) { > + return false; > + } > + > + // Plain notation, no exponent > + if (x == z) { > + // At most one 0 starting the integer > + if (i > 1) { > + return false; > + } > + > + // If the integer is 0, at most 2 zeroes start the > fraction > + if (i == 1 && f - fz > 2) { > + return false; > + } > + > + // The integer cannot have more than 7 digits > + if (p > 7) { > + return false; > + } > + > + q = fz - x; > + > + // OK for plain notation > + return true; > + } > + > + // Computerized scientific notation > + > + // The integer has exactly one nonzero digit > + if (i != 0 || p != 1) { > + return false; > + } > + > + // > + // There must be an exponent indicator > + if (x == g) { > + return false; > + } > + > + // There must be an exponent > + if (ez == z) { > + return false; > + } > + > + // The exponent must not start with zeroes > + if (ez != e) { > + return false; > + } > + > + if (g != ez) { > + q = -q; > + } > + > + // The exponent must not lie in [-3, 7) > + if (-3 <= q && q < 7) { > + return false; > + } > + > + q += fz - x; > + > + // OK for computerized scientific notation > + return true; > + } catch (IOException ex) { > + // An IOException on a StringReader??? Please... > + return false; > + } > + } > + > + boolean isOK() { > + if (isNaN()) { > + return s.equals("NaN"); > + } > + if (isNegative()) { > + if (s.isEmpty() || s.charAt(0) != '-') { > + return false; > + } > + invert(); > + s = s.substring(1); > + } > + if (isInfinity()) { > + return s.equals("Infinity"); > + } > + if (isZero()) { > + return s.equals("0.0"); > + } > + if (!parse()) { > + return false; > + } > + if (len10 < 2) { > + c *= 10; > + q -= 1; > + len10 += 1; > + } > + if (2 > len10 || len10 > maxLen10()) { > + return false; > + } > + > + // The exponent is bounded > + if (minExp() > q + len10 || q + len10 > maxExp()) { > + return false; > + } > + > + // s must recover v > + try { > + if (!recovers(s)) { > + return false; > + } > + } catch (NumberFormatException e) { > + return false; > + } > + > + // Get rid of trailing zeroes, still ensuring at least 2 digits > + while (len10 > 2 && c % 10 == 0) { > + c /= 10; > + q += 1; > + len10 -= 1; > + } > + > + if (len10 > 2) { > + // Try with a shorter number less than v... > + if (recovers(BigDecimal.valueOf(c / 10, -q - 1))) { > + return false; > + } > + > + // ... and with a shorter number greater than v > + if (recovers(BigDecimal.valueOf(c / 10 + 1, -q - 1))) { > + return false; > + } > + } > + > + // Try with the decimal predecessor... > + BigDecimal dp = c == 10 ? > + BigDecimal.valueOf(99, -q + 1) : > + BigDecimal.valueOf(c - 1, -q); > + if (recovers(dp)) { > + BigDecimal bv = toBigDecimal(); > + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); > + if (deltav.signum() >= 0) { > + return true; > + } > + BigDecimal delta = dp.subtract(bv); > + if (delta.signum() >= 0) { > + return false; > + } > + int cmp = deltav.compareTo(delta); > + return cmp > 0 || cmp == 0 && (c & 0x1) == 0; > + } > + > + // ... and with the decimal successor > + BigDecimal ds = BigDecimal.valueOf(c + 1, -q); > + if (recovers(ds)) { > + BigDecimal bv = toBigDecimal(); > + BigDecimal deltav = bv.subtract(BigDecimal.valueOf(c, -q)); > + if (deltav.signum() <= 0) { > + return true; > + } > + BigDecimal delta = ds.subtract(bv); > + if (delta.signum() <= 0) { > + return false; > + } > + int cmp = deltav.compareTo(delta); > + return cmp < 0 || cmp == 0 && (c & 0x1) == 0; > + } > + > + return true; > + } > + > + abstract BigDecimal toBigDecimal(); > + > + abstract boolean recovers(BigDecimal b); > + > + abstract boolean recovers(String s); > + > + abstract int maxExp(); > + > + abstract int minExp(); > + > + abstract int maxLen10(); > + > + abstract boolean isZero(); > + > + abstract boolean isInfinity(); > + > + abstract void invert(); > + > + abstract boolean isNegative(); > + > + abstract boolean isNaN(); > + > +} > > > > > > From mandy.chung at oracle.com Tue Oct 2 18:18:16 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 11:18:16 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: +1 Mandy On 10/2/18 11:17 AM, Mikael Vidstedt wrote: > > Thanks for the reviews. I?ve reverted the changes related to Helper > and ?just? adjusted the comments instead. > > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > > incremental (from webrev.00): > http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > > Btw, I notice that "Test not run, NO jmods directory? will be printed > twice when jmods is missing - once in Helper::newHelper and once in > the methods calling it. In general, the handling of a null return from > newHelper could use some clean up, but that is out of scope for this > change. > > Cheers, > Mikael From erik.joelsson at oracle.com Tue Oct 2 18:28:01 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 2 Oct 2018 11:28:01 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: <7f163563-0c99-d496-95d9-3f0a2ff54ca9@oracle.com> Looks good to me. /Erik On 2018-10-02 11:17, Mikael Vidstedt wrote: > Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. > > Cheers, > Mikael > >> On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: >> >> >> >> On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >>> Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >>> >> test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). >> >> I think Helper class should continue to return null if jmods does not exist. test/jdk/tools/jimage/JImageTest.java should also be reverted. >> >> Otherwise, the clean up looks good. >> >> Mandy From Alan.Bateman at oracle.com Tue Oct 2 18:28:26 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Oct 2018 19:28:26 +0100 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: <5ce26e91-9ecc-3adf-e61a-b85eb4349beb@oracle.com> On 02/10/2018 19:17, Mikael Vidstedt wrote: > Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. > At some point I think the test for jlink will need to be cleaned up anyway but that is way outside of scope of what you are doing. The updated webrev looks okay to me. -Alan From mandy.chung at oracle.com Tue Oct 2 19:33:16 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 Oct 2018 12:33:16 -0700 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak Message-ID: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> Class::newInstance maintains its separate cache of the caller class after access check.? This leak has been there for a long time and unnoticed. This patch changes Class::newInstance to use the code path for Constructor::newInstance doing the access check and caching the caller class.? It will also get the illegal access check in effect when Class::newInstance is called consistent with Constructor::newInstance. Webrev at: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.00 Alan raises a question whether the cache is still needed given that we have improved the performance of slow path of access check with Class::getPackageName.? It's a good investigation to follow up. Mandy From xueming.shen at oracle.com Tue Oct 2 20:04:48 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 02 Oct 2018 13:04:48 -0700 Subject: RFR JDK-8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative Message-ID: <5BB3CF60.6050900@oracle.com> Hi, Please help review the change for JDK-8211585. issue: https://bugs.openjdk.java.net/browse/JDK-8211385 webrev: http://cr.openjdk.java.net/~sherman/8211385/webrev Thanks, Sherman From david.holmes at oracle.com Tue Oct 2 20:06:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Oct 2018 06:06:23 +1000 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: <86c65ecd-dca0-6b0d-d144-22ad5a1e73e6@oracle.com> Message-ID: Looks good. Ship it! David On 3/10/2018 4:17 AM, Mikael Vidstedt wrote: > > Thanks for the reviews. I?ve reverted the changes related to Helper and ?just? adjusted the comments instead. > > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01/open/webrev/ > incremental (from webrev.00): http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.01.incr/open/webrev/ > > > Btw, I notice that "Test not run, NO jmods directory? will be printed twice when jmods is missing - once in Helper::newHelper and once in the methods calling it. In general, the handling of a null return from newHelper could use some clean up, but that is out of scope for this change. > > Cheers, > Mikael > >> On Oct 2, 2018, at 8:40 AM, Mandy Chung wrote: >> >> >> >> On 10/2/18 12:21 AM, Mikael Vidstedt wrote: >>> Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8211350 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ >>> >> >> test/jdk/tools/lib/tests/Helper.java is used by test/jdk/tools/jimage and test/jdk/tools/jlink tests which will be skipped, rather than failing, when running with images where jmods directory is not present (e.g. exploded image). >> >> I think Helper class should continue to return null if jmods does not exist. test/jdk/tools/jimage/JImageTest.java should also be reverted. >> >> Otherwise, the clean up looks good. >> >> Mandy > From jonathan.gibbons at oracle.com Tue Oct 2 21:39:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Oct 2018 14:39:50 -0700 Subject: RFR(S): 8211350: Remove jprt support In-Reply-To: References: Message-ID: <5BB3E5A6.8070401@oracle.com> *Chuckle* at the long-obsolete reference in test/langtools/Makefile 292 apt: JTREG_TESTDIRS = tools/apt Otherwise, apart from other overdue cleanup, test/langtools/Makefile looks OK. -- Jon On 10/02/2018 12:21 AM, Mikael Vidstedt wrote: > Please review this change which removes support for, and references to, the (Oracle internal) JPRT system. > > bug: https://bugs.openjdk.java.net/browse/JDK-8211350 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8211350/webrev.00/open/webrev/ > > * Background (from the issue) > > The Oracle internal JPRT system was once used to build and test the JDK. It has been superseded and can no longer be used to build/test mainline JDK. The support in the JDK code for running jobs in JPRT should be removed. > > > * About the change > > The change touches several areas: build/make, hotspot, and jdk. I?m optimistically sending it out as a single webrev anyway. If it helps, I?m expecting the reviews to roughly map like so: > > build-dev: make related files, jprt.* > hotspot-dev: {src,test}/hotspot > core-libs-dev: test/jdk - I?m especially interested in hearing if the change to test/jdk/tools/lib/tests/Helper.java (to throw if the jmods directory is missing) is valid > > Of course I?d welcome reviews across those mappings as well. > > * Testing > > tier1 (passed), tier2-3 still running (looking good so far). > > Cheers, > Mikael > From xueming.shen at oracle.com Tue Oct 2 22:01:47 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 02 Oct 2018 15:01:47 -0700 Subject: RFR: 8211382 ISO2022JP and GB18030 NIO converter issues In-Reply-To: References: Message-ID: <5BB3EACB.8050202@oracle.com> +1 -Sherman btw, since gb18030.decodeArrayLoop() is right I would assume it's just a "typo" in decodeBufferLoop() On 10/2/18, 2:21 AM, Ichiroh Takiguchi wrote: > Hello, > IBM would like to contribute NIO converter patch to OpenJDK project. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211382 > Change: https://cr.openjdk.java.net/~itakiguchi/8211382/webrev.00/ > > Issue: > ISO2022JP decoder and GB18030 decoder (for decodeBufferLoop()) have > code range definition issues. > > ISO2022JP, 0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, 0x42, is converted to > \uFFA0 > ISO2022JP is for Japanese, but \uFFA0 is a part of Korean Hangul > character. > > GB18030, \uFFFE is converted to 0x84, 0x31, 0xA4, 0x38. > 0x84, 0x31, 0xA4, 0x38 is converted to replacement character \uFFFD. > > $ java Test1 > \uFFA0 > \uFFFD > > Expected result > $ java Test1 > \uFFFD > \uFFFE > > Testcase is as follows: > ======================== > $ cat Test1.java > import java.nio.*; > import java.nio.charset.*; > > public class Test1 { > public static void main(String[] args) throws Exception { > { > byte[] ba = new byte[] {0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, 0x42,}; > for(char ch : (new String(ba, "ISO2022JP")).toCharArray()) { > System.out.printf("\\u%04X",(int)ch); > } > System.out.println(); > } > { > Charset cs = Charset.forName("GB18030"); > CharsetDecoder cd = cs.newDecoder(); > cd.onMalformedInput(CodingErrorAction.REPLACE) > .onUnmappableCharacter(CodingErrorAction.REPLACE); > byte[] ba = "\uFFFE".getBytes(cs); > ByteBuffer bb = ByteBuffer.allocateDirect(ba.length); > bb.put(ByteBuffer.wrap(ba)); > bb.position(0); > CharBuffer cb = cd.decode(bb); > for(int i=0; i System.out.printf("\\u%04X",(int)cb.get(i)); > } > System.out.println(); > } > } > } > ======================== > > I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > From igor.ignatyev at oracle.com Tue Oct 2 23:26:32 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 2 Oct 2018 16:26:32 -0700 Subject: Test Libraries : Status and Further Steps Message-ID: Dear all, I am pleased to announce that we have finished work on 'Merge jdk and hotspot test libraries' and achieved the big milestone in our work on improving test libraries. Since this project started a long time, I think it's worth it to reiterate why we are doing it, what has been done, and what is planned to be done. So by this email, I hope to bring us all on the same page as well as to initiate discussion on possible further improvements. 1. Background and Past Work The project on merging test libraries started more than three years ago. The test libraries were created long before a consolidated repository, so HotSpot test suite and JDK test suite were not only in different directories but also in separate repositories, and if it was not enough, their developments were happening in different forests. All these were making it really hard to share test libraries and have them synchronized. However, people who work on both hotspot and JDK tests craved to have a consistent test library which covers most common use-cases, this is how several internal forks of test library emerged[1-2]. Obviously, it did not end well: test libraries started to grow differently, and the efforts to keep them in sync became more and more cumbersome. At some point in time, we accepted the forks being different and stopped any attempts to synchronize them and decided to introduce a common library which can be used by all test suites. The common library had been placed in '/test/lib' directory, which was in the top-level repository, and was based on HotSpot's fork (by the right of the "firstborn"). Christian made a huge and very valuable effort[3-4] on switching all HotSpot tests to use this library. Although that significantly increased sanity of HotSpot developers and simplified their life, it did not solve the original problem, as we still had multiple copies of a test library. By the end of JDK 9 time frame, we had three forks of test library: two deprecated in JAXP and JDK repositories and one in the top repository. As the top-level library was based on HotSpot' version, switching other test suites required more work and testing. 8075327[5] was created to switch JAXP and JDK test suites to use the common test library. It appeared that only a few JAXP tests were using JAXP version of the test library, so it was relatively easy and straightforward. JDK test library, on the contrary, was heavily used by the test suite. And as JDK test library had been forked back in 2013, it altered a lot from HotSpot's version: some functionality was missed in one version, some in another, some were implemented very differently, etc. Therefore the patch for JDK was not as easy as a simple change of @library/@build tags and import statements and became a long and tedious process of handling one test library class after another. 8211171[6-7] removed JarUtils and "handled" the last class existing in multiple versions of the common test libraries. 2. Future work Further improvements of the test libraries include handling the rest of JDK and JAXP test library classes; merging logical duplications within the test libraries; modularize the test libraries. Besides these changes, there are other possible enhancements and bug fixes in the test libraries, but they are out of the scope of this project. The following sections explain each of these three improvements in greater details. 2.1. Handling the rest of JDK and JAXP test libraries Currently, neither JDK nor JAXP test library contains classes from the common test library, but these test libraries still have some other classes which, in some cases, should be rearranged to improve the overall experience with the test libraries. One might suggest moving all these classes into the top-level library, but such an action would come at a high price. Placing classes into the top-level test library implies certain difficulties: you must assume that they are used by tests from all test suites, so all changes must be reviewed and tested accordingly, and the changes which break behavioral compatibility must be done with great care. Generally speaking, the further library classes away from tests, the greater risk to break other tests. Leaving classes as-is is another extreme and can also cause some complications. One such complication is a possibility to get a fork of library classes, which will move us back into 2013. Another is a creation of "unintended" test libraries. "Unintended" test library can be created because it is possible to use classes from any other tests (including from another test suite). Although, it is technically possible, expecting someone to test or fix someone else's tests when they change their internal classes would be unreasonable. Thus using classes which are not part of any test libraries and not part of the tests must be discouraged by guidelines and indicated during the review process. Thereby, the rest of the test libraries classes can be split into three categories and placed accordingly: 1) classes which are intended to be used by all test suites are to be moved to the top-level test library; 2) classes which are used by a certain test group and would have very low, if any, usefulness for other test suites. Such classes should be kept in a test library specific for a test suite. 3) classes which are very specific to a few particular tests should be moved closer to the tests which depend on them. I have looked through the remaining test library classes, made an initial assessment of their category, and wrote it done as comments in 8211290[8]. Since I am not an original author of these classes nor their user, I might be completely wrong in my evaluation, so I would really appreciate Core-Libs and JAXP team's opinion on them, and would also love them to check whenever I missed any other test library classes. 2.2. Merging duplications Due to the fact that the top-level test library has been created as a merge of commonly used test library classes, it has several classes which do a similar or the same thing but slightly differently. For example, there are two ways to get a reproducible random generator -- 'jdk.test.lib.Utils.RANDOM_GENERATOR' and 'jdk.test.lib.RandomFactory'. Such duplications have obvious negative impacts on test libraries. All cases of such duplication should be carefully reviewed and "merged" into one entity if possible. Here "merge" doesn't necessarily mean to get a class which provides both a set of APIs and "merge" can be achieved by removing one of the classes accompanied by conversions of the existing tests. Poor documentation and visibility of available test library classes seem to be the key causing factors of such duplications. Therefore this effort also includes documenting public classes of the test libraries and making this documentation easily available for Open JDK developers. 8211289[9] has been created to track internal merges and documentation effort. I made an initial identification of duplications and posted a proposed solution for each found case in the RFE. 2.3. Modularize Analyzing test library classes, one can notice that they are different in their dependencies and/or objectives. Thus it is logical to split them into separate entities and Jigsaw modules are a perfect fit for that. Using Jigsaw modules will allow us to express dependencies more easily and consistently. Although most of the test library depends only on the exported APIs of 'java.base' module, there are classes which have dependencies on other modules as well as classes which use internal packages, so it is logical to use this information to get the first grouping, otherwise, we will needlessly restrict usage of the test library. For example, 'jdk.test.lib.compiler.*' classes are the only classes in the top-level test library which depend on 'java.compiler' module, so it makes sense to place them into a dedicated module and name this module 'test.compiler' to express this dependency. The top-level classes which depend only on 'java.base' module and do not require special handling will be placed into one module which can be named 'test.base'. Since jtreg supports building Jigsaw modules natively, modularization will also guarantee that all classes are built by a simple and straightforward @build tag. Continuing with the example, tests which want to use 'test.base' module will have to have just two directives '@library /test/lib' and '@build test.base/*' to always get all the needed classes properly built. It is important to highlight that although modularization of the test library will make it possible to use a test library as a set of jigsaw modules, it still will be possible to use the test library almost as before without using modules at all, as this is necessary for a certain group of tests, e.g. ones which are strict on the list of available modules. The initial modularization proposal is based on the information extracted by 'jdeps' tool. 8211358[10] provides details on proposed modules, their names, packages/classes to include, and reasoning why a separate module is required. 3. Final Goal After all these improvements are implemented, we will have more organized modularized tests libraries which do not have irritating duplications. Common test libraries classes will be in '/test/lib', test libraries specific for test suites will be in 'lib' directory inside in a test suite. The tests will use these libraries by a few meaningful @library and @build directives, and the test libraries layout will look similar to the following: test |-- lib | |-- test.base | |-- test.compiler | |-- test.jfr | `-- test.whitebox |-- hotspot/lib | |-- test.hotspot.jvmti | `-- test.hotspot.ctw `-- jdk/lib |-- test.jdk.client `-- test.jdk.security 4. Summary Although significant progress has been achieved in this field, there is still a long way ahead of us. We have merged three distinct forks into one common test library available to use in any jtreg test suites. All the existing test suites have been switched to use the classes from this test library. Next steps aim at further improving Open JDK developer experience and make test libraries maintenance easier. 8211290, 8211289, and 8211358 have been filed for each step and contain more details on proposed action plans, I would really like to encourage interested parties to express their opinion in this email thread and/or in the corresponding RFE. Since the adoption of the test library as well as preventing duplication highly depend on awareness people about existing library classes, I would also appreciate people suggesting to use existing classes when appropriate more often during reviews. Thanks, -- Igor [1] https://bugs.openjdk.java.net/browse/JDK-8007142 [2] http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-February/008215.html [3] https://bugs.openjdk.java.net/browse/JDK-8157957 [4] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198.html [5] https://bugs.openjdk.java.net/browse/JDK-8075327 [6] https://bugs.openjdk.java.net/browse/JDK-8211171 [7] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055702.html [8] https://bugs.openjdk.java.net/browse/JDK-8211290 [9] https://bugs.openjdk.java.net/browse/JDK-8211289 [10] https://bugs.openjdk.java.net/browse/JDK-8211358 From stuart.marks at oracle.com Tue Oct 2 23:28:33 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 2 Oct 2018 16:28:33 -0700 Subject: Convert old-style array declarations In-Reply-To: References: <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com> Message-ID: <9f0a72c1-130a-2a22-fb1a-1712ff79e138@oracle.com> On 10/1/18 10:46 AM, Martin Buchholz wrote: > This is one example of a change that should leave zero > impact on the generated bytecode, and that should be testable, if only by > comparing the .class files for identical size. This is a good point. I did something similar when I did the "diamond" conversion way back in JDK 7. That conversion didn't change any bytecodes, I compared class files to ensure the results were identical after the change. That provided greater assurance of correctness for large changesets. s'marks From stuart.marks at oracle.com Tue Oct 2 23:34:34 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 2 Oct 2018 16:34:34 -0700 Subject: Optimized HashSet.toArray() In-Reply-To: References: Message-ID: <0970e1c5-0c7e-64ea-5267-88f1d07296fd@oracle.com> Hi Tagir, Thanks for doing this! This looks like a good optimization. I can sponsor it for you. The preliminary patch looks fine. Too bad there's some code duplication. If this weren't HashMap, I'd suggest refactoring it and using a lambda expression. However, HashMap is used early in JDK startup and we generally avoid using lambdas and method references there. Thanks, s'marks On 9/30/18 10:03 PM, Tagir Valeev wrote: > Hello! > > I think that HashSet.toArray(), HashMap.keySet().toArray() and > HashMap.values().toArray() methods are used often enough to deserve a > dedicated optimized implementation. Here's the patch I propose which > is based on KeySet#forEach and AbstractCollection#toArray > implementations: > http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/patch.txt > > I performed quick JMH test for HashSet.toArray(). The source code is here: > http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/jmh/ToArray.java > > Result on JDK 11+28 is here: > http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/jmh/jmh_toArray_11.txt > > Result on JDK 11+28 with patch applied is here > http://cr.openjdk.java.net/~tvaleev/patches/hashset_toarray/jmh/jmh_toArray_11_patched.txt > > Summary (non-patched): > Benchmark (size) Score Error Units > ToArray.toArray 0 6,327 ? 0,094 ns/op > ToArray.toArray 1 55,040 ? 0,389 ns/op > ToArray.toArray 10 112,903 ? 3,571 ns/op > ToArray.toArray 1000 11281,875 ? 74,423 ns/op > ToArray.toArray 100000 2795345,640 ? 57164,196 ns/op > ToArray.toArray 10000000 443763064,267 ? 82551994,563 ns/op > ToArray.toArrayPresized 0 8,244 ? 0,054 ns/op > ToArray.toArrayPresized 1 57,094 ? 0,431 ns/op > ToArray.toArrayPresized 10 105,456 ? 3,831 ns/op > ToArray.toArrayPresized 1000 11935,895 ? 251,150 ns/op > ToArray.toArrayPresized 100000 2771938,363 ? 42917,423 ns/op > ToArray.toArrayPresized 10000000 421335484,317 ? 66222482,723 ns/op > ToArray.toObjectArray 0 8,288 ? 0,060 ns/op > ToArray.toObjectArray 1 49,415 ? 2,454 ns/op > ToArray.toObjectArray 10 94,243 ? 2,346 ns/op > ToArray.toObjectArray 1000 10061,125 ? 77,197 ns/op > ToArray.toObjectArray 100000 2455011,037 ? 86539,734 ns/op > ToArray.toObjectArray 10000000 416595706,650 ? 84619961,188 ns/op > > Summary (patched): > Benchmark (size) Score Error Units > ToArray.toArray 0 5,319 ? 0,050 ns/op > ToArray.toArray 1 22,235 ? 0,365 ns/op > ToArray.toArray 10 57,515 ? 0,687 ns/op > ToArray.toArray 1000 6586,112 ? 71,258 ns/op > ToArray.toArray 100000 1700754,903 ? 41289,676 ns/op > ToArray.toArray 10000000 299815797,250 ? 37778823,759 ns/op > ToArray.toArrayPresized 0 6,689 ? 0,042 ns/op > ToArray.toArrayPresized 1 44,852 ? 0,813 ns/op > ToArray.toArrayPresized 10 66,904 ? 0,748 ns/op > ToArray.toArrayPresized 1000 7839,880 ? 75,954 ns/op > ToArray.toArrayPresized 100000 1605381,429 ? 55070,143 ns/op > ToArray.toArrayPresized 10000000 292954965,933 ? 45912224,761 ns/op > ToArray.toObjectArray 0 6,608 ? 0,049 ns/op > ToArray.toObjectArray 1 28,085 ? 0,326 ns/op > ToArray.toObjectArray 10 58,170 ? 2,716 ns/op > ToArray.toObjectArray 1000 5979,407 ? 55,930 ns/op > ToArray.toObjectArray 100000 1420318,139 ? 27226,724 ns/op > ToArray.toObjectArray 10000000 255417541,372 ? 33366555,142 ns/op > > As you can see, the patched version is always faster, sometimes 2x and > even more. Also it doesn't allocate anything except the target array > when necessary (current version allocates an iterator). > > If anybody is interested to sponsor this change, I can log a JBS issue > and provide proper webrev for review. Do we need to add new unit-tests > or these methods are covered enough by existing tests? > > With best regards, > Tagir Valeev. > From lance.andersen at oracle.com Wed Oct 3 00:13:31 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 2 Oct 2018 20:13:31 -0400 Subject: RFR JDK-8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative In-Reply-To: <5BB3CF60.6050900@oracle.com> References: <5BB3CF60.6050900@oracle.com> Message-ID: Hi Sherman, The change looks fine > On Oct 2, 2018, at 4:04 PM, Xueming Shen wrote: > > Hi, > > Please help review the change for JDK-8211585. > > issue: https://bugs.openjdk.java.net/browse/JDK-8211385 > webrev: http://cr.openjdk.java.net/~sherman/8211385/webrev > > > Thanks, > Sherman Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From adinn at redhat.com Wed Oct 3 09:12:03 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 3 Oct 2018 10:12:03 +0100 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: On 02/10/18 19:17, Martin Buchholz wrote: > Raffaello and Ulf should talk. > It seems like Ulf's ryu project is trying to solve the same problem. > ryu is also still being worked on, but there is already a published paper > and ryu is being adopted by various core libraries. > https://github.com/ulfjack/ryu > https://dl.acm.org/citation.cfm?id=3192369 > Ulf, if you haven't already signed an Oracle Contributor Agreement for > openjdk, you should do so. > (Who knew printing floating point numbers could be so hard?) Well, Guy Steele and Jon L White, for starters (quite literally) [1] [1] https://dl.acm.org/citation.cfm?id=93559 regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Wed Oct 3 09:14:12 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 3 Oct 2018 10:14:12 +0100 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com> <50ed4716-b76e-6557-1146-03084776c160@redhat.com> <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> Message-ID: On 30/09/18 16:31, Alan Bateman wrote: > On 26/09/2018 14:27, Andrew Dinn wrote: >> : >> I'm not clear why we should only use one flag. The two flags I specified >> reflect two independent use cases, one where data stored in an NVM >> device is accessed read-only and another where it is accessed >> read-write. Are you suggesting that the read-only case is redundant? I'm >> not sure I agree. For example, a utility which might want to review the >> state of persistent data while a service is off-line would really want >> to pass flag READ_ONLY_PERSISTENT. Of course, it could employ >> READ_WRITE_PERSISTENT (or equivalently, SYNC) and just not write the >> data but, mutatis mutandis, that same argument would remove the case for >> flag READ_ONLY. >> > I'm wrong on this point. The map takes a single MapMode, not a set of > modes as I was assuming,? so you are right that it needs two new modes, > not one. I do think we should re-visit the name though as the native > flag is MAP_SYNC. Sure, I'd be happy to change this. Would READ_ONLY_SYNC and READ_WRITE_SYNC be suitable alternatives? Or do you have something else in mind? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From amaembo at gmail.com Wed Oct 3 10:29:24 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 3 Oct 2018 17:29:24 +0700 Subject: RFR(S): 8211441 Collection::removeIf spec does not say whether intermediate collection updates are visible to the filter function Message-ID: Hello! Please review and sponsor http://cr.openjdk.java.net/~tvaleev/webrev/8211441/r1/ https://bugs.openjdk.java.net/browse/JDK-8211441 Previous discussion: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055642.html With best regards, Tagir Valeev From Alan.Bateman at oracle.com Wed Oct 3 13:02:16 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Oct 2018 14:02:16 +0100 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak In-Reply-To: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> References: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> Message-ID: <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> On 02/10/2018 20:33, Mandy Chung wrote: > Class::newInstance maintains its separate cache of the caller > class after access check.? This leak has been there for a long > time and unnoticed. > > This patch changes Class::newInstance to use the code path > for Constructor::newInstance doing the access check and > caching the caller class.? It will also get the illegal > access check in effect when Class::newInstance is called > consistent with Constructor::newInstance. > > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.00 > > Alan raises a question whether the cache is still needed > given that we have improved the performance of slow > path of access check with Class::getPackageName.? It's a > good investigation to follow up. The changes look okay. One niggle is Cache.callerClassCache as nothing to do with Cache, maybe the method should be removed and the one usage changed to create the weak ref. On the benefit of the cache then I think it would be good to get some data on the benefit. Prior to the JDK 9 then I think most of the cost was checking the package but that has mostly disappeared with the changes in 9. -Alan From Alan.Bateman at oracle.com Wed Oct 3 13:43:33 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Oct 2018 14:43:33 +0100 Subject: RFR JDK-8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative In-Reply-To: <5BB3CF60.6050900@oracle.com> References: <5BB3CF60.6050900@oracle.com> Message-ID: <1fb990bc-be93-3cc4-12bb-f4175e180dbf@oracle.com> On 02/10/2018 21:04, Xueming Shen wrote: > Hi, > > Please help review the change for JDK-8211585. > > issue: https://bugs.openjdk.java.net/browse/JDK-8211385 > webrev: http://cr.openjdk.java.net/~sherman/8211385/webrev This looks okay although it might be cleaner for iteratorOf to take the directory as a parameter rather than path and a flag. -Alan. From Alan.Bateman at oracle.com Wed Oct 3 14:24:30 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Oct 2018 15:24:30 +0100 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com> <50ed4716-b76e-6557-1146-03084776c160@redhat.com> <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> Message-ID: On 03/10/2018 10:14, Andrew Dinn wrote: > : > Sure, I'd be happy to change this. > > Would READ_ONLY_SYNC and READ_WRITE_SYNC be suitable alternatives? Or do > you have something else in mind? > I think that works but it means looking at the proposed MappedByteBuffer::isPersistent too. MappedByteBuffer hasn't needed methods to test if the mapping is read-only, read-write or private mapping and I wonder if isPersistent is really needed. -Alan From mandy.chung at oracle.com Wed Oct 3 15:14:25 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 Oct 2018 08:14:25 -0700 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak In-Reply-To: <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> References: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> Message-ID: On 10/3/18 6:02 AM, Alan Bateman wrote: > > > On 02/10/2018 20:33, Mandy Chung wrote: >> Class::newInstance maintains its separate cache of the caller >> class after access check.? This leak has been there for a long >> time and unnoticed. >> >> This patch changes Class::newInstance to use the code path >> for Constructor::newInstance doing the access check and >> caching the caller class.? It will also get the illegal >> access check in effect when Class::newInstance is called >> consistent with Constructor::newInstance. >> >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.00 >> >> Alan raises a question whether the cache is still needed >> given that we have improved the performance of slow >> path of access check with Class::getPackageName.? It's a >> good investigation to follow up. > The changes look okay. One niggle is Cache.callerClassCache as nothing > to do with Cache, maybe the method should be removed and the one usage > changed to create the weak ref. > Thanks.? I have removed the callerClassCache method as you suggest. > On the benefit of the cache then I think it would be good to get some > data on the benefit. Prior to the JDK 9 then I think most of the cost > was checking the package but that has mostly disappeared with the > changes in 9. I created https://bugs.openjdk.java.net/browse/JDK-8211452 as a follow up. Mandy From peter.levart at gmail.com Wed Oct 3 16:30:46 2018 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 3 Oct 2018 18:30:46 +0200 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak In-Reply-To: References: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> Message-ID: <3f3273b9-0c4b-0a09-7295-d7084311f697@gmail.com> Hi Mandy, I don't know if this matters though, but should Reflection.getCallerClass() ever return null, previous behavior was to throw NPE (from Reflection.verifyMemberAccess(...)), now the checks are skipped. This should only be observable if [Class, Constructor].newInstance() was called from JNI's newly attached thread I believe. You know the inner workings of Reflection.getCallerClass() more than I do, so is it trust-able to always return non-null? Regards, Peter On 10/03/2018 05:14 PM, Mandy Chung wrote: > > > On 10/3/18 6:02 AM, Alan Bateman wrote: >> >> >> On 02/10/2018 20:33, Mandy Chung wrote: >>> Class::newInstance maintains its separate cache of the caller >>> class after access check.? This leak has been there for a long >>> time and unnoticed. >>> >>> This patch changes Class::newInstance to use the code path >>> for Constructor::newInstance doing the access check and >>> caching the caller class.? It will also get the illegal >>> access check in effect when Class::newInstance is called >>> consistent with Constructor::newInstance. >>> >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.00 >>> >>> Alan raises a question whether the cache is still needed >>> given that we have improved the performance of slow >>> path of access check with Class::getPackageName.? It's a >>> good investigation to follow up. >> The changes look okay. One niggle is Cache.callerClassCache as >> nothing to do with Cache, maybe the method should be removed and the >> one usage changed to create the weak ref. >> > > Thanks.? I have removed the callerClassCache method as you suggest. > >> On the benefit of the cache then I think it would be good to get some >> data on the benefit. Prior to the JDK 9 then I think most of the cost >> was checking the package but that has mostly disappeared with the >> changes in 9. > > I created https://bugs.openjdk.java.net/browse/JDK-8211452 as a follow > up. > > Mandy From mandy.chung at oracle.com Wed Oct 3 17:28:40 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 Oct 2018 10:28:40 -0700 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak In-Reply-To: <3f3273b9-0c4b-0a09-7295-d7084311f697@gmail.com> References: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> <3f3273b9-0c4b-0a09-7295-d7084311f697@gmail.com> Message-ID: On 10/3/18 9:30 AM, Peter Levart wrote: > Hi Mandy, > > I don't know if this matters though, but should > Reflection.getCallerClass() ever return null, previous behavior was to > throw NPE (from Reflection.verifyMemberAccess(...)), now the checks > are skipped. This should only be observable if [Class, > Constructor].newInstance() was called from JNI's newly attached thread > I believe. Yes that's the case.?? Such case never works as it will get NPE.? I didn't worry too much about it.? Since you mentioned it, I should keep the existing behavior (throwing NPE): http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.01 Mandy From mandy.chung at oracle.com Wed Oct 3 17:56:51 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 Oct 2018 10:56:51 -0700 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass Message-ID: This patch replaces java.lang.invoke and JFR use of jdk.internal.misc.Unsafe::defineClass with Lookup::defineClass. It also replaces dynamic proxy and reflection implementation to use the shared secret to invoke ClassLoader::defineClass. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8181443/webrev.00 With this change, JDK no longer uses Unsafe::defineClass. Any opinion in removing Unsafe::defineClass support? I ran jdk_core, jdk_jfr, tier1_runtime and tier1_compiler tests. thanks Mandy From erik.gahlin at oracle.com Wed Oct 3 18:12:45 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 3 Oct 2018 20:12:45 +0200 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass In-Reply-To: References: Message-ID: <66B9B46E-CFCD-49DB-9FCA-3B9F08AA6C2F@oracle.com> JFR changes looks good. Erik > On 3 Oct 2018, at 19:56, Mandy Chung wrote: > > This patch replaces java.lang.invoke and JFR use of > jdk.internal.misc.Unsafe::defineClass with Lookup::defineClass. > It also replaces dynamic proxy and reflection implementation to > use the shared secret to invoke ClassLoader::defineClass. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8181443/webrev.00 > > With this change, JDK no longer uses Unsafe::defineClass. > Any opinion in removing Unsafe::defineClass support? > > I ran jdk_core, jdk_jfr, tier1_runtime and tier1_compiler tests. > > thanks > Mandy > > > From xueming.shen at oracle.com Wed Oct 3 18:45:52 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 03 Oct 2018 11:45:52 -0700 Subject: RFR JDK-8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative In-Reply-To: <1fb990bc-be93-3cc4-12bb-f4175e180dbf@oracle.com> References: <5BB3CF60.6050900@oracle.com> <1fb990bc-be93-3cc4-12bb-f4175e180dbf@oracle.com> Message-ID: <5BB50E60.2090606@oracle.com> On 10/3/18, 6:43 AM, Alan Bateman wrote: > > > On 02/10/2018 21:04, Xueming Shen wrote: >> Hi, >> >> Please help review the change for JDK-8211585. >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8211385 >> webrev: http://cr.openjdk.java.net/~sherman/8211385/webrev > This looks okay although it might be cleaner for iteratorOf to take > the directory as a parameter rather than path and a flag. > > -Alan. Thanks Alan! Take a second look, since the "resolved" is cached in ZipPath, it appears the "path" is actually not necessary. "ZipPath dir" is good enough here. Webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8211385/webrev/ sherman From philipp.kunz at paratix.ch Wed Oct 3 18:55:45 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Wed, 03 Oct 2018 20:55:45 +0200 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: <1537938483.2077.4.camel@paratix.ch> References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> Message-ID: <1538592945.2782.4.camel@paratix.ch> In short, bug 6202130 is about removal of comments in Attributes like > XXX Need to handle UTF8 values and break up lines longer than 72 The patch here contains a test that shows that utf characters are handled correctly, which has been the case before. Breaking lines has also been working before. In the?main code, the patch only removes a few comments and does not change actual code. It all has been working before and now we know. Philipp https://bugs.openjdk.java.net/browse/JDK-6202130 On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > Hi, > > There are some comments in the source code like this: > > > XXX Need to handle UTF8 values and break up lines longer than 72 bytes > > in Attributes.java on lines 299, 327, and 370. Bug 6202130 also suggests > to add a test to show that the character set is fully supported before > actually removing those comments. > > Hence, I added such a test, see ValueUtfEncoding in attached patch, and > it finds the complete utf character set supported correctly and that it > has been so already before. > > The comments in Attributes also say that lines longer than 72 bytes need > to be broken. That is a different issue and has been already addressed > and solved in bug 6372077 and is now tested in LineBreakLineWidth and > therefore, that line break part of the comment is obsolete now as well > with the exception of version headers ("Manifest-Version" or > "Signature-Version") at least when taking strictly. > > Version headers are not subject of bug 6202130 for which my patch > intends to provide a fix and if only because multi-byte characters are > not allowed in version headers and wasn't subject of 6372077 either > which was about too short lines rather than too long ones. If I would > change only the minimum I could argue was safe, there would have to > remain a comment in Attributes.java on line 327 like > > > XXX Need to handle version headers longer than 72 bytes > > but I guess that should probably better be represented as another bug > rather than this style of comment if at all desired. There are some bugs > concerning version headers and particularly the behavior of the > manifests in their absence, among possibly others, 6910466, 4935610, > 4271239, 8196371 and 4256580 which have some relation but I haven't > found one that really fits the 72 byte line length limit of version > headers. Whether such a bug is created or found or not, it does not > directly relate to the one I'm trying to fix here, 6202130. > > If also the test is good I would assume that the comments can be > removed now without actually changing the Manifest and Attributes > implementation. > > Regards, > Philipp > -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130.patch Type: text/x-patch Size: 10222 bytes Desc: not available URL: From kim.barrett at oracle.com Wed Oct 3 19:13:15 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Oct 2018 15:13:15 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features Message-ID: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> I've submitted a JEP for (1) enabling the use of C++14 Language Features when building the JDK, (2) define a process for deciding and documenting which new features can be used or are forbidden in HotSpot code, (3) provide an initial list of permitted and forbidden new features. https://bugs.openjdk.java.net/browse/JDK-8208089 From Alan.Bateman at oracle.com Wed Oct 3 19:39:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Oct 2018 20:39:21 +0100 Subject: RFR JDK-8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths when directory is relative In-Reply-To: <5BB50E60.2090606@oracle.com> References: <5BB3CF60.6050900@oracle.com> <1fb990bc-be93-3cc4-12bb-f4175e180dbf@oracle.com> <5BB50E60.2090606@oracle.com> Message-ID: <39de2261-c2a1-0cb3-b517-4a1574624e0c@oracle.com> On 03/10/2018 19:45, Xueming Shen wrote: > Thanks Alan! > > Take a second look, since the "resolved" is cached in ZipPath, it > appears the > "path" is actually not necessary. "ZipPath dir" is good enough here. > > Webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/8211385/webrev/ This looks much better - thanks! -Alan From xueming.shen at oracle.com Wed Oct 3 19:48:42 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 03 Oct 2018 12:48:42 -0700 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: <1538592945.2782.4.camel@paratix.ch> References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> Message-ID: <5BB51D1A.2000600@oracle.com> +1 only nit is it might be preferred to use "utf8" directly in the test instead of current "utf" -sherman On 10/03/2018 11:55 AM, Philipp Kunz wrote: > In short, bug 6202130 is about removal of comments in Attributes like > >> XXX Need to handle UTF8 values and break up lines longer than 72 > The patch here contains a test that shows that utf characters are > handled correctly, which has been the case before. Breaking lines has > also been working before. > > In the main code, the patch only removes a few comments and does not > change actual code. It all has been working before and now we know. > > Philipp > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: >> Hi, >> >> There are some comments in the source code like this: >> >> > XXX Need to handle UTF8 values and break up lines longer than 72 bytes >> >> in Attributes.java on lines 299, 327, and 370. Bug 6202130 also suggests >> to add a test to show that the character set is fully supported before >> actually removing those comments. >> >> Hence, I added such a test, see ValueUtfEncoding in attached patch, and >> it finds the complete utf character set supported correctly and that it >> has been so already before. >> >> The comments in Attributes also say that lines longer than 72 bytes need >> to be broken. That is a different issue and has been already addressed >> and solved in bug 6372077 and is now tested in LineBreakLineWidth and >> therefore, that line break part of the comment is obsolete now as well >> with the exception of version headers ("Manifest-Version" or >> "Signature-Version") at least when taking strictly. >> >> Version headers are not subject of bug 6202130 for which my patch >> intends to provide a fix and if only because multi-byte characters are >> not allowed in version headers and wasn't subject of 6372077 either >> which was about too short lines rather than too long ones. If I would >> change only the minimum I could argue was safe, there would have to >> remain a comment in Attributes.java on line 327 like >> >> > XXX Need to handle version headers longer than 72 bytes >> >> but I guess that should probably better be represented as another bug >> rather than this style of comment if at all desired. There are some bugs >> concerning version headers and particularly the behavior of the >> manifests in their absence, among possibly others, 6910466, 4935610, >> 4271239, 8196371 and 4256580 which have some relation but I haven't >> found one that really fits the 72 byte line length limit of version >> headers. Whether such a bug is created or found or not, it does not >> directly relate to the one I'm trying to fix here, 6202130. >> >> If also the test is good I would assume that the comments can be >> removed now without actually changing the Manifest and Attributes >> implementation. >> >> Regards, >> Philipp From Alan.Bateman at oracle.com Wed Oct 3 19:49:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 Oct 2018 20:49:14 +0100 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass In-Reply-To: References: Message-ID: On 03/10/2018 18:56, Mandy Chung wrote: > This patch replaces java.lang.invoke and JFR use of > jdk.internal.misc.Unsafe::defineClass with Lookup::defineClass. > It also replaces dynamic proxy and reflection implementation to > use the shared secret to invoke ClassLoader::defineClass. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8181443/webrev.00 > > With this change, JDK no longer uses Unsafe::defineClass. > Any opinion in removing Unsafe::defineClass support? > > I ran jdk_core, jdk_jfr, tier1_runtime and tier1_compiler tests. > This change looks okay to me. Nothing outside of java.base should be making direct use of classes in jdk.internal.misc so it's okay to refactor or remove classes or methods as needed. In this case, the internal defineClass is an attractive nuisance as there may be libraries tempted to hack into it. So I think it should be removed at some point. -Alan From sean.mullan at oracle.com Wed Oct 3 20:12:39 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 3 Oct 2018 16:12:39 -0400 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: References: Message-ID: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> For those of you that are not also subscribed to security-dev, this is mostly FYI, as the review is winding down, but if you have any comments, let me know. This change will add new token options ("allow" and "disallow") to the java.security.manager system property. The "disallow" option is intended to provide a potential performance boost for applications that don't enable a SecurityManager, as there is a cost associated with allowing a SecurityManager to enabled at runtime, even if it is never enabled. The CSR provides a good summary of the issue and spec changes: https://bugs.openjdk.java.net/browse/JDK-8203316 Thanks, Sean -------- Forwarded Message -------- Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable Date: Tue, 2 Oct 2018 11:34:09 -0400 From: Sean Mullan Organization: Oracle Corporation To: security Dev OpenJDK Hello, Thanks for all the comments so far, and the interesting discussions about the future of the SecurityManager. We will definitely return to those discussions in the near future, but for now I have a second webrev ready for review for this enhancement: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ The main changes since the initial revision are: 1. System.setSecurityManager is no longer deprecated. This type of change clearly needs more discussion and is not an essential part of this RFE. 2. After further thought, I took Bernd's suggestion [1] and instead of adding a new property to disallow the setting of a SecurityManager at runtime, have added new tokens to the existing "java.security.manager" system property, named "=disallow", and "=allow" to toggle this behavior. The "=" is to avoid any potential clashes with custom SM classes with those names. I think this is a cleaner approach. There are a couple of new paragraphs in the SecurityManager class description describing the "java.security.manager" property and how the new tokens work. 3. I also added a comment that Bernd had requested [2] on why System.setSecurityManager calls checkPackageAccess("java.lang"). Also, the CSR has been updated: https://bugs.openjdk.java.net/browse/JDK-8203316 Thanks, Sean [1] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html [2] http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html On 9/13/18 4:02 PM, Sean Mullan wrote: > This is a SecurityManager related change which warrants some additional > details for its motivation. > > The current System.setSecurityManager() API allows a SecurityManager to > be set at run-time. However, because of this mutability, it incurs a > performance overhead even for applications that never call it and do not > enable a SecurityManager dynamically, which is probably the majority of > applications. > > For example, there are lots of "SecurityManager sm = > System.getSecurityManager(); if (sm != null) ..." checks in the JDK. If > it was known that a SecurityManager could never be set at run-time, > these checks could be optimized using constant-folding. > > There are essentially two main parts to this change: > > 1. Deprecation of System.securityManager() > > Going forward, we want to discourage applications from calling > System.setSecurityManager(). Instead they should enable a > SecurityManager using the java.security.manager system property on the > command-line. > > 2. A new JDK-specific system property to disallow the setting of the > security manager at run-time: jdk.allowSecurityManager > > If set to false, it allows the run-time to optimize the code and improve > performance when it is known that an application will never run with a > SecurityManager. To support this behavior, the > System.setSecurityManager() API has been updated such that it can throw > an UnsupportedOperationException if it does not allow a security manager > to be set dynamically. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 > JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 > > (I will likely also send this to core-libs for additional review later) > > --Sean From mark.reinhold at oracle.com Wed Oct 3 23:55:37 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 03 Oct 2018 16:55:37 -0700 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <20181003165537.306971476@eggemoggin.niobe.net> 2018/10/3 12:13:15 -0700, kim.barrett at oracle.com: > ... > > https://bugs.openjdk.java.net/browse/JDK-8208089 Or, more readably: https://openjdk.java.net/jeps/8208089 - Mark From Sergey.Bylokhov at oracle.com Thu Oct 4 00:52:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 3 Oct 2018 17:52:16 -0700 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> References: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> Message-ID: <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> Hi, Sean. One question related to SecurityManager and performance, is it possible to provide a special version of AccessController.doPrivileged which will be noop if SecurityManager is not present? On 03/10/2018 13:12, Sean Mullan wrote: > For those of you that are not also subscribed to security-dev, this is > mostly FYI, as the review is winding down, but if you have any comments, > let me know. > > This change will add new token options ("allow" and "disallow") to the > java.security.manager system property. The "disallow" option is intended > to provide a potential performance boost for applications that don't > enable a SecurityManager, as there is a cost associated with allowing a > SecurityManager to enabled at runtime, even if it is never enabled. The > CSR provides a good summary of the issue and spec changes: > https://bugs.openjdk.java.net/browse/JDK-8203316 > > Thanks, > Sean > > -------- Forwarded Message -------- > Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's > security manager immutable > Date: Tue, 2 Oct 2018 11:34:09 -0400 > From: Sean Mullan > Organization: Oracle Corporation > To: security Dev OpenJDK > > Hello, > > Thanks for all the comments so far, and the interesting discussions > about the future of the SecurityManager. We will definitely return to > those discussions in the near future, but for now I have a second webrev > ready for review for this enhancement: > > http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ > > The main changes since the initial revision are: > > 1. System.setSecurityManager is no longer deprecated. This type of > change clearly needs more discussion and is not an essential part of > this RFE. > > 2. After further thought, I took Bernd's suggestion [1] and instead of > adding a new property to disallow the setting of a SecurityManager at > runtime, have added new tokens to the existing "java.security.manager" > system property, named "=disallow", and "=allow" to toggle this > behavior. The "=" is to avoid any potential clashes with custom SM > classes with those names. I think this is a cleaner approach. There are > a couple of new paragraphs in the SecurityManager class description > describing the "java.security.manager" property and how the new tokens > work. > > 3. I also added a comment that Bernd had requested [2] on why > System.setSecurityManager calls checkPackageAccess("java.lang"). > > Also, the CSR has been updated: > https://bugs.openjdk.java.net/browse/JDK-8203316 > > Thanks, > Sean > > [1] > http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html > > > On 9/13/18 4:02 PM, Sean Mullan wrote: >> This is a SecurityManager related change which warrants some >> additional details for its motivation. >> >> The current System.setSecurityManager() API allows a SecurityManager >> to be set at run-time. However, because of this mutability, it incurs >> a performance overhead even for applications that never call it and do >> not enable a SecurityManager dynamically, which is probably the >> majority of applications. >> >> For example, there are lots of "SecurityManager sm = >> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. >> If it was known that a SecurityManager could never be set at run-time, >> these checks could be optimized using constant-folding. >> >> There are essentially two main parts to this change: >> >> 1. Deprecation of System.securityManager() >> >> Going forward, we want to discourage applications from calling >> System.setSecurityManager(). Instead they should enable a >> SecurityManager using the java.security.manager system property on the >> command-line. >> >> 2. A new JDK-specific system property to disallow the setting of the >> security manager at run-time: jdk.allowSecurityManager >> >> If set to false, it allows the run-time to optimize the code and >> improve performance when it is known that an application will never >> run with a SecurityManager. To support this behavior, the >> System.setSecurityManager() API has been updated such that it can >> throw an UnsupportedOperationException if it does not allow a security >> manager to be set dynamically. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >> >> (I will likely also send this to core-libs for additional review later) >> >> --Sean -- Best regards, Sergey. From goetz.lindenmaier at sap.com Thu Oct 4 06:59:03 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 06:59:03 +0000 Subject: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <71fb517fba794dc28291cf51afb6e8b9@sap.com> Hi, I appreciate this is handled in a JEP and well communicated! XLc, the compiler we use for AIX, might be a bottleneck here. But we currently have no compiler-constraints by products on our aix port of jdk12 (for jdk11 we must stay with the current compiler xlc 12 which does not support C++11, and jdk11 even should be compilable with aCC by HP for which we won't get new versions!) We will update our compiler for jdk/jdk to the most recent Xlc as soon as possible. To my current knowledge, Xlc 14 was dropped, and xlc 16 is to be released early 2019. It is supposed to support C++ 11, and also some C++ 14 features. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Kim Barrett > Sent: Mittwoch, 3. Oktober 2018 21:13 > To: hotspot-dev developers > Cc: build-dev ; core-libs- > dev at openjdk.java.net > Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features > > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 From volker.simonis at gmail.com Thu Oct 4 08:35:06 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Oct 2018 11:35:06 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: Hi Tim, Jeff, Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) https://bugs.openjdk.java.net/browse/JDK-8208089 Could you please provide a summary of which of these features are already available since which version of xlC for AIX and potentially escalate the implementation of the missing features within IBM?s xlC on AIX team. Thank you and best regards, Volker Kim Barrett schrieb am Mi. 3. Okt. 2018 um 22:13: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > From martijnverburg at gmail.com Thu Oct 4 08:57:43 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 4 Oct 2018 09:57:43 +0100 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: Hi Kim, I like this initiative. I'm wondering if some of these rules can be easily codified or written into a jcheck style checker (ccheck?) so that Authors can adhere to the conventions and not rely on a Human review to pick out where that convention isn't met. Cheers, Martijn On Wed, 3 Oct 2018 at 20:13, Kim Barrett wrote: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > From jai.forums2013 at gmail.com Thu Oct 4 09:36:23 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 4 Oct 2018 15:06:23 +0530 Subject: JarFile constructor throws undocumented exception (only) on Windows OS Message-ID: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> Please consider the following trivial code: import java.util.jar.*; import java.io.*; public class JarFileTest { ??? public static void main(final String[] args) throws Exception { ??? ??? final String tmpDir = System.getProperty("java.io.tmpdir"); ??? ??? try { ??? ??? ??? final JarFile jarFile = new JarFile(tmpDir + File.separator + "*"); ??? ??? } catch (IOException ioe) { ??? ??? ??? System.out.println("Got the expected IOException " + ioe); ??? ??? } ??? } } The constructor of the JarFile is passed a string which intentionally is an (wildcard) invalid path. The above code (as expected) throws an IOException on *nix systems across various version of Java (tested against Java 8, 11). The same code throws an IOException (as expected) in Java 8 on Windows OS too. However, in Java 11, on Windows OS, this code throws a different exception (java.nio.file.InvalidPathException) which isn't IOException or a subclass of it: Exception in thread "main" java.nio.file.InvalidPathException: Illegal char <*> at index 38: C:\Users\someone\AppData\Local\Temp\1\* at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229) at java.base/java.io.File.toPath(File.java:2290) at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1220) at java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727) at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:845) at java.base/java.util.zip.ZipFile.(ZipFile.java:245) at java.base/java.util.zip.ZipFile.(ZipFile.java:175) at java.base/java.util.jar.JarFile.(JarFile.java:341) at java.base/java.util.jar.JarFile.(JarFile.java:312) at java.base/java.util.jar.JarFile.(JarFile.java:251) at JarFileTest.main(JarFileTest.java:8) The javadoc of JarFile constructor(s) mentions that: ???? * @throws IOException if an I/O error has occurred Given that the javadoc doesn't mention anything about this other exception, would this throwing of java.nio.file.InvalidPathException be considered a bug in the implementation? If this indeed is considered a bug, it appears to be the code in java.util.zip.ZipFile$Source.get method which calls File#toPath(), which as per its javadoc is indeed expected to throw an java.nio.file.InvalidPathException if a Path cannot be constructed out of the File. Looking at the implementation of the underlying java.nio.file.FileSystem on *nix and Windows, they differ when it comes to whether or not the exception gets thrown (Unix one seems to always return a result). But keeping the implementation of java.nio.file.FileSystem aside, I guess the java.util.zip.ZipFile$Source.get code needs to have a catch block for the InvalidPathException to wrap that into a IOException? Something like: # HG changeset patch # User Jaikiran Pai # Date 1538645309 -19800 #????? Thu Oct 04 14:58:29 2018 +0530 # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e # Parent? 8705c6d536c5c197d0210acccf145ebc48f90227 Wrap and throw an IOException when a InvalidPathException is thrown diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java --- a/src/java.base/share/classes/java/util/zip/ZipFile.java +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java @@ -35,6 +35,7 @@ ?import java.lang.ref.Cleaner.Cleanable; ?import java.nio.charset.Charset; ?import java.nio.charset.StandardCharsets; +import java.nio.file.InvalidPathException; ?import java.nio.file.attribute.BasicFileAttributes; ?import java.nio.file.Files; ?import java.util.ArrayDeque; @@ -1218,8 +1219,13 @@ ? ? ???????? static Source get(File file, boolean toDelete) throws IOException { -??????????? Key key = new Key(file, -????????????????????????????? Files.readAttributes(file.toPath(), BasicFileAttributes.class)); +??????????? final Key key; +??????????? try { +??????????????? key = new Key(file, +??????????????????????? Files.readAttributes(file.toPath(), BasicFileAttributes.class)); +??????????? } catch (InvalidPathException ipe) { +??????????????? throw new IOException(ipe); +??????????? } ???????????? Source src; ???????????? synchronized (files) { ???????????????? src = files.get(key); Any thoughts? -Jaikiran From magnus.ihse.bursie at oracle.com Thu Oct 4 12:31:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 4 Oct 2018 14:31:43 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <940757E3-8781-4E7A-B5B9-1F0D3E944E0F@oracle.com> > 4 okt. 2018 kl. 10:57 skrev Martijn Verburg : > > Hi Kim, > > I like this initiative. I'm wondering if some of these rules can be easily > codified or written into a jcheck style checker (ccheck?) so that Authors > can adhere to the conventions and not rely on a Human review to pick out > where that convention isn't met. That's an interesting thought! I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.) I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code. Neither seem like an ideal solution. The Google tool is hard coded to support the Google rules. It's possible we can fork it and add our own, but it's not clear that this is even possible, much less so that it's a good way forward. Vera++, on the other hand, seems much more likely to be able to provide the tooling needed to write checks that enforce these rules. However, what we have is just a framework, and someone's got to write those rules (in TCL of all languages...). Then again, Vera++ is an old and quite popular tool, so its possible there is already a bunch of predefined rules that we can use as a starting point out there. (I didn't go that far in my analysis). Apart from these two, there appear to be no popular, well-encompassing, open source C++ checker out there, that could possibly be verifying rules like these. :( /Magnus [1] https://github.com/google/styleguide/tree/gh-pages/cpplint [2] https://google.github.io/styleguide/cppguide.html [3] https://bitbucket.org/verateam/vera/wiki/Introduction > > Cheers, > Martijn > > >> On Wed, 3 Oct 2018 at 20:13, Kim Barrett wrote: >> >> I've submitted a JEP for >> >> (1) enabling the use of C++14 Language Features when building the JDK, >> >> (2) define a process for deciding and documenting which new features >> can be used or are forbidden in HotSpot code, >> >> (3) provide an initial list of permitted and forbidden new features. >> >> https://bugs.openjdk.java.net/browse/JDK-8208089 >> >> From sean.mullan at oracle.com Thu Oct 4 12:50:14 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 Oct 2018 08:50:14 -0400 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> References: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> Message-ID: <0a8fa2f0-07de-ada6-8331-ea9d3c054365@oracle.com> On 10/3/18 8:52 PM, Sergey Bylokhov wrote: > Hi, Sean. > One question related to SecurityManager and performance, is it possible > to provide a special version of AccessController.doPrivileged which will > be noop if SecurityManager is not present? Yes, it may be possible, and we have prototyped it. But I didn't want to mix it up with this one as it has some different specification challenges -- for example, the AccessController APIs can be used independently of the SecurityManager. I plan to get back to this one soon and hope to have something that can be reviewed a bit later. Thanks, Sean > > On 03/10/2018 13:12, Sean Mullan wrote: >> For those of you that are not also subscribed to security-dev, this is >> mostly FYI, as the review is winding down, but if you have any >> comments, let me know. >> >> This change will add new token options ("allow" and "disallow") to the >> java.security.manager system property. The "disallow" option is >> intended to provide a potential performance boost for applications >> that don't enable a SecurityManager, as there is a cost associated >> with allowing a SecurityManager to enabled at runtime, even if it is >> never enabled. The CSR provides a good summary of the issue and spec >> changes: https://bugs.openjdk.java.net/browse/JDK-8203316 >> >> Thanks, >> Sean >> >> -------- Forwarded Message -------- >> Subject: Re: RFR (12): 8191053: Provide a mechanism to make system's >> security manager immutable >> Date: Tue, 2 Oct 2018 11:34:09 -0400 >> From: Sean Mullan >> Organization: Oracle Corporation >> To: security Dev OpenJDK >> >> Hello, >> >> Thanks for all the comments so far, and the interesting discussions >> about the future of the SecurityManager. We will definitely return to >> those discussions in the near future, but for now I have a second >> webrev ready for review for this enhancement: >> >> http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.01/ >> >> The main changes since the initial revision are: >> >> 1. System.setSecurityManager is no longer deprecated. This type of >> change clearly needs more discussion and is not an essential part of >> this RFE. >> >> 2. After further thought, I took Bernd's suggestion [1] and instead of >> adding a new property to disallow the setting of a SecurityManager at >> runtime, have added new tokens to the existing "java.security.manager" >> system property, named "=disallow", and "=allow" to toggle this >> behavior. The "=" is to avoid any potential clashes with custom SM >> classes with those names. I think this is a cleaner approach. There >> are a couple of new paragraphs in the SecurityManager class >> description describing the "java.security.manager" property and how >> the new tokens work. >> >> 3. I also added a comment that Bernd had requested [2] on why >> System.setSecurityManager calls checkPackageAccess("java.lang"). >> >> Also, the CSR has been updated: >> https://bugs.openjdk.java.net/browse/JDK-8203316 >> >> Thanks, >> Sean >> >> [1] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018217.html >> >> [2] >> http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018193.html >> >> >> On 9/13/18 4:02 PM, Sean Mullan wrote: >>> This is a SecurityManager related change which warrants some >>> additional details for its motivation. >>> >>> The current System.setSecurityManager() API allows a SecurityManager >>> to be set at run-time. However, because of this mutability, it incurs >>> a performance overhead even for applications that never call it and >>> do not enable a SecurityManager dynamically, which is probably the >>> majority of applications. >>> >>> For example, there are lots of "SecurityManager sm = >>> System.getSecurityManager(); if (sm != null) ..." checks in the JDK. >>> If it was known that a SecurityManager could never be set at >>> run-time, these checks could be optimized using constant-folding. >>> >>> There are essentially two main parts to this change: >>> >>> 1. Deprecation of System.securityManager() >>> >>> Going forward, we want to discourage applications from calling >>> System.setSecurityManager(). Instead they should enable a >>> SecurityManager using the java.security.manager system property on >>> the command-line. >>> >>> 2. A new JDK-specific system property to disallow the setting of the >>> security manager at run-time: jdk.allowSecurityManager >>> >>> If set to false, it allows the run-time to optimize the code and >>> improve performance when it is known that an application will never >>> run with a SecurityManager. To support this behavior, the >>> System.setSecurityManager() API has been updated such that it can >>> throw an UnsupportedOperationException if it does not allow a >>> security manager to be set dynamically. >>> >>> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8203316 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8191053 >>> >>> (I will likely also send this to core-libs for additional review later) >>> >>> --Sean > > From ulfjack at google.com Thu Oct 4 13:22:55 2018 From: ulfjack at google.com (Ulf Adams) Date: Thu, 4 Oct 2018 15:22:55 +0200 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: <21df26c8-97a4-e339-baa2-fade0f1216fa@redhat.com> <2181f074-15b8-ed37-2f64-b675249216ac@gmail.com> Message-ID: Very cool! On Fri, Sep 28, 2018 at 5:15 PM Dmitry Nadezhin wrote: > I would like to tell about some steps towards formal check of Raffaello's > human proof. > I work on formal verification of some Oracle projects but they are > unrelated to JDK. > In April Brian Burkhalter requested me to review the Raffaello's paper. > His paper is smart and clear but nevertheless I was afraid to miss some > possible error in his it. > So I decided to check his proofs formally. I am familiar with a proof > checker ACL2 [1]. So I used it. > ACL2 is an abbreviation of "Applicative Common Lisp". It is both a language > ( a subset of Common Lisp ) and > proof assistant for reasoning about functions in this language. It is > open-source and it is developed in UT at Austin. > > This work in progress can be found in this GitHub repository [2]. > ACL2 definitions and proofs followed human definitions and proofs as > possible. > Materials of N-th section of the paper are in a file acl2/sectionN.lisp . > Proofs from sections 2-10 were checked by ACL2 completely. > Also cases fullCaseXS and fullCaseXM from the sections 2-11 were checked by > ACL2. > Sorry, I didn't finish formal proof of the entire paper in anticipation of > a new algorithm. > > Sometimes in July a paper by Michel Hack [3] prompted us that it is > possible to avoid multi-precision arithmetic. > File acl2/cont-fractions.lisp formalizes some of Michel's ideas in ACL2. > It considers a linear mapping alpha*d from range of naturals 0 <= d <= > max-d to rationals. > It defines an algorithms which for given alpha and "max-d" returns bound > "lo" and "hi" > how non-integer results of this mapping are frar from integer grid. > If approximate computations shows that alpha*d is very close to some > integer m > m - hi < alpha * d < m + lo > then alpha * d is equal to m exactly. > Theorems frac-alpha-d-nonzero-bound-dp-correct and > frac-alpha-d-nonzero-bound-sp-correct explicitly > state bounds lo and hi for float and double Java formats. > This fact is proved using continous fractions. > > Raffaello derived from this theorem that a table of powers of 5 with > 126-bit precision is enough > to correctly implement DoubleToString conversion. > He designed a new implementation of DoubleToString and FloatToString and > presented it in this core-libs-dev thread. > It was exciting to know that Ulf Adama also developed fast conversion > algorithm. > New Raffaello's and Ulf's algorithms looks similar. > It would be interesting to compare them, to match similarities and to think > on differences. > For example the problem of finding "lo" and "hi" is formulated as computing > minimum and maximum of a modular product in Ilf's paper. > It would be interesting to check if our lo-hi bounds are scaled versions of > Ulf's minimum and maximum. > I believe that my minmax proof applies to Raffaello's algorithm as well, and I get slightly tighter bounds (124 vs. 126). I have some work-in-progress to find even tighter bounds, though I'm not sure yet if it will work out. I found a method to compute a counter-example if there aren't enough bits, but I'm not sure whether it's exhaustive (whether it's guaranteed to find a counter-example if one exists). It doesn't make a difference in this case, as long as it's <= 128 bits (or maybe < 128 to avoid overflow in some cases). > Ideally it would be interesting to formally verify both of them though I am > not sure if I find time for this. > > If Raffaello prepares a new paper with proof of his new algorithm then I > will try to check these new proofs by ACL2 again. > I hope that paper with its formal check will increase confidence. > > --- > > Andrew Dinn said about other problem: "how details of specific coding > operations are not always clearly > identifiable from an abstract mathematical treatment.". Formal verification > is applicable for this also. > It can be done either at Java language level or at classfile level. > > Verification at classfile level requires formal model of JVM. > There are at least three models of JVM in ACL2: > i) An M5 model in the distribution of ACL2 books: [4] > ii) Defensive JVM model by CLI: [5] > iii) M6 model by Hamling Liu: [6] > > Verification at Java language level can be done using other tools, > especially the KeY tool: [7]. > TimSort bug [8][ has been found during to attempt to verify this > alogorithm's implementation by KeY. > > Unfortunately I am not sure that I find time to verify implementation > (classfile or Java-file) of the new Raffaello algorithm. > > --- > > [1] http://www.cs.utexas.edu/~moore/acl2/ > > [2] https://github.com/nadezhin/verify-todec > > [3] > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.8351&rep=rep1&type=pdf#page=114 > > [4] https://github.com/acl2/acl2/tree/master/books/models/jvm/m5 > > [5] http://www.computationallogic.com/software/djvm/index.html > > [6] https://github.com/haliu/M6 > > [7] https://www.key-project.org/ > > [8] > > http://www.envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/ > > On Fri, Sep 28, 2018 at 1:11 AM Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > > > On Sep 27, 2018, at 9:00 AM, Raffaello Giulietti < > > raffaello.giulietti at gmail.com> wrote: > > > > > On 2018-09-27 17:53, Andrew Dinn wrote: > > >> On 27/09/18 16:37, Raffaello Giulietti wrote: > > >> . . . > > >>> I thank you in advance for your willingness to review the code but my > > >>> understanding is that only the officially appointed reviewers can > > >>> approve OpenJDK contributions, which is of course a good policy. > > >>> Besides, as two Andrews engineers from RedHat correctly observe, > > >>> understanding the rationale of the code without the planned > > accompanying > > >>> paper is hard. > > >> Oh no, let me stop you right there! Anyone competent can offer a > review > > >> (well incompetent people can too but let's assume they get ignored > :-). > > >> Indeed, an expert critique is always very welcome and reviewers > normally > > >> get credited even if they have no official status. The official > > >> reviewers are needed for a final say so. No one sensible is going to > > >> reject clear and clearly justified advice. > > > > > > An excellent policy, indeed! > > > > I was going to reply with essentially the same comments. While an > > imprimatur from at least one sanctioned OpenJDK reviewer is required > > eventually, comments and review from any competent parties are most > > welcome. This is especially the case for a relatively complicated topic > > such as the one of this thread. > > > > >>>> I'm not a contributor to the Jdk, and this isn't my full-time job. I > > >>>> was lurking here because I was going to send a patch for the double > to > > >>>> string conversion code myself (based on Ryu). > > >>>> > > >>> > > >>> All my efforts on this projects are done in my unpaid spare time, > too. > > >> Which is very much appreciated, thank you. > > > > > > Thank all of you for your interest in this issue. > > > > I would like to second that. It is great to see so many comments on this > > topic and to have knowledgable people paying attention. > > > > Brian > From ulfjack at google.com Thu Oct 4 13:28:04 2018 From: ulfjack at google.com (Ulf Adams) Date: Thu, 4 Oct 2018 15:28:04 +0200 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: On Thu, Sep 27, 2018 at 5:37 PM Raffaello Giulietti < raffaello.giulietti at gmail.com> wrote: > Hi Ulf, > > > On 2018-09-27 16:40, Ulf Adams wrote: > > Hi Raffaello, > > > > I am the author of a recent publication on double to string conversion > > [1] - the Ryu algorithm. I've been aware of the problems with the Jdk > > for several years, and am very much looking forward to improvements in > > correctness and performance in this area. > > > > What a coincidence! I'm happy to hear that the quest for better > floating->string conversions has not stopped. Tomorrow I'll download > your paper and have a look at it during the weekend. > Have you had a chance to take a look? (I'm traveling for the next ~10 days and at a conference, so don't expect too much from me during that time.) > > > > > I have done some testing against my Java implementation of the Ryu > > algorithm described in the linked paper. Interestingly, I've found a few > > cases where they output different results. In particular: > > 1.0E-323 is printed as 9.9E-324 > > 1.0E-322 is printed as 9.9E-323 > > If Ryu also produces 1 digit long outputs, then your results above are > correct. But then Ryu should also output 5.0E-324 rather than 4.9E-324, > for example. > Even better, it should output 5E-324, 1E-323 and 1E-322 because adding > the .0 part might confuse a human reader to believe that 2 digits are > really needed. But then 4.9E-324, 9.9E-324 and 9.9E-323 are closer to > the double. > The C version produces 1 digit long outputs, and I was trying to follow the Java spec in the Java version, but the code to do so isn't quite right. Unfortunately, I haven't yet been able to fix it. > > 2 digits are for backward compatibility with the existing spec which > requires at least one digit to the right of the decimal point. > > > > > > It's likely that there are more such cases - I only ran a sample of > > double-precision numbers. Arguably, 9.9 is the correctly rounded 2-digit > > output and Ryu is incorrect here. That's what you get when you have a > > special case for Java without a correctness proof. :-( > > > > In terms of performance, this algorithm performs almost exactly the same > > as my Java implementation of Ryu, although I'd like to point out that my > > C implementation of Ryu is quite a bit faster (though note that it > > generates different output, in particular, it only outputs a single > > digit of precision in the above cases, rather than two), and I didn't > > backport all the performance improvements from the Java version, yet. It > > looks like this is not coincidence - as far as I can see so far, it's > > algorithmically very similar, although it manages to avoid the loop I'm > > using in Ryu to find the shortest representation. > > > > I have a few comments: > > > > *

  • It rounds to {@code v} according to the usual > > round-to-closest > > * rule of IEEE 754 floating-point arithmetic. > > - Since you're spelling out the rounding rules just below, this is > > duplicated, and by itself, it's unclear since it doesn't specify the > > specific sub-type (round half even). > > > > I tried to save as much of the original spec wording as possible. > Perhaps it isn't worthwhile. > > > > > - Naming: I'd strongly suggest to use variable names that relate to > > what's stored, e.g., m for mantissa, e for exponent, etc. > > > > I currently prefer to be consistent with a forthcoming paper of mine on > the subject. But thanks for the suggestion. > May I suggest that the paper also uses names that relate to what they're referring to? :-) Not that I've managed to do that very well myself... > > > > - What's not clear to me is how the algorithm determines how many digits > > to print. > > > > You'll have to wait for the paper. > Looking forward to it. I tried to reverse engineer the code, but it's far from obvious. > > > > - Also, it might be nicer to move the long multiplications to a helper > > method - at least from a short look, it looks like the computations of > > vn, vnl, and vnr are identical. > > > > I tried several variants: the current one seems to be the faster with > the current optimizations of C2. Some day I'll also try with Graal. > Sure, but moving it to a method shouldn't affect performance (except if you need to return multiple values), and, right now, it looks like identical code. > > > > > - I looked through the spec, and it looks like all cases are > > well-defined. Yay! > > > > I will need some more time to do a more thorough review of the code and > > more testing for differences. Unfortunately, I'm also traveling the next > > two weeks, so this might take a bit of time. > > > > I thank you in advance for your willingness to review the code but my > understanding is that only the officially appointed reviewers can > approve OpenJDK contributions, which is of course a good policy. > Besides, as two Andrews engineers from RedHat correctly observe, > understanding the rationale of the code without the planned accompanying > paper is hard. > > > > > I'm not a contributor to the Jdk, and this isn't my full-time job. I was > > lurking here because I was going to send a patch for the double to > > string conversion code myself (based on Ryu). > > > > All my efforts on this projects are done in my unpaid spare time, too. > > > > Thanks, > > > > -- Ulf > > > > [1] https://dl.acm.org/citation.cfm?id=3192369 > > [2] https://github.com/google/double-conversion > > [3] https://en.wikipedia.org/wiki/Rounding > > > > > Thank you > Raffaello > > > > > > > From david.lloyd at redhat.com Thu Oct 4 14:17:49 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 4 Oct 2018 09:17:49 -0500 Subject: Fwd: Re: RFR (12): 8191053: Provide a mechanism to make system's security manager immutable In-Reply-To: <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> References: <1b22437e-69ff-54a3-81b9-ccd6a0782629@oracle.com> <189f3e88-44e8-f297-1b73-02dd73a79fad@oracle.com> Message-ID: On Wed, Oct 3, 2018 at 7:53 PM Sergey Bylokhov wrote: > Hi, Sean. > One question related to SecurityManager and performance, is it possible > to provide a special version of AccessController.doPrivileged which will > be noop if SecurityManager is not present? TBH that method (at least, the no-arg variant) should *always* have been a no-op. All it really accomplishes, in practice, is to place a mark on the stack where the stack crawl to build the access control context should stop (plus one frame), and this effect is something that is already a natural consequence of a method being called in the JVM. The doPrivileged variant that accepts an ACC parameter should likewise always have been no-op other than stashing the nested ACC into some sort of thread-local (or better, a field on Thread) which can be referred to by the aforementioned stack crawl. The pure-java AccessController I prototyped late last year relies on these ideas, among other things. -- - DML From Roger.Riggs at oracle.com Thu Oct 4 15:09:11 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 4 Oct 2018 11:09:11 -0400 Subject: RFR 8207690: SearchPath API for classpath and similar path strings Message-ID: <60355b5b-ea45-754d-239b-5798cd659c95@oracle.com> Please review a revised API for parsing search and using paths. Thanks for the earlier comments and suggestions. java.util.SearchPath is an immutable sequence of strings, typically filesystem paths. A search path is created from a list of strings or by? splitting a string using File.pathSeparator. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-searchpath-8207690/ Javadoc: http://cr.openjdk.java.net/~rriggs/searchpath-8208208/java.base/java/util/SearchPath.html Issue: https://bugs.openjdk.java.net/browse/JDK-8207690 CSR: https://bugs.openjdk.java.net/browse/JDK-8208208 Thanks, Roger From raffaello.giulietti at gmail.com Thu Oct 4 15:57:20 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Thu, 4 Oct 2018 17:57:20 +0200 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: <5b96cda8-45d2-5c7a-929e-2adfb1a3ef45@gmail.com> Hi, On 2018-10-02 20:17, Martin Buchholz wrote: > Raffaello and Ulf should talk. I work on this project in my spare time, which is limited and not entirely devoted to programming for the OpenJDK, of course ;-) Starting this weekend, I'll try to recollect my notes and organize them in paper or tutorial form. I cannot speak for Ulf, of course, but my understanding is that his porting to Java is a spare-time project, too. > It seems like Ulf's ryu project is trying to solve the same problem. > ryu is also still being worked on, but there is already a published > paper and ryu is being adopted by various core libraries. > https://github.com/ulfjack/ryu > https://dl.acm.org/citation.cfm?id=3192369 > Ulf, if you haven't already signed an Oracle Contributor Agreement for > openjdk, you should do so. > (Who knew printing floating point numbers could be so hard?) > Well, printing floating point numbers is simple if there are no performance concerns. Abstractly, it is only a matter of calculations with rational numbers. It becomes harder when efficiency becomes part of the goal. The quest started about 30 years ago with a seminal paper of Steele & White and seemed settled with an implementation by Gay around 1991. Since then, other interesting approaches have seen light with the goal of even better performance. Greetings Raffaello From raffaello.giulietti at gmail.com Thu Oct 4 16:00:21 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Thu, 4 Oct 2018 18:00:21 +0200 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: <797af194-b4f8-3ee8-9068-c561ebf067da@gmail.com> On 2018-10-03 11:12, Andrew Dinn wrote: > On 02/10/18 19:17, Martin Buchholz wrote: >> Raffaello and Ulf should talk. >> It seems like Ulf's ryu project is trying to solve the same problem. >> ryu is also still being worked on, but there is already a published paper >> and ryu is being adopted by various core libraries. >> https://github.com/ulfjack/ryu >> https://dl.acm.org/citation.cfm?id=3192369 >> Ulf, if you haven't already signed an Oracle Contributor Agreement for >> openjdk, you should do so. >> (Who knew printing floating point numbers could be so hard?) > > Well, Guy Steele and Jon L White, for starters (quite literally) [1] > In my eyes, the clarity of that paper is almost mythical. I wish I could follow their teaching myself. > [1] https://dl.acm.org/citation.cfm?id=93559 > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From rhillegas at comcast.net Thu Oct 4 16:10:13 2018 From: rhillegas at comcast.net (Richard Hillegas) Date: Thu, 4 Oct 2018 09:10:13 -0700 Subject: generated code and jigsaw modules Message-ID: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> I am looking for advice about how to tighten up module encapsulation while generating byte code on the fly. I ask this question on behalf of Apache Derby, a pure-Java relational database whose original code dates back to Java 1.2. I want to reduce Derby's attack-surface when running with a module path. First a little context: A relational database is an interpreter for the SQL language. It converts SQL queries into byte code which then runs on a virtual machine embedded in the interpreter. In Derby's case, the virtual machine is the Java VM and the byte code is simply Java byte code. That is, a Derby query plan is a class whose byte code is generated on the fly at run time. I have converted the Apache Derby codeline into a set of jigsaw modules: https://issues.apache.org/jira/browse/DERBY-6945. Unfortunately, I had to punch holes in the encapsulation of the main Derby module so that the generated query plans could call back into the Derby engine. That is because, by default, generated query plans load into the catch-all, unnamed module. Note that all of these generated classes live in a single package which does not belong to any named module. 1) Is it possible to load generated code into a named module? 2) Alternatively, can someone recommend another approach for preserving module encapsulation while generating classes on the fly? I would appreciate any advice or examples which you can recommend. Thanks, -Rick From raffaello.giulietti at gmail.com Thu Oct 4 16:14:55 2018 From: raffaello.giulietti at gmail.com (raffaello.giulietti at gmail.com) Date: Thu, 4 Oct 2018 18:14:55 +0200 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: References: Message-ID: On 2018-10-04 15:28, Ulf Adams wrote: > On Thu, Sep 27, 2018 at 5:37 PM Raffaello Giulietti > > > wrote: > > Hi Ulf, > > > On 2018-09-27 16:40, Ulf Adams wrote: > > Hi Raffaello, > > > > I am the author of a recent publication on double to string > conversion > > [1] - the Ryu algorithm. I've been aware of the problems with the Jdk > > for several years, and am very much looking forward to > improvements in > > correctness and performance in this area. > > > > What a coincidence! I'm happy to hear that the quest for better > floating->string conversions has not stopped. Tomorrow I'll download > your paper and have a look at it during the weekend. > > > Have you had a chance to take a look? > > (I'm traveling for the next ~10 days and at a conference, so don't > expect too much from me during that time.) > ? > I had a cursory reading but couldn't dig deeper for now. If nothing unexpected happens, I should be able to study your paper during the weekend. > > > > > I have done some testing against my Java implementation of the Ryu > > algorithm described in the linked paper. Interestingly, I've found > a few > > cases where they output different results. In particular: > > 1.0E-323 is printed as 9.9E-324 > > 1.0E-322 is printed as 9.9E-323 > > If Ryu also produces 1 digit long outputs, then your results above are > correct. But then Ryu should also output 5.0E-324 rather than 4.9E-324, > for example. > Even better, it should output 5E-324, 1E-323 and 1E-322 because adding > the .0 part might confuse a human reader to believe that 2 digits are > really needed. But then 4.9E-324, 9.9E-324 and 9.9E-323 are closer to > the double. > > > The C version produces 1 digit long outputs, and I was trying to follow > the Java spec in the Java version, but the code to do so isn't quite > right. Unfortunately, I haven't yet been able to fix it. > ? > > > 2 digits are for backward compatibility with the existing spec which > requires at least one digit to the right of the decimal point. > > > > > > It's likely that there are more such cases - I only ran a sample of > > double-precision numbers. Arguably, 9.9 is the correctly rounded > 2-digit > > output and Ryu is incorrect here. That's what you get when you have a > > special case for Java without a correctness proof. :-( > > > > In terms of performance, this algorithm performs almost exactly > the same > > as my Java implementation of Ryu, although I'd like to point out > that my > > C implementation of Ryu is quite a bit faster (though note that it > > generates different output, in particular, it only outputs a single > > digit of precision in the above cases, rather than two), and I didn't > > backport all the performance improvements from the Java version, > yet. It > > looks like this is not coincidence - as far as I can see so far, it's > > algorithmically very similar, although it manages to avoid the > loop I'm > > using in Ryu to find the shortest representation. > > > > I have a few comments: > > > >? ? ? ?*? ? ?
  • It rounds to {@code v} according to the usual > > round-to-closest > >? ? ? ?*? ? ?rule of IEEE 754 floating-point arithmetic. > > - Since you're spelling out the rounding rules just below, this is > > duplicated, and by itself, it's unclear since it doesn't specify the > > specific sub-type (round half even). > > > > I tried to save as much of the original spec wording as possible. > Perhaps it isn't worthwhile. > > > > > - Naming: I'd strongly suggest to use variable names that relate to > > what's stored, e.g., m for mantissa, e for exponent, etc. > > > > I currently prefer to be consistent with a forthcoming paper of mine on > the subject. But thanks for the suggestion. > > > May I suggest that the paper also uses names that relate to what they're > referring to? :-) Not that I've managed to do that very well myself... > I tend to use short "mathematical" names that still evoke their semantics. Will see if I manage to be consistent. > > > > > - What's not clear to me is how the algorithm determines how many > digits > > to print. > > > > You'll have to wait for the paper. > > > Looking forward to it. I tried to reverse engineer the code, but it's > far from obvious. > ? I don't think it is reversible, even for knowledgeable people like you :-( I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... I have to write the paper... > > > > > - Also, it might be nicer to move the long multiplications to a > helper > > method - at least from a short look, it looks like the > computations of > > vn, vnl, and vnr are identical. > > > > I tried several variants: the current one seems to be the faster with > the current optimizations of C2. Some day I'll also try with Graal. > > > Sure, but moving it to a method shouldn't affect performance (except if > you need to return multiple values), and, right now, it looks like > identical code. > ? > Where possible, I try not to rely on C2 to perform inlining of "long" code like the 8 lines for the multiplication. In the end, it is repeated only 3 times there and in a limited space. It shouldn't come to a surprise to a reader. I'll certainly add a comment to warn the reader that the code is the same and I'll retry my experiments with extracting a method for the multiplication although it currently seems more complex than at first sight. Unfortunately, Java does not yet support 128 bits quantities. Greetings Raffaello > > > > > - I looked through the spec, and it looks like all cases are > > well-defined. Yay! > > > > I will need some more time to do a more thorough review of the > code and > > more testing for differences. Unfortunately, I'm also traveling > the next > > two weeks, so this might take a bit of time. > > > > I thank you in advance for your willingness to review the code but my > understanding is that only the officially appointed reviewers can > approve OpenJDK contributions, which is of course a good policy. > Besides, as two Andrews engineers from RedHat correctly observe, > understanding the rationale of the code without the planned > accompanying > paper is hard. > > > > > I'm not a contributor to the Jdk, and this isn't my full-time job. > I was > > lurking here because I was going to send a patch for the double to > > string conversion code myself (based on Ryu). > > > > All my efforts on this projects are done in my unpaid spare time, too. > > > > Thanks, > > > > -- Ulf > > > ?> [1] https://dl.acm.org/citation.cfm?id=3192369 > ?> [2] https://github.com/google/double-conversion > ?> [3] https://en.wikipedia.org/wiki/Rounding > ?> > > > Thank you > Raffaello > > > > > > From forax at univ-mlv.fr Thu Oct 4 16:26:59 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 4 Oct 2018 18:26:59 +0200 (CEST) Subject: generated code and jigsaw modules In-Reply-To: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> Message-ID: <201267511.428468.1538670419592.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Richard Hillegas" > ?: "core-libs-dev" > Envoy?: Jeudi 4 Octobre 2018 18:10:13 > Objet: generated code and jigsaw modules > I am looking for advice about how to tighten up module encapsulation > while generating byte code on the fly. I ask this question on behalf of > Apache Derby, a pure-Java relational database whose original code dates > back to Java 1.2. I want to reduce Derby's attack-surface when running > with a module path. > > First a little context: A relational database is an interpreter for the > SQL language. It converts SQL queries into byte code which then runs on > a virtual machine embedded in the interpreter. In Derby's case, the > virtual machine is the Java VM and the byte code is simply Java byte > code. That is, a Derby query plan is a class whose byte code is > generated on the fly at run time. > > I have converted the Apache Derby codeline into a set of jigsaw modules: > https://issues.apache.org/jira/browse/DERBY-6945. Unfortunately, I had > to punch holes in the encapsulation of the main Derby module so that the > generated query plans could call back into the Derby engine. That is > because, by default, generated query plans load into the catch-all, > unnamed module. Note that all of these generated classes live in a > single package which does not belong to any named module. > > 1) Is it possible to load generated code into a named module? > > 2) Alternatively, can someone recommend another approach for preserving > module encapsulation while generating classes on the fly? > > I would appreciate any advice or examples which you can recommend. you can use Lookup.defineClass. > > Thanks, > -Rick cheers, R?mi From Alan.Bateman at oracle.com Thu Oct 4 16:45:21 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Oct 2018 17:45:21 +0100 Subject: generated code and jigsaw modules In-Reply-To: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> Message-ID: <055e5e66-06af-4098-db89-048c6c022c9b@oracle.com> On 04/10/2018 17:10, Richard Hillegas wrote: > I am looking for advice about how to tighten up module encapsulation > while generating byte code on the fly. I ask this question on behalf > of Apache Derby, a pure-Java relational database whose original code > dates back to Java 1.2. I want to reduce Derby's attack-surface when > running with a module path. > > First a little context: A relational database is an interpreter for > the SQL language. It converts SQL queries into byte code which then > runs on a virtual machine embedded in the interpreter. In Derby's > case, the virtual machine is the Java VM and the byte code is simply > Java byte code. That is, a Derby query plan is a class whose byte code > is generated on the fly at run time. > > I have converted the Apache Derby codeline into a set of jigsaw > modules: https://issues.apache.org/jira/browse/DERBY-6945. > Unfortunately, I had to punch holes in the encapsulation of the main > Derby module so that the generated query plans could call back into > the Derby engine. That is because, by default, generated query plans > load into the catch-all, unnamed module. Note that all of these > generated classes live in a single package which does not belong to > any named module. > > 1) Is it possible to load generated code into a named module? > > 2) Alternatively, can someone recommend another approach for > preserving module encapsulation while generating classes on the fly? > > I would appreciate any advice or examples which you can recommend. There are a couple of places in the JDK where we spin bytecode into modules that are created at run-time. One example is in the Nashorn and was presented by MIchael Haupt at JVMLS 2017 [1]. There's a lot in that so a simpler example to look at is in the XML transformation code [2] where there is a module created at run-time for each translet. The module is fully encapsulate except for an entry point that it exports to the java.xml module in the parent module layer. In turn, the java.xml exports one of its internal packages to the translet module to allow what may be equivalent to your generated code calling back into the Derby engine. -Alan [1] https://www.youtube.com/watch?v=Zk6a6jNZAt0 [2] http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java From Alan.Bateman at oracle.com Thu Oct 4 17:45:01 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 Oct 2018 18:45:01 +0100 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak In-Reply-To: References: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> <3f3273b9-0c4b-0a09-7295-d7084311f697@gmail.com> Message-ID: <81769e45-d334-d282-0312-cfa323346ea2@oracle.com> On 03/10/2018 18:28, Mandy Chung wrote: > : > > On 10/3/18 9:30 AM, Peter Levart wrote: >> Hi Mandy, >> >> I don't know if this matters though, but should >> Reflection.getCallerClass() ever return null, previous behavior was >> to throw NPE (from Reflection.verifyMemberAccess(...)), now the >> checks are skipped. This should only be observable if [Class, >> Constructor].newInstance() was called from JNI's newly attached >> thread I believe. > > Yes that's the case.?? Such case never works as it will get NPE. I > didn't worry too much about it.? Since you mentioned it, I should keep > the existing behavior (throwing NPE): > > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.01 The JNI call with no java frames is a corner case but good not to change existing behavior. The updated webrev looks okay to me. -Alan From philipp.kunz at paratix.ch Thu Oct 4 19:58:51 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Thu, 04 Oct 2018 21:58:51 +0200 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: <5BB51D1A.2000600@oracle.com> References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> <5BB51D1A.2000600@oracle.com> Message-ID: <1538683131.2782.10.camel@paratix.ch> Thanks to Sherman's hint, I revised the test to use the terms unicode character and utf encoding?consistently and not utf character. Affects only the test, mostly in comments and a few identifiers. Philipp On Wed, 2018-10-03 at 12:48 -0700, Xueming Shen wrote: > +1 > > only nit is it might be preferred to use "utf8" directly in the test > instead of current "utf" > > -sherman > > On 10/03/2018 11:55 AM, Philipp Kunz wrote: > > In short, bug 6202130 is about removal of comments in Attributes > > like > > > > > XXX Need to handle UTF8 values and break up lines longer than 72 > > > > The patch here contains a test that shows that utf characters are > > handled correctly, which has been the case before. Breaking lines > > has > > also been working before. > > > > In the main code, the patch only removes a few comments and does > > not > > change actual code. It all has been working before and now we know. > > > > Philipp > > > > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > > > > > > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > > > Hi, > > > > > > There are some comments in the source code like this: > > > > > > ? >??XXX Need to handle UTF8 values and break up lines longer > > > than 72 bytes > > > > > > in Attributes.java on lines 299, 327, and 370. Bug 6202130 also > > > suggests > > > to add a test to show that the character set is fully supported > > > before > > > actually removing those comments. > > > > > > Hence, I added such a test, see ValueUtfEncoding in attached > > > patch, and > > > it finds the complete utf character set supported correctly and > > > that it > > > has been so already before. > > > > > > The comments in Attributes also say that lines longer than 72 > > > bytes need > > > to be broken. That is a different issue and has been already > > > addressed > > > and solved in bug 6372077 and is now tested in LineBreakLineWidth > > > and > > > therefore, that line break part of the comment is obsolete now as > > > well > > > with the exception of version headers ("Manifest-Version" or > > > "Signature-Version") at least when taking strictly. > > > > > > Version headers are not subject of bug 6202130 for which my patch > > > intends to provide a fix and if only because multi-byte > > > characters are > > > not allowed in version headers and wasn't subject of 6372077 > > > either > > > which was about too short lines rather than too long ones. If I > > > would > > > change only the minimum I could argue was safe, there would have > > > to > > > remain a comment in Attributes.java on line 327 like > > > > > > ? >??XXX Need to handle version headers longer than 72 bytes > > > > > > but I guess that should probably better be represented as another > > > bug > > > rather than this style of comment if at all desired. There are > > > some bugs > > > concerning version headers and particularly the behavior of the > > > manifests in their absence, among possibly others, 6910466, > > > 4935610, > > > 4271239, 8196371 and 4256580 which have some relation but I > > > haven't > > > found one that really fits the 72 byte line length limit of > > > version > > > headers. Whether such a bug is created or found or not, it does > > > not > > > directly relate to the one I'm trying to fix here, 6202130. > > > > > > If also the test is good I would assume that the comments can be > > > removed now without actually changing the Manifest and Attributes > > > implementation. > > > > > > Regards, > > > Philipp > -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130.patch Type: text/x-patch Size: 9318 bytes Desc: not available URL: From peter.levart at gmail.com Thu Oct 4 20:06:05 2018 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 4 Oct 2018 22:06:05 +0200 Subject: Review Request: JDK-8206240: java.lang.Class.newInstance() is causing caller to leak In-Reply-To: <81769e45-d334-d282-0312-cfa323346ea2@oracle.com> References: <8c58252b-dbac-8508-8644-21d7ee233263@oracle.com> <6e1c04e3-f550-ee2e-bd0a-157b3132ad00@oracle.com> <3f3273b9-0c4b-0a09-7295-d7084311f697@gmail.com> <81769e45-d334-d282-0312-cfa323346ea2@oracle.com> Message-ID: <0f8cbfbb-cb6b-9cdd-82c0-6c7515564a63@gmail.com> Hi Mandy, On 10/04/2018 07:45 PM, Alan Bateman wrote: > > > On 03/10/2018 18:28, Mandy Chung wrote: >> : >> >> On 10/3/18 9:30 AM, Peter Levart wrote: >>> Hi Mandy, >>> >>> I don't know if this matters though, but should >>> Reflection.getCallerClass() ever return null, previous behavior was >>> to throw NPE (from Reflection.verifyMemberAccess(...)), now the >>> checks are skipped. This should only be observable if [Class, >>> Constructor].newInstance() was called from JNI's newly attached >>> thread I believe. >> >> Yes that's the case.?? Such case never works as it will get NPE.? I >> didn't worry too much about it.? Since you mentioned it, I should >> keep the existing behavior (throwing NPE): >> >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8206240/webrev.01 > The JNI call with no java frames is a corner case but good not to > change existing behavior. The updated webrev looks okay to me. > > -Alan Likewise. Regards, Peter From naoto.sato at oracle.com Thu Oct 4 20:30:46 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 4 Oct 2018 13:30:46 -0700 Subject: [12] RFR: 8211398: Square character support for the Japanese new era Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8211398 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8211398/webrev.00/ This change is to allow the code point (U+32FF) which will designate the square character for the Japanese new era. Naoto From Roger.Riggs at oracle.com Thu Oct 4 20:42:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 4 Oct 2018 16:42:27 -0400 Subject: [12] RFR: 8211398: Square character support for the Japanese new era In-Reply-To: References: Message-ID: Hi Naoto, Looks ok to me. Regards, Roger On 10/04/2018 04:30 PM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8211398 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8211398/webrev.00/ > > This change is to allow the code point (U+32FF) which will designate > the square character for the Japanese new era. > > Naoto -- Thanks, Roger From kim.barrett at oracle.com Thu Oct 4 21:01:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:01:03 -0400 Subject: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <71fb517fba794dc28291cf51afb6e8b9@sap.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <71fb517fba794dc28291cf51afb6e8b9@sap.com> Message-ID: <2DB05A59-EA8F-46FD-9ECF-CA47DA5E313E@oracle.com> > On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz wrote: > > Hi, > > I appreciate this is handled in a JEP and well communicated! > > XLc, the compiler we use for AIX, might be a bottleneck here. > > But we currently have no compiler-constraints by products on > our aix port of jdk12 (for jdk11 we must stay with the current > compiler xlc 12 which does not support C++11, and jdk11 even > should be compilable with aCC by HP for which we won't > get new versions!) > > We will update our compiler for jdk/jdk to the most recent Xlc > as soon as possible. > To my current knowledge, Xlc 14 was dropped, and xlc 16 > is to be released early 2019. It is supposed to support > C++ 11, and also some C++ 14 features. The information I've been able to find mostly discusses Linux support for XLC 16. Any information about "some C++14 features"? I haven't found any detail on that. I am working toward being able to target this for JDK 12, but realize that might not be reachable. Windows is already there, because of VS2017 support. There are a couple of minor patches needed for gcc and clang based builds; Linux-x64 and MacOSX-x64 have had a fair amount of ad hoc testing. We (Oracle) only switched over the Solaris/sparc builds to the necessary compiler version (Oracle Studio 12.6) very recently, and there are some issues still to be dealt with there. And the currently used XLC is just not up to the change. From kim.barrett at oracle.com Thu Oct 4 21:09:57 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:09:57 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> Message-ID: <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> > On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov wrote: > > Kim, > > Thank you for posting this. It's an important step to make. I wanted to clarify a couple of points: > > 1. Since this is infrastructure JEP, is the version of JDK which will undergo such changes going to be some future version or does it apply to past versions as well? I'm concerned with how we can simplify security backports to 8u which (I currently assume) is not subject to this change. Future version (perhaps as soon as JDK 12). I don't think there is any desire to backport this change. And yes, introducing the use of new language features will make backports even more interesting than they already are. That seems unavoidable if we're going to pursue this direction. > 2. Which versions of GCC do you tentatively consider at this point? Non-x86 ports may have a problem upgrading to a specific version of GCC which the shared code will use and may need additional lead time to adjust. I think our (ad hoc) testing has been limited to gcc 7.x. But looking at the gcc language conformance tables and release notes, gcc 5.x might be good enough, and gcc 6.x seems fairly likely sufficient. Of course, older versions are more likely to have bugs in some of these new features. Updating the minimum supported versions for gcc and clang are noted as TBD in the JEP. From kim.barrett at oracle.com Thu Oct 4 21:53:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Oct 2018 17:53:27 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <3C557F9A-82B7-4941-850B-EA2D0ED44EDA@oracle.com> > On Oct 4, 2018, at 4:35 AM, Volker Simonis wrote: > > Hi Tim, Jeff, > > Kim has assembled a quite detailed list of new C++ features intended for use in HotSpot/OpenJDK (with links to the corresponding C++ standard) > > https://bugs.openjdk.java.net/browse/JDK-8208089 Note that this list is intended as a starting point. The JEP also describes a process for adding to the list of permitted features, and I anticipate that process will be used. There are several that I personally think would be good to add (perhaps with some limits or restrictions), but that I think may involve more detailed discussion. And other folks may have their favorite must have feature(s) that didn?t seem to me to be needed in this initial seed list. From rhillegas at comcast.net Thu Oct 4 21:55:27 2018 From: rhillegas at comcast.net (Richard Hillegas) Date: Thu, 4 Oct 2018 14:55:27 -0700 Subject: generated code and jigsaw modules In-Reply-To: <201267511.428468.1538670419592.JavaMail.zimbra@u-pem.fr> References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> <201267511.428468.1538670419592.JavaMail.zimbra@u-pem.fr> Message-ID: <98ada664-7796-cc41-80ea-1be6cf9d9048@comcast.net> On 10/4/18 9:26 AM, Remi Forax wrote: > ----- Mail original ----- >> De: "Richard Hillegas" >> ?: "core-libs-dev" >> Envoy?: Jeudi 4 Octobre 2018 18:10:13 >> Objet: generated code and jigsaw modules >> I am looking for advice about how to tighten up module encapsulation >> while generating byte code on the fly. I ask this question on behalf of >> Apache Derby, a pure-Java relational database whose original code dates >> back to Java 1.2. I want to reduce Derby's attack-surface when running >> with a module path. >> >> First a little context: A relational database is an interpreter for the >> SQL language. It converts SQL queries into byte code which then runs on >> a virtual machine embedded in the interpreter. In Derby's case, the >> virtual machine is the Java VM and the byte code is simply Java byte >> code. That is, a Derby query plan is a class whose byte code is >> generated on the fly at run time. >> >> I have converted the Apache Derby codeline into a set of jigsaw modules: >> https://issues.apache.org/jira/browse/DERBY-6945. Unfortunately, I had >> to punch holes in the encapsulation of the main Derby module so that the >> generated query plans could call back into the Derby engine. That is >> because, by default, generated query plans load into the catch-all, >> unnamed module. Note that all of these generated classes live in a >> single package which does not belong to any named module. >> >> 1) Is it possible to load generated code into a named module? >> >> 2) Alternatively, can someone recommend another approach for preserving >> module encapsulation while generating classes on the fly? >> >> I would appreciate any advice or examples which you can recommend. > you can use Lookup.defineClass. Thanks, R?mi. That gives me something to google up. Cheers! > >> Thanks, >> -Rick > cheers, > R?mi > From rhillegas at comcast.net Thu Oct 4 21:57:11 2018 From: rhillegas at comcast.net (Richard Hillegas) Date: Thu, 4 Oct 2018 14:57:11 -0700 Subject: generated code and jigsaw modules In-Reply-To: <055e5e66-06af-4098-db89-048c6c022c9b@oracle.com> References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> <055e5e66-06af-4098-db89-048c6c022c9b@oracle.com> Message-ID: On 10/4/18 9:45 AM, Alan Bateman wrote: > On 04/10/2018 17:10, Richard Hillegas wrote: >> I am looking for advice about how to tighten up module encapsulation >> while generating byte code on the fly. I ask this question on behalf >> of Apache Derby, a pure-Java relational database whose original code >> dates back to Java 1.2. I want to reduce Derby's attack-surface when >> running with a module path. >> >> First a little context: A relational database is an interpreter for >> the SQL language. It converts SQL queries into byte code which then >> runs on a virtual machine embedded in the interpreter. In Derby's >> case, the virtual machine is the Java VM and the byte code is simply >> Java byte code. That is, a Derby query plan is a class whose byte >> code is generated on the fly at run time. >> >> I have converted the Apache Derby codeline into a set of jigsaw >> modules: https://issues.apache.org/jira/browse/DERBY-6945. >> Unfortunately, I had to punch holes in the encapsulation of the main >> Derby module so that the generated query plans could call back into >> the Derby engine. That is because, by default, generated query plans >> load into the catch-all, unnamed module. Note that all of these >> generated classes live in a single package which does not belong to >> any named module. >> >> 1) Is it possible to load generated code into a named module? >> >> 2) Alternatively, can someone recommend another approach for >> preserving module encapsulation while generating classes on the fly? >> >> I would appreciate any advice or examples which you can recommend. > > There are a couple of places in the JDK where we spin bytecode into > modules that are created at run-time. One example is in the Nashorn > and was presented by MIchael Haupt at JVMLS 2017 [1]. There's a lot in > that so a simpler example to look at is in the XML transformation code > [2] where there is a module created at run-time for each translet. The > module is fully encapsulate except for an entry point that it exports > to the java.xml module in the parent module layer. In turn, the > java.xml exports one of its internal packages to the translet module > to allow what may be equivalent to your generated code calling back > into the Derby engine. > > -Alan Thanks, Alan. I will study this example. Cheers! > > [1] https://www.youtube.com/watch?v=Zk6a6jNZAt0 > [2] > http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java > From martinrb at google.com Thu Oct 4 22:24:30 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 4 Oct 2018 15:24:30 -0700 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: <1538683131.2782.10.camel@paratix.ch> References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> <5BB51D1A.2000600@oracle.com> <1538683131.2782.10.camel@paratix.ch> Message-ID: "utf8" is a thing. "utf" is not. On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz wrote: > Thanks to Sherman's hint, I revised the test to use the terms unicode > character and utf encoding consistently and not utf character. Affects > only the test, mostly in comments and a few identifiers. > > Philipp > > > On Wed, 2018-10-03 at 12:48 -0700, Xueming Shen wrote: >> +1 >> >> only nit is it might be preferred to use "utf8" directly in the test >> instead of current "utf" >> >> -sherman >> >> On 10/03/2018 11:55 AM, Philipp Kunz wrote: >> > In short, bug 6202130 is about removal of comments in Attributes >> > like >> > >> > > XXX Need to handle UTF8 values and break up lines longer than 72 >> > >> > The patch here contains a test that shows that utf characters are >> > handled correctly, which has been the case before. Breaking lines >> > has >> > also been working before. >> > >> > In the main code, the patch only removes a few comments and does >> > not >> > change actual code. It all has been working before and now we know. >> > >> > Philipp >> > >> > >> > https://bugs.openjdk.java.net/browse/JDK-6202130 >> > >> > >> > >> > >> > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: >> > > Hi, >> > > >> > > There are some comments in the source code like this: >> > > >> > > > XXX Need to handle UTF8 values and break up lines longer >> > > than 72 bytes >> > > >> > > in Attributes.java on lines 299, 327, and 370. Bug 6202130 also >> > > suggests >> > > to add a test to show that the character set is fully supported >> > > before >> > > actually removing those comments. >> > > >> > > Hence, I added such a test, see ValueUtfEncoding in attached >> > > patch, and >> > > it finds the complete utf character set supported correctly and >> > > that it >> > > has been so already before. >> > > >> > > The comments in Attributes also say that lines longer than 72 >> > > bytes need >> > > to be broken. That is a different issue and has been already >> > > addressed >> > > and solved in bug 6372077 and is now tested in LineBreakLineWidth >> > > and >> > > therefore, that line break part of the comment is obsolete now as >> > > well >> > > with the exception of version headers ("Manifest-Version" or >> > > "Signature-Version") at least when taking strictly. >> > > >> > > Version headers are not subject of bug 6202130 for which my patch >> > > intends to provide a fix and if only because multi-byte >> > > characters are >> > > not allowed in version headers and wasn't subject of 6372077 >> > > either >> > > which was about too short lines rather than too long ones. If I >> > > would >> > > change only the minimum I could argue was safe, there would have >> > > to >> > > remain a comment in Attributes.java on line 327 like >> > > >> > > > XXX Need to handle version headers longer than 72 bytes >> > > >> > > but I guess that should probably better be represented as another >> > > bug >> > > rather than this style of comment if at all desired. There are >> > > some bugs >> > > concerning version headers and particularly the behavior of the >> > > manifests in their absence, among possibly others, 6910466, >> > > 4935610, >> > > 4271239, 8196371 and 4256580 which have some relation but I >> > > haven't >> > > found one that really fits the 72 byte line length limit of >> > > version >> > > headers. Whether such a bug is created or found or not, it does >> > > not >> > > directly relate to the one I'm trying to fix here, 6202130. >> > > >> > > If also the test is good I would assume that the comments can be >> > > removed now without actually changing the Manifest and Attributes >> > > implementation. >> > > >> > > Regards, >> > > Philipp >> From aleksei.voitylov at bell-sw.com Thu Oct 4 13:17:21 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 4 Oct 2018 16:17:21 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> Kim, Thank you for posting this. It's an important step to make. I wanted to clarify a couple of points: 1. Since this is infrastructure JEP, is the version of JDK which will undergo such changes going to be some future version or does it apply to past versions as well? I'm concerned with how we can simplify security backports to 8u which (I currently assume) is not subject to this change. 2. Which versions of GCC do you tentatively consider at this point? Non-x86 ports may have a problem upgrading to a specific version of GCC which the shared code will use and may need additional lead time to adjust. Thanks, -Aleksei On 03/10/2018 22:13, Kim Barrett wrote: > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > From jai.forums2013 at gmail.com Fri Oct 5 06:29:22 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 5 Oct 2018 11:59:22 +0530 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> Message-ID: <93700d13-3e86-1b00-fb72-7942c426c1f5@gmail.com> Just for reference - this came up while debugging an issue, that one of our users of Apache Ant project raised here https://bz.apache.org/bugzilla/show_bug.cgi?id=62764#c8 -Jaikiran On 04/10/18 3:06 PM, Jaikiran Pai wrote: > Please consider the following trivial code: > > import java.util.jar.*; > import java.io.*; > > public class JarFileTest { > ??? public static void main(final String[] args) throws Exception { > ??? ??? final String tmpDir = System.getProperty("java.io.tmpdir"); > ??? ??? try { > ??? ??? ??? final JarFile jarFile = new JarFile(tmpDir + File.separator > + "*"); > ??? ??? } catch (IOException ioe) { > ??? ??? ??? System.out.println("Got the expected IOException " + ioe); > ??? ??? } > ??? } > } > > The constructor of the JarFile is passed a string which intentionally is > an (wildcard) invalid path. The above code (as expected) throws an > IOException on *nix systems across various version of Java (tested > against Java 8, 11). The same code throws an IOException (as expected) > in Java 8 on Windows OS too. However, in Java 11, on Windows OS, this > code throws a different exception (java.nio.file.InvalidPathException) > which isn't IOException or a subclass of it: > > Exception in thread "main" java.nio.file.InvalidPathException: Illegal > char <*> at index 38: C:\Users\someone\AppData\Local\Temp\1\* > at > java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at > java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229) > at java.base/java.io.File.toPath(File.java:2290) > at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1220) > at > java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727) > at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:845) > at java.base/java.util.zip.ZipFile.(ZipFile.java:245) > at java.base/java.util.zip.ZipFile.(ZipFile.java:175) > at java.base/java.util.jar.JarFile.(JarFile.java:341) > at java.base/java.util.jar.JarFile.(JarFile.java:312) > at java.base/java.util.jar.JarFile.(JarFile.java:251) > at JarFileTest.main(JarFileTest.java:8) > > > The javadoc of JarFile constructor(s) mentions that: > > ???? * @throws IOException if an I/O error has occurred > > Given that the javadoc doesn't mention anything about this other > exception, would this throwing of java.nio.file.InvalidPathException be > considered a bug in the implementation? > > If this indeed is considered a bug, it appears to be the code in > java.util.zip.ZipFile$Source.get method which calls File#toPath(), which > as per its javadoc is indeed expected to throw an > java.nio.file.InvalidPathException if a Path cannot be constructed out > of the File. Looking at the implementation of the underlying > java.nio.file.FileSystem on *nix and Windows, they differ when it comes > to whether or not the exception gets thrown (Unix one seems to always > return a result). But keeping the implementation of > java.nio.file.FileSystem aside, I guess the > java.util.zip.ZipFile$Source.get code needs to have a catch block for > the InvalidPathException to wrap that into a IOException? Something like: > > > # HG changeset patch > # User Jaikiran Pai > # Date 1538645309 -19800 > #????? Thu Oct 04 14:58:29 2018 +0530 > # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e > # Parent? 8705c6d536c5c197d0210acccf145ebc48f90227 > Wrap and throw an IOException when a InvalidPathException is thrown > > diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java > b/src/java.base/share/classes/java/util/zip/ZipFile.java > --- a/src/java.base/share/classes/java/util/zip/ZipFile.java > +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java > @@ -35,6 +35,7 @@ > ?import java.lang.ref.Cleaner.Cleanable; > ?import java.nio.charset.Charset; > ?import java.nio.charset.StandardCharsets; > +import java.nio.file.InvalidPathException; > ?import java.nio.file.attribute.BasicFileAttributes; > ?import java.nio.file.Files; > ?import java.util.ArrayDeque; > @@ -1218,8 +1219,13 @@ > ? > ? > ???????? static Source get(File file, boolean toDelete) throws IOException { > -??????????? Key key = new Key(file, > -????????????????????????????? Files.readAttributes(file.toPath(), > BasicFileAttributes.class)); > +??????????? final Key key; > +??????????? try { > +??????????????? key = new Key(file, > +??????????????????????? Files.readAttributes(file.toPath(), > BasicFileAttributes.class)); > +??????????? } catch (InvalidPathException ipe) { > +??????????????? throw new IOException(ipe); > +??????????? } > ???????????? Source src; > ???????????? synchronized (files) { > ???????????????? src = files.get(key); > > > Any thoughts? > > > -Jaikiran > From erik.helin at oracle.com Fri Oct 5 07:58:53 2018 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 5 Oct 2018 09:58:53 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <940757E3-8781-4E7A-B5B9-1F0D3E944E0F@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <940757E3-8781-4E7A-B5B9-1F0D3E944E0F@oracle.com> Message-ID: <8a771c9d-0803-d8c7-20f2-675733d416c4@oracle.com> On 10/4/18 2:31 PM, Magnus Ihse Bursie wrote:>> 4 okt. 2018 kl. 10:57 skrev Martijn Verburg : >> I like this initiative. I'm wondering if some of these rules can be easily >> codified or written into a jcheck style checker (ccheck?) so that Authors >> can adhere to the conventions and not rely on a Human review to pick out >> where that convention isn't met. > > That's an interesting thought! > > I googled around a bit, but could find no obvious candidate for doing such a check. In fact, parsing and analyzing C++ seems quite a hard problem, compared to many other languages. (Sad, but not really surprising.) > > I found two possible routes to explore: cpplint [1], the official Google tool to verify that the Google C++ Style Guide [2] is followed, and Vera++ [3], a framework for creating scripts that can analyze and/or transform C++ code. As usual there is of a third route, this one is "just a matter of programming" :) The (probably) easiest way to enforce usage of only a subset of C++ is to write custom clang-tidy checks [0]. We could most likely write a couple of ASTMatchers [1] to watch out for features we do not want. It used to be very hard to use the clang tooling with HotSpot, but thanks to Robin Westberg's compile-commands patch [2] that just went in, this is no longer an issue. Unfortunately I don't think requiring all contributors to install a custom version of clang-tidy with HotSpot checks is feasible, this is more something you would want to run in a CI setup. Thanks, Erik [0]: https://clang.llvm.org/extra/clang-tidy/#writing-a-clang-tidy-check [1]: http://clang.llvm.org/docs/LibASTMatchers.html [2]: http://hg.openjdk.java.net/jdk/jdk/rev/804792ce736f From goetz.lindenmaier at sap.com Fri Oct 5 08:13:21 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 5 Oct 2018 08:13:21 +0000 Subject: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <2DB05A59-EA8F-46FD-9ECF-CA47DA5E313E@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <71fb517fba794dc28291cf51afb6e8b9@sap.com> <2DB05A59-EA8F-46FD-9ECF-CA47DA5E313E@oracle.com> Message-ID: <22d25e558b2d426f827d3322b9a56d3a@sap.com> Hi Kim, > for XLC 16. Any information about "some C++14 features"? I haven't > found any detail on that. we will user our internal connections to IBM to find out :) Best regards, Goetz. > -----Original Message----- > From: Kim Barrett > Sent: Donnerstag, 4. Oktober 2018 23:01 > To: Lindenmaier, Goetz > Cc: hotspot-dev developers ; build-dev > ; core-libs-dev at openjdk.java.net > Subject: Re: JEP JDK-8208089: Implement C++14 Language Features > > > On Oct 4, 2018, at 2:59 AM, Lindenmaier, Goetz > wrote: > > > > Hi, > > > > I appreciate this is handled in a JEP and well communicated! > > > > XLc, the compiler we use for AIX, might be a bottleneck here. > > > > But we currently have no compiler-constraints by products on > > our aix port of jdk12 (for jdk11 we must stay with the current > > compiler xlc 12 which does not support C++11, and jdk11 even > > should be compilable with aCC by HP for which we won't > > get new versions!) > > > > We will update our compiler for jdk/jdk to the most recent Xlc > > as soon as possible. > > To my current knowledge, Xlc 14 was dropped, and xlc 16 > > is to be released early 2019. It is supposed to support > > C++ 11, and also some C++ 14 features. > > The information I've been able to find mostly discusses Linux support > for XLC 16. Any information about "some C++14 features"? I haven't > found any detail on that. > > I am working toward being able to target this for JDK 12, but realize > that might not be reachable. Windows is already there, because of > VS2017 support. There are a couple of minor patches needed for gcc > and clang based builds; Linux-x64 and MacOSX-x64 have had a fair > amount of ad hoc testing. We (Oracle) only switched over the > Solaris/sparc builds to the necessary compiler version (Oracle Studio > 12.6) very recently, and there are some issues still to be dealt with > there. And the currently used XLC is just not up to the change. From ecki at zusammenkunft.net Fri Oct 5 09:21:34 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 5 Oct 2018 09:21:34 +0000 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: <93700d13-3e86-1b00-fb72-7942c426c1f5@gmail.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com>, <93700d13-3e86-1b00-fb72-7942c426c1f5@gmail.com> Message-ID: Why does that actually throw an Exception on Linux/Unix, it is a perfectly legal file name. Gruss Bernd Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: -2122936656m Auftrag von Gesendet: Freitag, Oktober 5, 2018 11:00 AM An: core-libs-dev at openjdk.java.net Betreff: Re: JarFile constructor throws undocumented exception (only) on Windows OS Just for reference - this came up while debugging an issue, that one of our users of Apache Ant project raised here https://bz.apache.org/bugzilla/show_bug.cgi?id=62764#c8 -Jaikiran On 04/10/18 3:06 PM, Jaikiran Pai wrote: > Please consider the following trivial code: > > import java.util.jar.*; > import java.io.*; > > public class JarFileTest { > public static void main(final String[] args) throws Exception { > final String tmpDir = System.getProperty("java.io.tmpdir"); > try { > final JarFile jarFile = new JarFile(tmpDir + File.separator > + "*"); > } catch (IOException ioe) { > System.out.println("Got the expected IOException " + ioe); > } > } > } > > The constructor of the JarFile is passed a string which intentionally is > an (wildcard) invalid path. The above code (as expected) throws an > IOException on *nix systems across various version of Java (tested > against Java 8, 11). The same code throws an IOException (as expected) > in Java 8 on Windows OS too. However, in Java 11, on Windows OS, this > code throws a different exception (java.nio.file.InvalidPathException) > which isn't IOException or a subclass of it: > > Exception in thread "main" java.nio.file.InvalidPathException: Illegal > char <*> at index 38: C:\Users\someone\AppData\Local\Temp\1\* > at > java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > at > java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229) > at java.base/java.io.File.toPath(File.java:2290) > at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1220) > at > java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727) > at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:845) > at java.base/java.util.zip.ZipFile.(ZipFile.java:245) > at java.base/java.util.zip.ZipFile.(ZipFile.java:175) > at java.base/java.util.jar.JarFile.(JarFile.java:341) > at java.base/java.util.jar.JarFile.(JarFile.java:312) > at java.base/java.util.jar.JarFile.(JarFile.java:251) > at JarFileTest.main(JarFileTest.java:8) > > > The javadoc of JarFile constructor(s) mentions that: > > * @throws IOException if an I/O error has occurred > > Given that the javadoc doesn't mention anything about this other > exception, would this throwing of java.nio.file.InvalidPathException be > considered a bug in the implementation? > > If this indeed is considered a bug, it appears to be the code in > java.util.zip.ZipFile$Source.get method which calls File#toPath(), which > as per its javadoc is indeed expected to throw an > java.nio.file.InvalidPathException if a Path cannot be constructed out > of the File. Looking at the implementation of the underlying > java.nio.file.FileSystem on *nix and Windows, they differ when it comes > to whether or not the exception gets thrown (Unix one seems to always > return a result). But keeping the implementation of > java.nio.file.FileSystem aside, I guess the > java.util.zip.ZipFile$Source.get code needs to have a catch block for > the InvalidPathException to wrap that into a IOException? Something like: > > > # HG changeset patch > # User Jaikiran Pai > # Date 1538645309 -19800 > # Thu Oct 04 14:58:29 2018 +0530 > # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e > # Parent 8705c6d536c5c197d0210acccf145ebc48f90227 > Wrap and throw an IOException when a InvalidPathException is thrown > > diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java > b/src/java.base/share/classes/java/util/zip/ZipFile.java > --- a/src/java.base/share/classes/java/util/zip/ZipFile.java > +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java > @@ -35,6 +35,7 @@ > import java.lang.ref.Cleaner.Cleanable; > import java.nio.charset.Charset; > import java.nio.charset.StandardCharsets; > +import java.nio.file.InvalidPathException; > import java.nio.file.attribute.BasicFileAttributes; > import java.nio.file.Files; > import java.util.ArrayDeque; > @@ -1218,8 +1219,13 @@ > > > static Source get(File file, boolean toDelete) throws IOException { > - Key key = new Key(file, > - Files.readAttributes(file.toPath(), > BasicFileAttributes.class)); > + final Key key; > + try { > + key = new Key(file, > + Files.readAttributes(file.toPath(), > BasicFileAttributes.class)); > + } catch (InvalidPathException ipe) { > + throw new IOException(ipe); > + } > Source src; > synchronized (files) { > src = files.get(key); > > > Any thoughts? > > > -Jaikiran > From jai.forums2013 at gmail.com Fri Oct 5 09:29:24 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 5 Oct 2018 14:59:24 +0530 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <93700d13-3e86-1b00-fb72-7942c426c1f5@gmail.com> Message-ID: <67a2c574-673e-1dea-d3d7-1a98bfa94451@gmail.com> Hello Bernd, On 05/10/18 2:51 PM, Bernd Eckenfels wrote: > Why does that actually throw an Exception on Linux/Unix, it is a > perfectly legal file name. In the context of my test and the issue reported in Apache Ant, it fails on Linux/Unix because there isn't actually a file present at that path. So it's a genuine NoSuchFileException and _isn't_ an implementation bug: Exception in thread "main" java.nio.file.NoSuchFileException: /tmp/* The reason I used a non-existent file in my sample, is to illustrate the difference in the exception thrown by Java 11 on Windows and *nix. -Jaikiran > > Gruss > Bernd > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ? > ------------------------------------------------------------------------ > *Von:* -2122936656m Auftrag von > *Gesendet:* Freitag, Oktober 5, 2018 11:00 AM > *An:* core-libs-dev at openjdk.java.net > *Betreff:* Re: JarFile constructor throws undocumented exception > (only) on Windows OS > ? > Just for reference - this came up while debugging an issue, that one of > our users of Apache Ant project raised here > https://bz.apache.org/bugzilla/show_bug.cgi?id=62764#c8 > > -Jaikiran > > > On 04/10/18 3:06 PM, Jaikiran Pai wrote: > > Please consider the following trivial code: > > > > import java.util.jar.*; > > import java.io.*; > > > > public class JarFileTest { > > ??? public static void main(final String[] args) throws Exception { > > ??? ??? final String tmpDir = System.getProperty("java.io.tmpdir"); > > ??? ??? try { > > ??? ??? ??? final JarFile jarFile = new JarFile(tmpDir + File.separator > > + "*"); > > ??? ??? } catch (IOException ioe) { > > ??? ??? ??? System.out.println("Got the expected IOException " + ioe); > > ??? ??? } > > ??? } > > } > > > > The constructor of the JarFile is passed a string which > intentionally is > > an (wildcard) invalid path. The above code (as expected) throws an > > IOException on *nix systems across various version of Java (tested > > against Java 8, 11). The same code throws an IOException (as expected) > > in Java 8 on Windows OS too. However, in Java 11, on Windows OS, this > > code throws a different exception (java.nio.file.InvalidPathException) > > which isn't IOException or a subclass of it: > > > > Exception in thread "main" java.nio.file.InvalidPathException: Illegal > > char <*> at index 38: C:\Users\someone\AppData\Local\Temp\1\* > > at > > > java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) > > > at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) > > at > java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) > > at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92) > > at > > > java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229) > > > at java.base/java.io.File.toPath(File.java:2290) > > at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1220) > > at > > > java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:727) > > > at > java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:845) > > at java.base/java.util.zip.ZipFile.(ZipFile.java:245) > > at java.base/java.util.zip.ZipFile.(ZipFile.java:175) > > at java.base/java.util.jar.JarFile.(JarFile.java:341) > > at java.base/java.util.jar.JarFile.(JarFile.java:312) > > at java.base/java.util.jar.JarFile.(JarFile.java:251) > > at JarFileTest.main(JarFileTest.java:8) > > > > > > The javadoc of JarFile constructor(s) mentions that: > > > > ???? * @throws IOException if an I/O error has occurred > > > > Given that the javadoc doesn't mention anything about this other > > exception, would this throwing of java.nio.file.InvalidPathException be > > considered a bug in the implementation? > > > > If this indeed is considered a bug, it appears to be the code in > > java.util.zip.ZipFile$Source.get method which calls File#toPath(), > which > > as per its javadoc is indeed expected to throw an > > java.nio.file.InvalidPathException if a Path cannot be constructed out > > of the File. Looking at the implementation of the underlying > > java.nio.file.FileSystem on *nix and Windows, they differ when it comes > > to whether or not the exception gets thrown (Unix one seems to always > > return a result). But keeping the implementation of > > java.nio.file.FileSystem aside, I guess the > > java.util.zip.ZipFile$Source.get code needs to have a catch block for > > the InvalidPathException to wrap that into a IOException? Something > like: > > > > > > # HG changeset patch > > # User Jaikiran Pai > > # Date 1538645309 -19800 > > #????? Thu Oct 04 14:58:29 2018 +0530 > > # Node ID ff1bfd8cc9a3b385716fa5191bb68989d552f87e > > # Parent? 8705c6d536c5c197d0210acccf145ebc48f90227 > > Wrap and throw an IOException when a InvalidPathException is thrown > > > > diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java > > b/src/java.base/share/classes/java/util/zip/ZipFile.java > > --- a/src/java.base/share/classes/java/util/zip/ZipFile.java > > +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java > > @@ -35,6 +35,7 @@ > > ?import java.lang.ref.Cleaner.Cleanable; > > ?import java.nio.charset.Charset; > > ?import java.nio.charset.StandardCharsets; > > +import java.nio.file.InvalidPathException; > > ?import java.nio.file.attribute.BasicFileAttributes; > > ?import java.nio.file.Files; > > ?import java.util.ArrayDeque; > > @@ -1218,8 +1219,13 @@ > > ? > > ? > > ???????? static Source get(File file, boolean toDelete) throws > IOException { > > -??????????? Key key = new Key(file, > > -????????????????????????????? Files.readAttributes(file.toPath(), > > BasicFileAttributes.class)); > > +??????????? final Key key; > > +??????????? try { > > +??????????????? key = new Key(file, > > +??????????????????????? Files.readAttributes(file.toPath(), > > BasicFileAttributes.class)); > > +??????????? } catch (InvalidPathException ipe) { > > +??????????????? throw new IOException(ipe); > > +??????????? } > > ???????????? Source src; > > ???????????? synchronized (files) { > > ???????????????? src = files.get(key); > > > > > > Any thoughts? > > > > > > -Jaikiran > > > From Alan.Bateman at oracle.com Fri Oct 5 10:45:05 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 11:45:05 +0100 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> Message-ID: On 04/10/2018 10:36, Jaikiran Pai wrote: > : > > > The javadoc of JarFile constructor(s) mentions that: > > ???? * @throws IOException if an I/O error has occurred > > Given that the javadoc doesn't mention anything about this other > exception, would this throwing of java.nio.file.InvalidPathException be > considered a bug in the implementation? > Yes, it's a bug in the ZipFile code as it's not specified to throw this unchecked exception. Note that the issue is not specific to Windows, you'll see the same thing on Linux/other with other garbage input - a good example to try is a path string with NUL characters. -Alan From jai.forums2013 at gmail.com Fri Oct 5 10:54:18 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 5 Oct 2018 16:24:18 +0530 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> Message-ID: <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> Hello Alan, On 05/10/18 4:15 PM, Alan Bateman wrote: > On 04/10/2018 10:36, Jaikiran Pai wrote: >> : >> >> >> The javadoc of JarFile constructor(s) mentions that: >> >> ????? * @throws IOException if an I/O error has occurred >> >> Given that the javadoc doesn't mention anything about this other >> exception, would this throwing of java.nio.file.InvalidPathException be >> considered a bug in the implementation? >> > Yes, it's a bug in the ZipFile code as it's not specified to throw > this unchecked exception. Note that the issue is not specific to > Windows, you'll see the same thing on Linux/other with other garbage > input - a good example to try is a path string with NUL characters. You are right indeed. Changing that sample code to something like: final JarFile jarFile = new JarFile(tmpDir + File.separator + "abc\0xyz"); does indeed end up throwing a java.nio.file.InvalidPathException even on *nix, on Java 11. I don't have access to create an issue for this in OpenJDK JIRA, so I'll go ahead and create one at bugs.java.com. -Jaikiran From chris.hegarty at oracle.com Fri Oct 5 11:06:01 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Oct 2018 12:06:01 +0100 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> Message-ID: <15e0ea38-0f23-0e07-6c4e-b823de7d2217@oracle.com> On 05/10/18 11:45, Alan Bateman wrote: > On 04/10/2018 10:36, Jaikiran Pai wrote: >> : >> >> >> The javadoc of JarFile constructor(s) mentions that: >> >> ????? * @throws IOException if an I/O error has occurred >> >> Given that the javadoc doesn't mention anything about this other >> exception, would this throwing of java.nio.file.InvalidPathException be >> considered a bug in the implementation? >> > Yes, it's a bug in the ZipFile code as it's not specified to throw this > unchecked exception. Given the stacktrace, from a previous email in this thread, does it make more sense to wrap the IPE in an IOException, rather then declaring that the ZipFile constructor can throw IPE? The reason I suggest this is that it looks, from that stacktrace, that the error is detected deep in the implementation, rather than when performing argument validation. If this is not the case, then maybe the implementation could be updated to perform the toPath operation earlier, or at least add some comment indicating the implicit arg check. -Chris. From jai.forums2013 at gmail.com Fri Oct 5 11:08:25 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 5 Oct 2018 16:38:25 +0530 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> Message-ID: <0d6fe0ae-9cd9-f272-00cb-18ed7a04cbc3@gmail.com> > I don't have access to create an issue for this in OpenJDK JIRA, so I'll > go ahead and create one at bugs.java.com. > I just submitted the report. Internal review id 9057522 has been assigned to the issue. -Jaikiran From rafael.wth at gmail.com Fri Oct 5 12:17:04 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 5 Oct 2018 14:17:04 +0200 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass Message-ID: Hi Alan, I second that the Unsafe::defineClass method should be removed at some point. I'd very much prefer using a stable API over following up changes on internal API. However, for Java agents, there is still no good way to define auxiliary classes. There is an open ticket on https://bugs.openjdk.java.net/browse/JDK-8201784 and I have described my concerns with the suggested API in the linked discussion as being insufficient for many use cases. I still hope that a defineClass method can be added to the Instrumentation interface; I would not know of any other good use case that currently makes use of the internal Unsafe version but agents. As of today, Unsafe::defineClass is however still a crucial element for many Java agents that are widely used in the enterprise space, e.g. for APM tools, security monitoring or metrics extraction. Not offering an alternative would lock out these tools and stop a large fraction of Java users from updating their production environments until a new workaround is found. I hope that you consider an API for Java agents to define classes as a blocker issue to be solved prior to removing Unsafe::defineClass alltogether. Thanks and best regards, Rafael From chris.hegarty at oracle.com Fri Oct 5 12:51:52 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Oct 2018 13:51:52 +0100 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: <0d6fe0ae-9cd9-f272-00cb-18ed7a04cbc3@gmail.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> <0d6fe0ae-9cd9-f272-00cb-18ed7a04cbc3@gmail.com> Message-ID: <5387742A-B588-4A17-8C57-273BEED2F3C8@oracle.com> > On 5 Oct 2018, at 12:08, Jaikiran Pai wrote: > >> I don't have access to create an issue for this in OpenJDK JIRA, so I'll >> go ahead and create one at bugs.java.com. >> > I just submitted the report. Internal review id 9057522 has been > assigned to the issue. And now in the JDK project: https://bugs.openjdk.java.net/browse/JDK-8211765 -Chris. From Alan.Bateman at oracle.com Fri Oct 5 13:53:05 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 14:53:05 +0100 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass In-Reply-To: References: Message-ID: <0364b931-58a9-0864-4a2c-46ab2f65d625@oracle.com> On 05/10/2018 13:17, Rafael Winterhalter wrote: > : > > However, for Java agents, there is still no good way to define > auxiliary classes. There is an open ticket on > https://bugs.openjdk.java.net/browse/JDK-8201784 and I have described > my concerns with the suggested API in the linked discussion as being > insufficient for many use cases. I still hope that a defineClass > method can be added to the Instrumentation interface; I would not know > of any other good use case that currently makes use of the internal > Unsafe version but agents. > > As of today, Unsafe::defineClass is however still a crucial element > for many Java agents that are widely used in the enterprise space, > e.g. for APM tools, security monitoring or metrics extraction. Not > offering an alternative would lock out these tools and stop a large > fraction of Java users from updating their production environments > until a new workaround is found. I hope that you consider an API for > Java agents to define classes as a blocker issue to be solved prior to > removing Unsafe::defineClass alltogether. > There was a lengthy thread about this topic on serviceability-dev earlier this year. As I'm sure you will remember, Mandy did propose additions to the Instrumentation API to support defining of auxiliary classes in the same runtime package as the instrumented class. The nice thing about that proposal is that extended the Instrumentation API in a way that is aligned with original purpose of this API. As I think we explained several times, the Instrumentation API is to support tools doing benign instrumentation. The Instrumentation API was never intended to support some of the scenarios that you brought up in the discussion. Yes, we understand that you are trying to support some "interesting" use-case, esp. around mocking, but many of these scenario that are way outside the scope of this API. We do need to get back to that discussion but it's important to set expectations at the same time. -Alan From Alan.Bateman at oracle.com Fri Oct 5 13:58:22 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 Oct 2018 14:58:22 +0100 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: <15e0ea38-0f23-0e07-6c4e-b823de7d2217@oracle.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <15e0ea38-0f23-0e07-6c4e-b823de7d2217@oracle.com> Message-ID: On 05/10/2018 12:06, Chris Hegarty wrote: > > Given the stacktrace, from a previous email in this thread, > does it make more sense to wrap the IPE in an IOException, > rather then declaring that the ZipFile constructor can throw > IPE? Right, there's no suggestion in this thread to change the spec, it's an implementation only change. -Alan From chris.hegarty at oracle.com Fri Oct 5 14:29:02 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Oct 2018 15:29:02 +0100 Subject: JarFile constructor throws undocumented exception (only) on Windows OS In-Reply-To: References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <15e0ea38-0f23-0e07-6c4e-b823de7d2217@oracle.com> Message-ID: > On 5 Oct 2018, at 14:58, Alan Bateman wrote: > >> On 05/10/2018 12:06, Chris Hegarty wrote: >> >> Given the stacktrace, from a previous email in this thread, >> does it make more sense to wrap the IPE in an IOException, >> rather then declaring that the ZipFile constructor can throw >> IPE? > Right, there's no suggestion in this thread to change the spec, it's an implementation only change. Good. Thanks for the clarification. -Chris From stokito at gmail.com Fri Oct 5 14:59:12 2018 From: stokito at gmail.com (Sergey Ponomarev) Date: Fri, 5 Oct 2018 17:59:12 +0300 Subject: StringBuilder and StringBuffer: add a new constructor with initial string AND initial capacity. Restrict passing a null into constructors Message-ID: Hi, Both StringBuilder and StringBuffer have two constructors: 1. StringBuilder(int capacity) - Constructs a string builder with no characters in it and an initial capacity specified by the capacity argument. 2. StringBuilder(String str) - Constructs a string builder initialized to the contents of the specified string. The initial capacity of the string builder is 16 plus the length of the string argument. It's code is: public StringBuilder(String str) { super(str.length() + 16); // call to StringBuilder(int capacity) append(str); } I would like to propose to add the third constructor which combines the first two: 3. StringBuilder(String seq, int capacity) - Constructs a string builder initialized to the contents of the specified string with the initial capacity specified by the capacity argument. Its code may look like: public StringBuilder(CharSequence seq, int capacity) { this(capacity); append(initialString); } JUSTIFICATION First of all the same constructor StringBuilder(String, Int32) already exists and is used in .NET/C#. I analyzed my company's projects and the second constructor is popular among developers and typically used for constructing big SQL queries: StringBuilder query = new StringBuilder("SELECT * FROM users"); // a lot of conditional appends of search criteria The problem is that typical queries are mostly big with length in range 200-600 chars while the string builder created by this constructor will have a much smaller capacity. So to avoid reallocations it's better to initialize the StringBuilder with expected capacity but then we have to use the first constructor and separate call of append(): StringBuilder query = new StringBuilder(512).append("SELECT * FROM users"); And here is two problems: 1. Most developers are quite lazy or just don't think about this and will prefer to use StringBuilder(String str) without specifying of initial capacity. But if IDE's autocomplete suggest them already existed constructor StringBuilder(String, int) they will probably use it instead. 2. Additional call of append() takes more place and is not so effective for a performance because it has to ensure capacity while having a separate constructor for this case can be optimized in future. Another one issue is that while it said in StringBuilder javadoc that some constructors may accept null string while in fact all constructor will throw NPE on a null value. I think it's better to specify it explicitly in JavaDoc. Please see my patch against JDK master branch with the changes: https://github.com/stokito/jdk/commit/2f5827b3001f5bd4e7b2f5eebc124a975e2a3e1c (you can add ".patch" to the URL to get the raw patch file) Regards, Sergey Ponomarev From jai.forums2013 at gmail.com Fri Oct 5 15:31:07 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 5 Oct 2018 21:01:07 +0530 Subject: [PATCH] JDK-8211765 - JarFile constructor throws undocumented exception In-Reply-To: <5387742A-B588-4A17-8C57-273BEED2F3C8@oracle.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> <0d6fe0ae-9cd9-f272-00cb-18ed7a04cbc3@gmail.com> <5387742A-B588-4A17-8C57-273BEED2F3C8@oracle.com> Message-ID: Thank you Chris. I've attached a patch here which catches the InvalidPathException within the implementation of ZipFile and wraps and throws a IOException. It's the same patch which I mentioned earlier in this thread, but now also includes jtreg testcase to reproduce the issue and verify the fix. I have run the jtreg test with and without this patch on my *nix system and it behaves as expected (fails without the fix and passes with it). I don't have a Windows OS at hand to test this patch and the testcase on it. I also did a very basic check and went through the JarFile/ZipFile constructor code path to see if there are other places in that flow which might need similar treatment. My not-so-thorough check didn't show up any other such instance. Could I please get help from someone who can sponsor this patch and help with the review too? -Jaikiran On 05/10/18 6:21 PM, Chris Hegarty wrote: >> On 5 Oct 2018, at 12:08, Jaikiran Pai wrote: >> >>> I don't have access to create an issue for this in OpenJDK JIRA, so I'll >>> go ahead and create one at bugs.java.com. >>> >> I just submitted the report. Internal review id 9057522 has been >> assigned to the issue. > And now in the JDK project: > > https://bugs.openjdk.java.net/browse/JDK-8211765 > > -Chris. -------------- next part -------------- # HG changeset patch # User Jaikiran Pai # Date 1538645309 -19800 # Thu Oct 04 14:58:29 2018 +0530 # Node ID 957376a6e53c751fa144d0e41e063ef9179a9275 # Parent e75f6076d391a6081e621d64641526c99bf8c5b2 JDK-8211765 Wrap and throw an IOException when a InvalidPathException is thrown from within ZipFile constructor diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java b/src/java.base/share/classes/java/util/zip/ZipFile.java --- a/src/java.base/share/classes/java/util/zip/ZipFile.java +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java @@ -35,6 +35,7 @@ import java.lang.ref.Cleaner.Cleanable; import java.nio.charset.Charset; import java.nio.charset.StandardCharsets; +import java.nio.file.InvalidPathException; import java.nio.file.attribute.BasicFileAttributes; import java.nio.file.Files; import java.util.ArrayDeque; @@ -1218,8 +1219,13 @@ static Source get(File file, boolean toDelete) throws IOException { - Key key = new Key(file, - Files.readAttributes(file.toPath(), BasicFileAttributes.class)); + final Key key; + try { + key = new Key(file, + Files.readAttributes(file.toPath(), BasicFileAttributes.class)); + } catch (InvalidPathException ipe) { + throw new IOException(ipe); + } Source src; synchronized (files) { src = files.get(key); diff --git a/test/jdk/java/util/jar/JarFile/Constructor.java b/test/jdk/java/util/jar/JarFile/Constructor.java --- a/test/jdk/java/util/jar/JarFile/Constructor.java +++ b/test/jdk/java/util/jar/JarFile/Constructor.java @@ -23,7 +23,7 @@ /** * @test - * @bug 4842702 + * @bug 4842702 8211765 * @summary Check that constructors throw specified exceptions * @author Martin Buchholz */ @@ -63,5 +63,23 @@ try { Unreached (new JarFile (new File ("NoSuchJar.jar"))); } catch (IOException e) {} + + // operating system specific + final String osname = System.getProperty("os.name"); + if (osname.startsWith("Windows")) { + doWindowsTests(); + } else { + doUnixTests(); + } + } + + private static void doWindowsTests() throws Exception { + try { Unreached (new JarFile ("C:\\*")); } // invalid character + catch (IOException e) {} + } + + private static void doUnixTests() throws Exception { + try { Unreached (new JarFile ("foo\u0000bar")); } // invalid character + catch (IOException e) {} } } From philipp.kunz at paratix.ch Fri Oct 5 15:54:34 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 05 Oct 2018 17:54:34 +0200 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> <5BB51D1A.2000600@oracle.com> <1538683131.2782.10.camel@paratix.ch> Message-ID: <1538754874.2782.17.camel@paratix.ch> Thanks to Martin's hint, I revised the test to use UTF-8 consistently and not utf. Philipp On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote: > "utf8" is a thing.??"utf" is not. > > On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz h> wrote: > > Thanks to Sherman's hint, I revised the test to use the terms > > unicode > > character and utf encoding consistently and not utf character. > > Affects > > only the test, mostly in comments and a few identifiers. > > > > Philipp > > > > > > On Wed, 2018-10-03 at 12:48 -0700, Xueming Shen wrote: > > > +1 > > > > > > only nit is it might be preferred to use "utf8" directly in the > > > test > > > instead of current "utf" > > > > > > -sherman > > > > > > On 10/03/2018 11:55 AM, Philipp Kunz wrote: > > > > In short, bug 6202130 is about removal of comments in > > > > Attributes > > > > like > > > > > > > > > XXX Need to handle UTF8 values and break up lines longer than > > > > > 72 > > > > > > > > The patch here contains a test that shows that utf characters > > > > are > > > > handled correctly, which has been the case before. Breaking > > > > lines > > > > has > > > > also been working before. > > > > > > > > In the main code, the patch only removes a few comments and > > > > does > > > > not > > > > change actual code. It all has been working before and now we > > > > know. > > > > > > > > Philipp > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > > > > > > > > > > > > > > > > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > > > > > Hi, > > > > > > > > > > There are some comments in the source code like this: > > > > > > > > > > ? >??XXX Need to handle UTF8 values and break up lines longer > > > > > than 72 bytes > > > > > > > > > > in Attributes.java on lines 299, 327, and 370. Bug 6202130 > > > > > also > > > > > suggests > > > > > to add a test to show that the character set is fully > > > > > supported > > > > > before > > > > > actually removing those comments. > > > > > > > > > > Hence, I added such a test, see ValueUtfEncoding in attached > > > > > patch, and > > > > > it finds the complete utf character set supported correctly > > > > > and > > > > > that it > > > > > has been so already before. > > > > > > > > > > The comments in Attributes also say that lines longer than 72 > > > > > bytes need > > > > > to be broken. That is a different issue and has been already > > > > > addressed > > > > > and solved in bug 6372077 and is now tested in > > > > > LineBreakLineWidth > > > > > and > > > > > therefore, that line break part of the comment is obsolete > > > > > now as > > > > > well > > > > > with the exception of version headers ("Manifest-Version" or > > > > > "Signature-Version") at least when taking strictly. > > > > > > > > > > Version headers are not subject of bug 6202130 for which my > > > > > patch > > > > > intends to provide a fix and if only because multi-byte > > > > > characters are > > > > > not allowed in version headers and wasn't subject of 6372077 > > > > > either > > > > > which was about too short lines rather than too long ones. If > > > > > I > > > > > would > > > > > change only the minimum I could argue was safe, there would > > > > > have > > > > > to > > > > > remain a comment in Attributes.java on line 327 like > > > > > > > > > > ? >??XXX Need to handle version headers longer than 72 bytes > > > > > > > > > > but I guess that should probably better be represented as > > > > > another > > > > > bug > > > > > rather than this style of comment if at all desired. There > > > > > are > > > > > some bugs > > > > > concerning version headers and particularly the behavior of > > > > > the > > > > > manifests in their absence, among possibly others, 6910466, > > > > > 4935610, > > > > > 4271239, 8196371 and 4256580 which have some relation but I > > > > > haven't > > > > > found one that really fits the 72 byte line length limit of > > > > > version > > > > > headers. Whether such a bug is created or found or not, it > > > > > does > > > > > not > > > > > directly relate to the one I'm trying to fix here, 6202130. > > > > > > > > > > If also the test is good I would assume that the comments can > > > > > be > > > > > removed now without actually changing the Manifest and > > > > > Attributes > > > > > implementation. > > > > > > > > > > Regards, > > > > > Philipp > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130.patch Type: text/x-patch Size: 9667 bytes Desc: not available URL: From rafael.wth at gmail.com Fri Oct 5 16:14:34 2018 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 5 Oct 2018 18:14:34 +0200 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass In-Reply-To: <0364b931-58a9-0864-4a2c-46ab2f65d625@oracle.com> References: <0364b931-58a9-0864-4a2c-46ab2f65d625@oracle.com> Message-ID: Hi Alan, yes, I remember the discussion well. Unfortunately, I did not get the impression that my argument was heard or even considered. I mentioned the possible positive effects to mocking in Mockito as a supportive argument but not at all as my main point. From my experience of implementing a good dozed of agents for various customers and from consulting for several major Java tool vendors, I argue that the suggested API does not sufficiently cover many of the mentioned "benign" instrumentation use cases. I fully agree that Unsafe needs to be dismantled but we should neither forget how much good came from the class when restricting its use and that we should retain these use cases as good as possible. Monitoring agents are used in a majority of production environments nowadays, it would be a shame if some of those would suddenly stop working or had to restrict their feature set. To make sure that this is considered properly, I want to lay out a simple but common instrumentation use case once again to show how the current API suggestion is too limited. Consider a basic instrumentation for monitoring the runtime of a business transaction that spans to classes. I keep it fairly simple but this is not too far off to how some monitoring tools are actually implemented. Given the state: package foo; public class Foo { Bar bar; public void foo() { // some expensive operation bar.bar(new SomeRunnable()); } } package bar; public class Bar { public void bar(Runnable r) { r.run(); // some expensive operation } } a Java agent is used to inject a class and to instrument the above classes into: package foo; public class Foo { Bar bar; public void foo() { long time = System.currentTimeMillis(); // some expensive operation bar.bar(new InjectedRunnable(new SomeRunnable(), time)); } } package foo; public class InjectedRunnable implements Runnable { private final Runnable delegate; public final long time; public void run () { delegate.run(); } } package bar; public class Bar { public void bar(Runnable r) { r.run(); // some expensive operation if (r instanceof InjectedRunnable) { System.out.println(System.currentTimeMillis() - ((InjectedRunnable) r).time); } } } With restricting class injection to a package, the InjectedRunnable cannot be injected upon loading bar.Bar but only upon loading foo.Foo. This means that if bar.Bar was loaded and used before foo.Foo, a NoClassDefFoundError is thrown. As a Java agent cannot controll the order of class loading, the only alternative is delaying the instrumentation of bar.Bar until foo.Foo was loaded such that foo.InjectedRunnable is guaranteed to exist. This possibily requires a retransformation of bar.Bar which is obviously adding to runtime costs, especially if several such combined instrumentations are applied by an agent. Another alternative is to inject the callback into the package of whatever class is loaded first and condition the instrumentation upon it. But due to module boundaries, this is not always possible unless one is willing to break encapsulation of modules based on class loading order what I find a doubtful approach. I have taken the proposal very seriously and I have spent a few days of my own time to battle test it in real-life agents that are widely used in the Java space. With a lot of effort, you can make it work but at a minimum, jumping through the additional hoops adds up to several seconds of VM startup time besides cluttering the agent code base. I do not think that this is a desirable outcome of an API evolution and I find it a bit disappointing that my efforts and feedback are just discarded as not being "benign instrumentation". That said, the easiest migration path is to implement your own Unsafe::defineClass as: class UnsafeDefineClassProxy { void foo(Instrumentation inst, Class packageOwner, byte[] bytes) { inst.addClassFileTransformer(new ClassFileTransformer() { public byte[] transform(..., Injector injector) { if (classBeingRetransformed == packageOwner) { injector.inject(bytes); return null; }} }, true); inst.retransformClasses(packageOwner); } } All you need is a class from the targeted package to inject a class of your choosing. But of course, performance is terrible. Again, it is really not my intention to be overly bothering with this issue, I just think this is really important to get right. I have spent a lot of time on eveluating the proposal and I do not find it sufficient. I am saying this from experience in the field, I beg you to take me seriously on this. I also know that I am not the only agent vendor that is concered about this API proposal and I will ask others to come forward as well. Thanks again for your time and best regards, Rafael Am Fr., 5. Okt. 2018 um 15:53 Uhr schrieb Alan Bateman < Alan.Bateman at oracle.com>: > On 05/10/2018 13:17, Rafael Winterhalter wrote: > > : > > > > However, for Java agents, there is still no good way to define > > auxiliary classes. There is an open ticket on > > https://bugs.openjdk.java.net/browse/JDK-8201784 and I have described > > my concerns with the suggested API in the linked discussion as being > > insufficient for many use cases. I still hope that a defineClass > > method can be added to the Instrumentation interface; I would not know > > of any other good use case that currently makes use of the internal > > Unsafe version but agents. > > > > As of today, Unsafe::defineClass is however still a crucial element > > for many Java agents that are widely used in the enterprise space, > > e.g. for APM tools, security monitoring or metrics extraction. Not > > offering an alternative would lock out these tools and stop a large > > fraction of Java users from updating their production environments > > until a new workaround is found. I hope that you consider an API for > > Java agents to define classes as a blocker issue to be solved prior to > > removing Unsafe::defineClass alltogether. > > > There was a lengthy thread about this topic on serviceability-dev > earlier this year. As I'm sure you will remember, Mandy did propose > additions to the Instrumentation API to support defining of auxiliary > classes in the same runtime package as the instrumented class. The nice > thing about that proposal is that extended the Instrumentation API in a > way that is aligned with original purpose of this API. As I think we > explained several times, the Instrumentation API is to support tools > doing benign instrumentation. The Instrumentation API was never intended > to support some of the scenarios that you brought up in the discussion. > Yes, we understand that you are trying to support some "interesting" > use-case, esp. around mocking, but many of these scenario that are way > outside the scope of this API. We do need to get back to that discussion > but it's important to set expectations at the same time. > > -Alan > From xueming.shen at oracle.com Fri Oct 5 16:29:00 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 05 Oct 2018 09:29:00 -0700 Subject: [PATCH] JDK-8211765 - JarFile constructor throws undocumented exception In-Reply-To: References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> <0d6fe0ae-9cd9-f272-00cb-18ed7a04cbc3@gmail.com> <5387742A-B588-4A17-8C57-273BEED2F3C8@oracle.com> Message-ID: <5BB7914C.9070908@oracle.com> Hi Jaikiran, "wrap to throw a IOE" appears good. I will sponsor this patch. Thanks! -Sherman On 10/5/18, 8:31 AM, Jaikiran Pai wrote: > Thank you Chris. > > I've attached a patch here which catches the InvalidPathException within > the implementation of ZipFile and wraps and throws a IOException. It's > the same patch which I mentioned earlier in this thread, but now also > includes jtreg testcase to reproduce the issue and verify the fix. I > have run the jtreg test with and without this patch on my *nix system > and it behaves as expected (fails without the fix and passes with it). I > don't have a Windows OS at hand to test this patch and the testcase on it. > > I also did a very basic check and went through the JarFile/ZipFile > constructor code path to see if there are other places in that flow > which might need similar treatment. My not-so-thorough check didn't show > up any other such instance. > > Could I please get help from someone who can sponsor this patch and help > with the review too? > > -Jaikiran > > > On 05/10/18 6:21 PM, Chris Hegarty wrote: >>> On 5 Oct 2018, at 12:08, Jaikiran Pai wrote: >>> >>>> I don't have access to create an issue for this in OpenJDK JIRA, so I'll >>>> go ahead and create one at bugs.java.com. >>>> >>> I just submitted the report. Internal review id 9057522 has been >>> assigned to the issue. >> And now in the JDK project: >> >> https://bugs.openjdk.java.net/browse/JDK-8211765 >> >> -Chris. From xueming.shen at oracle.com Fri Oct 5 16:48:17 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 05 Oct 2018 09:48:17 -0700 Subject: RFR JDK-8211728,JarFile::versionedStream() does not filter META-INF resources in versioned stream Message-ID: <5BB795D1.5050200@oracle.com> Hi Please help review the change for JDK-8211728 issue: https://bugs.openjdk.java.net/browse/JDK-8211728 webrev: http://cr.openjdk.java.net/~sherman/8211728/webrev The "intention" of JEP 238 is that the resources under META-INF can't/shouldn't be versioned. But it appears this is not documented & specified clearly/explicitly. And the JarFile implementation has loophole dealing with this case. The spec clarification is being traced/addressed separately via JDK-8211758. The change proposed here is to fix the JarFile implementation. Note: the direct trigger of the bug is that versionedStream() does not expect the possibility VersinedEntry() might return null when the entry is actually under META-INF/versions/{n}/META-INF, in which it has a "basename" of META-INF/xxx but doesn't have a real entry under /META-INF (in which the getVersionEntry(...) is invoked with (name="META-INF/xxx", je=null). Thanks, Sherman From lance.andersen at oracle.com Fri Oct 5 22:41:15 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 5 Oct 2018 18:41:15 -0400 Subject: RFR JDK-8211728,JarFile::versionedStream() does not filter META-INF resources in versioned stream In-Reply-To: <5BB795D1.5050200@oracle.com> References: <5BB795D1.5050200@oracle.com> Message-ID: <99091B34-B74F-4427-A838-28709A76A656@oracle.com> Hi Sherman, The change looks OK Best Lance > On Oct 5, 2018, at 12:48 PM, Xueming Shen wrote: > > Hi > > Please help review the change for JDK-8211728 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211728 > webrev: http://cr.openjdk.java.net/~sherman/8211728/webrev > > The "intention" of JEP 238 is that the resources under META-INF can't/shouldn't > be versioned. But it appears this is not documented & specified clearly/explicitly. > And the JarFile implementation has loophole dealing with this case. The spec > clarification is being traced/addressed separately via JDK-8211758. The change > proposed here is to fix the JarFile implementation. > > Note: the direct trigger of the bug is that versionedStream() does not expect the > possibility VersinedEntry() might return null when the entry is actually under > META-INF/versions/{n}/META-INF, in which it has a "basename" of META-INF/xxx > but doesn't have a real entry under /META-INF (in which the getVersionEntry(...) > is invoked with (name="META-INF/xxx", je=null). > > Thanks, > Sherman Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jai.forums2013 at gmail.com Sat Oct 6 01:19:39 2018 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 6 Oct 2018 06:49:39 +0530 Subject: [PATCH] JDK-8211765 - JarFile constructor throws undocumented exception In-Reply-To: <5BB7914C.9070908@oracle.com> References: <0acee49c-5493-a769-2437-4b46ce04d5c7@gmail.com> <81980b9c-431d-011c-3369-9f63b87f99de@gmail.com> <0d6fe0ae-9cd9-f272-00cb-18ed7a04cbc3@gmail.com> <5387742A-B588-4A17-8C57-273BEED2F3C8@oracle.com> <5BB7914C.9070908@oracle.com> Message-ID: <1d2cebe0-170b-d2dc-f4f0-081c1f36342b@gmail.com> Thank you Sherman. -Jaikiran On 05/10/18 9:59 PM, Xueming Shen wrote: > Hi Jaikiran, > > "wrap to throw a IOE" appears good. I will sponsor this patch. > > Thanks! > -Sherman > > On 10/5/18, 8:31 AM, Jaikiran Pai wrote: >> Thank you Chris. >> >> I've attached a patch here which catches the InvalidPathException within >> the implementation of ZipFile and wraps and throws a IOException. It's >> the same patch which I mentioned earlier in this thread, but now also >> includes jtreg testcase to reproduce the issue and verify the fix. I >> have run the jtreg test with and without this patch on my *nix system >> and it behaves as expected (fails without the fix and passes with it). I >> don't have a Windows OS at hand to test this patch and the testcase >> on it. >> >> I also did a very basic check and went through the JarFile/ZipFile >> constructor code path to see if there are other places in that flow >> which might need similar treatment. My not-so-thorough check didn't show >> up any other such instance. >> >> Could I please get help from someone who can sponsor this patch and help >> with the review too? >> >> -Jaikiran >> >> >> On 05/10/18 6:21 PM, Chris Hegarty wrote: >>>> On 5 Oct 2018, at 12:08, Jaikiran Pai? >>>> wrote: >>>> >>>>> I don't have access to create an issue for this in OpenJDK JIRA, >>>>> so I'll >>>>> go ahead and create one at bugs.java.com. >>>>> >>>> I just submitted the report. Internal review id 9057522 has been >>>> assigned to the issue. >>> And now in the JDK project: >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211765 >>> >>> -Chris. > From Alan.Bateman at oracle.com Sat Oct 6 07:17:13 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 6 Oct 2018 08:17:13 +0100 Subject: RFR JDK-8211728,JarFile::versionedStream() does not filter META-INF resources in versioned stream In-Reply-To: <5BB795D1.5050200@oracle.com> References: <5BB795D1.5050200@oracle.com> Message-ID: On 05/10/2018 17:48, Xueming Shen wrote: > Hi > > Please help review the change for JDK-8211728 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211728 > webrev: http://cr.openjdk.java.net/~sherman/8211728/webrev > > The "intention" of JEP 238 is that the resources under META-INF > can't/shouldn't > be versioned. But it appears this is not documented & specified > clearly/explicitly. > And the JarFile implementation has loophole dealing with this case. > The spec > clarification is being traced/addressed separately via JDK-8211758. > The change > proposed here is to fix the JarFile implementation. > > Note: the direct trigger of the bug is that versionedStream() does not > expect the > possibility VersinedEntry() might return null when the entry is > actually under > META-INF/versions/{n}/META-INF, in which it has a "basename" of > META-INF/xxx > but doesn't have a real entry under /META-INF (in which the > getVersionEntry(...) > is invoked with (name="META-INF/xxx", je=null). The update to versionedStream looks okay but the test seems to be checking JarFile::stream rather than versionedStream. For the bug we need the stream to end without NPE and we also need to check that there isn't an element for META-INF/Foo.class (because this is not in the base section). -Alan From Alan.Bateman at oracle.com Sat Oct 6 07:43:16 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 6 Oct 2018 08:43:16 +0100 Subject: Review Request JDK-8181443: Replace usages of jdk.internal.misc.Unsafe with MethodHandles.Lookup.defineClass In-Reply-To: References: <0364b931-58a9-0864-4a2c-46ab2f65d625@oracle.com> Message-ID: <90492fd1-402c-bdc5-4180-cdad11611af2@oracle.com> On 05/10/2018 17:14, Rafael Winterhalter wrote: > : > > To make sure that this is considered properly, I want to lay out a > simple but common instrumentation use case once again to show how the > current API suggestion is too limited. Consider a basic > instrumentation for monitoring the runtime of a business transaction > that spans to classes. I keep it fairly simple but this is not too far > off to how some monitoring tools are actually implemented. This discussion always comes to down to what the Instrumentation API is intended for. Some of these apparently "simple" cases aren't really simple as they are trying to use Instrumentation API in ways that were never intended. As we explained in the discussions on serviceability-dev, the intention was to support cases where code is instrumented with calls into agent provided supporting classes and reduce any dependence that can lead to circularity issues. It maybe that the current appendToXXXSearch is too limited as it doesn't help with cases where the agent is spinning the supporting classes at run-time, in which case there may be a useful discussion there. The serviceability-dev list is the right place for that. -Alan From xueming.shen at oracle.com Sat Oct 6 08:29:58 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Sat, 6 Oct 2018 01:29:58 -0700 Subject: RFR JDK-8211728, JarFile::versionedStream() does not filter META-INF resources in versioned stream In-Reply-To: References: <5BB795D1.5050200@oracle.com> Message-ID: <6BF08497-B527-44ED-9181-26D2D90A90C1@oracle.com> The created mr jar file is being tested in #139 with versionedStream(). Without the fix there will be a npe. On Oct 6, 2018, at 12:17 AM, Alan Bateman wrote: > On 05/10/2018 17:48, Xueming Shen wrote: > Hi > > Please help review the change for JDK-8211728 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211728 > webrev: http://cr.openjdk.java.net/~sherman/8211728/webrev > > The "intention" of JEP 238 is that the resources under META-INF can't/shouldn't > be versioned. But it appears this is not documented & specified clearly/explicitly. > And the JarFile implementation has loophole dealing with this case. The spec > clarification is being traced/addressed separately via JDK-8211758. The change > proposed here is to fix the JarFile implementation. > > Note: the direct trigger of the bug is that versionedStream() does not expect the > possibility VersinedEntry() might return null when the entry is actually under > META-INF/versions/{n}/META-INF, in which it has a "basename" of META-INF/xxx > but doesn't have a real entry under /META-INF (in which the getVersionEntry(...) > is invoked with (name="META-INF/xxx", je=null). The update to versionedStream looks okay but the test seems to be checking JarFile::stream rather than versionedStream. For the bug we need the stream to end without NPE and we also need to check that there isn't an element for META-INF/Foo.class (because this is not in the base section). -Alan From Alan.Bateman at oracle.com Sat Oct 6 08:54:18 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 6 Oct 2018 09:54:18 +0100 Subject: RFR JDK-8211728,JarFile::versionedStream() does not filter META-INF resources in versioned stream In-Reply-To: <6BF08497-B527-44ED-9181-26D2D90A90C1@oracle.com> References: <5BB795D1.5050200@oracle.com> <6BF08497-B527-44ED-9181-26D2D90A90C1@oracle.com> Message-ID: On 06/10/2018 09:29, Xueming Shen wrote: > The created mr jar file is being tested in #139 with versionedStream(). Without the fix there will be a npe. Right but it's not testing that the versioned stream doesn't include META-INF/Foo.class. We need some test for this to be confident that the versioned stream never includes resources from META-INF in the versioned section. -Alan From lance.andersen at oracle.com Sat Oct 6 13:50:19 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 6 Oct 2018 09:50:19 -0400 Subject: RFR: 8211765 - JarFile constructor throws undocumented exception Message-ID: <9791A1B2-DC6E-41EB-9A6C-E9465469B35D@oracle.com> Hi All I integrated and tested Jaikiran?s patch. I made a minor change to the test. The webrev can be found at http://cr.openjdk.java.net/~lancea/8211765/webrev.00/ I have run the jdk tier1, tier2, and tier 3 tests as well as the JCK java_util test via mach5 and there were no additional failures Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Sat Oct 6 15:27:40 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 6 Oct 2018 16:27:40 +0100 Subject: RFR: 8211765 - JarFile constructor throws undocumented exception In-Reply-To: <9791A1B2-DC6E-41EB-9A6C-E9465469B35D@oracle.com> References: <9791A1B2-DC6E-41EB-9A6C-E9465469B35D@oracle.com> Message-ID: <1A261862-B596-4C9B-BFFE-2F0A96DD3368@oracle.com> Looks good. -Chris > On 6 Oct 2018, at 14:50, Lance Andersen wrote: > > Hi All > > I integrated and tested Jaikiran?s patch. I made a minor change to the test. The webrev can be found at > > http://cr.openjdk.java.net/~lancea/8211765/webrev.00/ > > I have run the jdk tier1, tier2, and tier 3 tests as well as the JCK java_util test via mach5 and there were no additional failures > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From aleksei.voitylov at bell-sw.com Sat Oct 6 15:07:52 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Sat, 6 Oct 2018 18:07:52 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> Kim, from an ARM port perspective, the stable GCC version is 4.9. The port compiles with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I agree on the overall direction and we'll commit resources to testing it further, but from an ARM port perspective it may happen JDK 12 is a little too optimistic. GCC x86 is a lot more stable than for ARM32 and AARCH64. -Aleksei On 05/10/2018 00:09, Kim Barrett wrote: >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov wrote: >> >> Kim, >> >> Thank you for posting this. It's an important step to make. I wanted to clarify a couple of points: >> >> 1. Since this is infrastructure JEP, is the version of JDK which will undergo such changes going to be some future version or does it apply to past versions as well? I'm concerned with how we can simplify security backports to 8u which (I currently assume) is not subject to this change. > Future version (perhaps as soon as JDK 12). I don't think there is > any desire to backport this change. And yes, introducing the use of > new language features will make backports even more interesting than > they already are. That seems unavoidable if we're going to pursue > this direction. > >> 2. Which versions of GCC do you tentatively consider at this point? Non-x86 ports may have a problem upgrading to a specific version of GCC which the shared code will use and may need additional lead time to adjust. > I think our (ad hoc) testing has been limited to gcc 7.x. But looking > at the gcc language conformance tables and release notes, gcc 5.x > might be good enough, and gcc 6.x seems fairly likely sufficient. Of > course, older versions are more likely to have bugs in some of these > new features. Updating the minimum supported versions for gcc and > clang are noted as TBD in the JEP. > From thomas.stuefe at gmail.com Mon Oct 8 10:48:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 8 Oct 2018 12:48:57 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: Hi Kim, is this JEP only about C++14 features or shall we discuss older features too? The reason I am asking is that I would like us to officially endorse namespaces. Not inline namespaces, just plain old namespaces. HotSpot makes very limited use of namespaces. Not really true, we already use them. E.g. in metaspace coding, I used them to keep the global name space clean and to keep internals internal. This was met with positive reviews, and it works on all toolchains, so compiler support should not be a problem. Using namespaces, we could get slowly replace the "AllStatic" classes, which are namespaces in all but name. In contrast to classes, namespaces can be spread over multiple files and compilation units, and allow for cleaner separation of internal and external coding. It also would allow us to get rid the middle-of-header-platform-inclusions: For example, today we have: [os.hpp] class os: AllStatic { .... (platform independent, outward facing os:: functions) #include "os_linux.hpp" >> (Inner class "Linux" with platform specific os functions) ... } Not only is the inclusion in the middle of a class terrifying, it also means the shared, outward facing os:: namespace contains class Linux and lots of platform specific internals. With namespaces one could: [os.hpp] namespace os { .... (platform independent, outward facing os:: functions) .... } [os_linux.hpp] namespace os { namespace Linux { (linux specific os functions) } } I think this is way cleaner, and keeps platform specifics from including files which only care for the shared os interface. -- Note that I would prefer forbidding the "using" directive for callers of namespace functions, but rather force them to spell out the namespace: So, instead of this: using os; jlong m = available_memory(); I would prefer this, which is our current practice with AllStatic childs: jlong m = os::available_memory(); The latter form would keep the code grepable. Best Regards, Thomas On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett wrote: > > I've submitted a JEP for > > (1) enabling the use of C++14 Language Features when building the JDK, > > (2) define a process for deciding and documenting which new features > can be used or are forbidden in HotSpot code, > > (3) provide an initial list of permitted and forbidden new features. > > https://bugs.openjdk.java.net/browse/JDK-8208089 > From volker.simonis at gmail.com Mon Oct 8 12:43:53 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Oct 2018 14:43:53 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: On Mon, Oct 8, 2018 at 12:49 PM Thomas St?fe wrote: > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. > > HotSpot makes very limited use of namespaces. > > Not really true, we already use them. E.g. in metaspace coding, I used > them to keep the global name space clean and to keep internals > internal. This was met with positive reviews, and it works on all > toolchains, so compiler support should not be a problem. Using > namespaces, we could get slowly replace the "AllStatic" classes, which > are namespaces in all but name. In contrast to classes, namespaces can > be spread over multiple files and compilation units, and allow for > cleaner separation of internal and external coding. > > It also would allow us to get rid the middle-of-header-platform-inclusions: > That's overdue since a long time! It would allow us to finally get correct code navigation in IDEs. > For example, today we have: > > [os.hpp] > class os: AllStatic { > .... > (platform independent, outward facing os:: functions) > #include "os_linux.hpp" > >> (Inner class "Linux" with platform specific os functions) > ... > } > > Not only is the inclusion in the middle of a class terrifying, it also > means the shared, outward facing os:: namespace contains class Linux > and lots of platform specific internals. > > With namespaces one could: > > [os.hpp] > namespace os { > .... > (platform independent, outward facing os:: functions) > .... > } > > [os_linux.hpp] > namespace os { > namespace Linux { > (linux specific os functions) > } > } > > I think this is way cleaner, and keeps platform specifics from > including files which only care for the shared os interface. > > -- > > Note that I would prefer forbidding the "using" directive for callers > of namespace functions, but rather force them to spell out the > namespace: > As far as I saw, "using" directives are already on the "Exclude" list in Kim's proposal. > So, instead of this: > > using os; > jlong m = available_memory(); > > I would prefer this, which is our current practice with AllStatic childs: > > jlong m = os::available_memory(); > > The latter form would keep the code grepable. > > Best Regards, Thomas > On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett wrote: > > > > I've submitted a JEP for > > > > (1) enabling the use of C++14 Language Features when building the JDK, > > > > (2) define a process for deciding and documenting which new features > > can be used or are forbidden in HotSpot code, > > > > (3) provide an initial list of permitted and forbidden new features. > > > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > From matcdac at gmail.com Mon Oct 8 14:43:20 2018 From: matcdac at gmail.com (Prakhar Makhija) Date: Mon, 8 Oct 2018 20:13:20 +0530 Subject: core-libs-dev Digest, Vol 138, Issue 30 In-Reply-To: References: Message-ID: Guys are there src git repositories for javase? Please share the links I found git repos for javaee only On Mon 8 Oct, 2018, 5:30 PM , wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-request at openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Aleksei Voitylov) > 2. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Thomas St?fe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 6 Oct 2018 18:07:52 +0300 > From: Aleksei Voitylov > To: Kim Barrett > Cc: build-dev , hotspot-dev developers > , core-libs-dev at openjdk.java.net > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6 at bell-sw.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Kim, > > from an ARM port perspective, the stable GCC version is 4.9. The port > compiles with stock GCC 7.3 but a lot of testing is required before > moving to GCC 7.3. I agree on the overall direction and we'll commit > resources to testing it further, but from an ARM port perspective it may > happen JDK 12 is a little too optimistic. > > GCC x86 is a lot more stable than for ARM32 and AARCH64. > > -Aleksei > > On 05/10/2018 00:09, Kim Barrett wrote: > >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov < > aleksei.voitylov at bell-sw.com> wrote: > >> > >> Kim, > >> > >> Thank you for posting this. It's an important step to make. I wanted to > clarify a couple of points: > >> > >> 1. Since this is infrastructure JEP, is the version of JDK which will > undergo such changes going to be some future version or does it apply to > past versions as well? I'm concerned with how we can simplify security > backports to 8u which (I currently assume) is not subject to this change. > > Future version (perhaps as soon as JDK 12). I don't think there is > > any desire to backport this change. And yes, introducing the use of > > new language features will make backports even more interesting than > > they already are. That seems unavoidable if we're going to pursue > > this direction. > > > >> 2. Which versions of GCC do you tentatively consider at this point? > Non-x86 ports may have a problem upgrading to a specific version of GCC > which the shared code will use and may need additional lead time to adjust. > > I think our (ad hoc) testing has been limited to gcc 7.x. But looking > > at the gcc language conformance tables and release notes, gcc 5.x > > might be good enough, and gcc 6.x seems fairly likely sufficient. Of > > course, older versions are more likely to have bugs in some of these > > new features. Updating the minimum supported versions for gcc and > > clang are noted as TBD in the JEP. > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 8 Oct 2018 12:48:57 +0200 > From: Thomas St?fe > To: Kim Barrett > Cc: build-dev , HotSpot Open Source > Developers , Java Core Libs > > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: > Go62SyPqo9X1aW9eZeU3gxcBujA at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. > > HotSpot makes very limited use of namespaces. > > Not really true, we already use them. E.g. in metaspace coding, I used > them to keep the global name space clean and to keep internals > internal. This was met with positive reviews, and it works on all > toolchains, so compiler support should not be a problem. Using > namespaces, we could get slowly replace the "AllStatic" classes, which > are namespaces in all but name. In contrast to classes, namespaces can > be spread over multiple files and compilation units, and allow for > cleaner separation of internal and external coding. > > It also would allow us to get rid the middle-of-header-platform-inclusions: > > For example, today we have: > > [os.hpp] > class os: AllStatic { > .... > (platform independent, outward facing os:: functions) > #include "os_linux.hpp" > >> (Inner class "Linux" with platform specific os functions) > ... > } > > Not only is the inclusion in the middle of a class terrifying, it also > means the shared, outward facing os:: namespace contains class Linux > and lots of platform specific internals. > > With namespaces one could: > > [os.hpp] > namespace os { > .... > (platform independent, outward facing os:: functions) > .... > } > > [os_linux.hpp] > namespace os { > namespace Linux { > (linux specific os functions) > } > } > > I think this is way cleaner, and keeps platform specifics from > including files which only care for the shared os interface. > > -- > > Note that I would prefer forbidding the "using" directive for callers > of namespace functions, but rather force them to spell out the > namespace: > > So, instead of this: > > using os; > jlong m = available_memory(); > > I would prefer this, which is our current practice with AllStatic childs: > > jlong m = os::available_memory(); > > The latter form would keep the code grepable. > > Best Regards, Thomas > On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett wrote: > > > > I've submitted a JEP for > > > > (1) enabling the use of C++14 Language Features when building the JDK, > > > > (2) define a process for deciding and documenting which new features > > can be used or are forbidden in HotSpot code, > > > > (3) provide an initial list of permitted and forbidden new features. > > > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > > > > End of core-libs-dev Digest, Vol 138, Issue 30 > ********************************************** > From claes.redestad at oracle.com Mon Oct 8 15:24:36 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:24:36 +0200 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization Message-ID: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> Hi, JDK-8207768 cause a noticeable regression in a subset of our startup tests due eagerly loading security.properties for getting a property that's only used in exceptional circumstances. Ensuring Manifest doesn't eagerly read in the property value in the static initializer avoids this. Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 Thanks! /Claes From claes.redestad at oracle.com Mon Oct 8 15:32:26 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:32:26 +0200 Subject: RFR: 8211859: (fc) Avoid initializing AtomicBoolean from RandomAccessFile Message-ID: <4032e6e5-dfb6-0cd5-3f7b-b6ebca0cb6ea@oracle.com> Hi, aligning the closing of RandomAccessFiles with the implementation in FileInput-/OutputStream improves startup in a few tests. Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 Thanks! /Claes From chris.hegarty at oracle.com Mon Oct 8 15:34:41 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 8 Oct 2018 16:34:41 +0100 Subject: RFR [12] 8211863: Problem list test/jdk/javax/naming/module/RunBasic.java Message-ID: Can I get a review to add javax/naming/module/RunBasic.java to the ProblemList until we can resolve 8211850. This test has been failing intermittently for months now. $ hg diff test/jdk/ProblemList.txt diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -866,6 +866,8 @@ javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all +javax/naming/module/RunBasic.java 8211850 generic-all + ############################################################################ -Chris. From lance.andersen at oracle.com Mon Oct 8 15:37:31 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 8 Oct 2018 11:37:31 -0400 Subject: RFR [12] 8211863: Problem list test/jdk/javax/naming/module/RunBasic.java In-Reply-To: References: Message-ID: +1 > On Oct 8, 2018, at 11:34 AM, Chris Hegarty wrote: > > Can I get a review to add javax/naming/module/RunBasic.java > to the ProblemList until we can resolve 8211850. This test > has been failing intermittently for months now. > > $ hg diff test/jdk/ProblemList.txt > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -866,6 +866,8 @@ > > javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all > > +javax/naming/module/RunBasic.java 8211850 generic-all > + > ############################################################################ > > > -Chris. > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From sean.mullan at oracle.com Mon Oct 8 15:47:14 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 8 Oct 2018 11:47:14 -0400 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> Message-ID: <975a559b-eaf9-fad6-4b30-04bb6ada254c@oracle.com> Looks good to me. --Sean On 10/8/18 11:24 AM, Claes Redestad wrote: > Hi, > > JDK-8207768 cause a noticeable regression in a subset of our startup > tests due eagerly loading security.properties for getting a property > that's only used in exceptional circumstances. Ensuring Manifest doesn't > eagerly read in the property value in the static initializer avoids this. > > Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Oct 8 15:55:12 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:55:12 +0200 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <975a559b-eaf9-fad6-4b30-04bb6ada254c@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> <975a559b-eaf9-fad6-4b30-04bb6ada254c@oracle.com> Message-ID: <723ef193-f144-95e2-3f2b-fc82d4418231@oracle.com> Thanks, Sean! /Claes On 2018-10-08 17:47, Sean Mullan wrote: > Looks good to me. > > --Sean > > On 10/8/18 11:24 AM, Claes Redestad wrote: >> Hi, >> >> JDK-8207768 cause a noticeable regression in a subset of our startup >> tests due eagerly loading security.properties for getting a property >> that's only used in exceptional circumstances. Ensuring Manifest >> doesn't eagerly read in the property value in the static initializer >> avoids this. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 >> >> Thanks! >> >> /Claes From Alan.Bateman at oracle.com Mon Oct 8 15:51:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Oct 2018 16:51:07 +0100 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> Message-ID: <47f79107-a3a2-1aee-596a-472d1a8110dc@oracle.com> On 08/10/2018 16:24, Claes Redestad wrote: > Hi, > > JDK-8207768 cause a noticeable regression in a subset of our startup > tests due eagerly loading security.properties for getting a property > that's only used in exceptional circumstances. Ensuring Manifest > doesn't eagerly read in the property value in the static initializer > avoids this. > > Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 This looks okay to me although something like "JAR_NAME" might be better than "JAR". -Alan From claes.redestad at oracle.com Mon Oct 8 15:59:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 17:59:05 +0200 Subject: RFR: 8211860: Avoid reading security properties eagerly on Manifest class initialization In-Reply-To: <47f79107-a3a2-1aee-596a-472d1a8110dc@oracle.com> References: <4a86031b-ee8f-b94f-f070-b31600011c76@oracle.com> <47f79107-a3a2-1aee-596a-472d1a8110dc@oracle.com> Message-ID: <7f07cf90-0fb3-1fba-30c3-83c0a6472089@oracle.com> On 2018-10-08 17:51, Alan Bateman wrote: > > > On 08/10/2018 16:24, Claes Redestad wrote: >> Hi, >> >> JDK-8207768 cause a noticeable regression in a subset of our startup >> tests due eagerly loading security.properties for getting a property >> that's only used in exceptional circumstances. Ensuring Manifest >> doesn't eagerly read in the property value in the static initializer >> avoids this. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8211860/jdk.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211860 > This looks okay to me although something like "JAR_NAME" might be > better than "JAR". Sure! /Claes From Alan.Bateman at oracle.com Mon Oct 8 16:49:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Oct 2018 17:49:59 +0100 Subject: RFR: 8211859: (fc) Avoid initializing AtomicBoolean from RandomAccessFile In-Reply-To: <4032e6e5-dfb6-0cd5-3f7b-b6ebca0cb6ea@oracle.com> References: <4032e6e5-dfb6-0cd5-3f7b-b6ebca0cb6ea@oracle.com> Message-ID: <8b412579-8917-57b3-2383-99c4adecd672@oracle.com> On 08/10/2018 16:32, Claes Redestad wrote: > Hi, > > aligning the closing of RandomAccessFiles with the implementation in > FileInput-/OutputStream improves startup in a few tests. > > Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 This looks okay to me. -Alan From ecki at zusammenkunft.net Mon Oct 8 17:37:40 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 8 Oct 2018 19:37:40 +0200 Subject: are there src git repositories for javase (was: core-libs-dev Digest, Vol 138, Issue 30) In-Reply-To: References: Message-ID: <5bbb95e4.1c69fb81.33a1d.9a37@mx.google.com> Hello, there is no official/canonical one as far as I know, but there are a few (externally maintained) Repos which are produced by mirroring the HG trees. I cannot endores any of them, but in GitHub you find: Older versions: https://github.com/openjdk-mirror SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11 Gruss Bernd BTW: ist not a good idea to respond to Digest mails, it messes up the threading and the subject -- http://bernd.eckenfels.net Von: Prakhar Makhija Gesendet: Montag, 8. Oktober 2018 18:44 An: core-libs-dev at openjdk.java.net Betreff: Re: core-libs-dev Digest, Vol 138, Issue 30 Guys are there src git repositories for javase? Please share the links I found git repos for javaee only On Mon 8 Oct, 2018, 5:30 PM , wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-request at openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Aleksei Voitylov) > 2. Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > (Thomas St?fe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 6 Oct 2018 18:07:52 +0300 > From: Aleksei Voitylov > To: Kim Barrett > Cc: build-dev , hotspot-dev developers > , core-libs-dev at openjdk.java.net > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6 at bell-sw.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Kim, > > from an ARM port perspective, the stable GCC version is 4.9. The port > compiles with stock GCC 7.3 but a lot of testing is required before > moving to GCC 7.3. I agree on the overall direction and we'll commit > resources to testing it further, but from an ARM port perspective it may > happen JDK 12 is a little too optimistic. > > GCC x86 is a lot more stable than for ARM32 and AARCH64. > > -Aleksei > > On 05/10/2018 00:09, Kim Barrett wrote: > >> On Oct 4, 2018, at 9:17 AM, Aleksei Voitylov < > aleksei.voitylov at bell-sw.com> wrote: > >> > >> Kim, > >> > >> Thank you for posting this. It's an important step to make. I wanted to > clarify a couple of points: > >> > >> 1. Since this is infrastructure JEP, is the version of JDK which will > undergo such changes going to be some future version or does it apply to > past versions as well? I'm concerned with how we can simplify security > backports to 8u which (I currently assume) is not subject to this change. > > Future version (perhaps as soon as JDK 12). I don't think there is > > any desire to backport this change. And yes, introducing the use of > > new language features will make backports even more interesting than > > they already are. That seems unavoidable if we're going to pursue > > this direction. > > > >> 2. Which versions of GCC do you tentatively consider at this point? > Non-x86 ports may have a problem upgrading to a specific version of GCC > which the shared code will use and may need additional lead time to adjust. > > I think our (ad hoc) testing has been limited to gcc 7.x. But looking > > at the gcc language conformance tables and release notes, gcc 5.x > > might be good enough, and gcc 6.x seems fairly likely sufficient. Of > > course, older versions are more likely to have bugs in some of these > > new features. Updating the minimum supported versions for gcc and > > clang are noted as TBD in the JEP. > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 8 Oct 2018 12:48:57 +0200 > From: Thomas St?fe > To: Kim Barrett > Cc: build-dev , HotSpot Open Source > Developers , Java Core Libs > > Subject: Re: RFC: JEP JDK-8208089: Implement C++14 Language Features > Message-ID: > Go62SyPqo9X1aW9eZeU3gxcBujA at mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. > > HotSpot makes very limited use of namespaces. > > Not really true, we already use them. E.g. in metaspace coding, I used > them to keep the global name space clean and to keep internals > internal. This was met with positive reviews, and it works on all > toolchains, so compiler support should not be a problem. Using > namespaces, we could get slowly replace the "AllStatic" classes, which > are namespaces in all but name. In contrast to classes, namespaces can > be spread over multiple files and compilation units, and allow for > cleaner separation of internal and external coding. > > It also would allow us to get rid the middle-of-header-platform-inclusions: > > For example, today we have: > > [os.hpp] > class os: AllStatic { > .... > (platform independent, outward facing os:: functions) > #include "os_linux.hpp" > >> (Inner class "Linux" with platform specific os functions) > ... > } > > Not only is the inclusion in the middle of a class terrifying, it also > means the shared, outward facing os:: namespace contains class Linux > and lots of platform specific internals. > > With namespaces one could: > > [os.hpp] > namespace os { > .... > (platform independent, outward facing os:: functions) > .... > } > > [os_linux.hpp] > namespace os { > namespace Linux { > (linux specific os functions) > } > } > > I think this is way cleaner, and keeps platform specifics from > including files which only care for the shared os interface. > > -- > > Note that I would prefer forbidding the "using" directive for callers > of namespace functions, but rather force them to spell out the > namespace: > > So, instead of this: > > using os; > jlong m = available_memory(); > > I would prefer this, which is our current practice with AllStatic childs: > > jlong m = os::available_memory(); > > The latter form would keep the code grepable. > > Best Regards, Thomas > On Wed, Oct 3, 2018 at 9:13 PM Kim Barrett wrote: > > > > I've submitted a JEP for > > > > (1) enabling the use of C++14 Language Features when building the JDK, > > > > (2) define a process for deciding and documenting which new features > > can be used or are forbidden in HotSpot code, > > > > (3) provide an initial list of permitted and forbidden new features. > > > > https://bugs.openjdk.java.net/browse/JDK-8208089 > > > > > End of core-libs-dev Digest, Vol 138, Issue 30 > ********************************************** > From kim.barrett at oracle.com Mon Oct 8 18:32:02 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Oct 2018 14:32:02 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> Message-ID: <2C15D9F7-6403-4FCA-806B-263FEF6F0DBA@oracle.com> > On Oct 8, 2018, at 6:48 AM, Thomas St?fe wrote: > > Hi Kim, > > is this JEP only about C++14 features or shall we discuss older > features too? The reason I am asking is that I would like us to > officially endorse namespaces. Not inline namespaces, just plain old > namespaces. I would like to keep this JEP focused on C++11/14 usage. However, it presently describes a process for recording and updating HotSpot usage. I think that process is pretty close to the de facto process, which is rarely used successfully because it's not written down anywhere. We could extract that part of the JEP out, formalize, discuss, agree, and record it. Then you could propose a change and there would be a process for dealing with the proposal, rather than having it slide into oblivion because we don't know how to proceed. And the JEP could be made a bit smaller because it could just refer to that process. From xueming.shen at oracle.com Mon Oct 8 19:01:20 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 08 Oct 2018 12:01:20 -0700 Subject: RFR JDK-8211728, JarFile::versionedStream() does not filter META-INF resources in versioned stream In-Reply-To: References: <5BB795D1.5050200@oracle.com> <6BF08497-B527-44ED-9181-26D2D90A90C1@oracle.com> Message-ID: <5BBBA980.4090602@oracle.com> On 10/6/18, 1:54 AM, Alan Bateman wrote: > > > On 06/10/2018 09:29, Xueming Shen wrote: >> The created mr jar file is being tested in #139 with >> versionedStream(). Without the fix there will be a npe. > Right but it's not testing that the versioned stream doesn't include > META-INF/Foo.class. We need some test for this to be confident that > the versioned stream never includes resources from META-INF in the > versioned section. > > -Alan Hi Alan, webrev has been updated to include the test case of testing if META-INF/Foo.class entry exists in versionedStream() output. http://cr.openjdk.java.net/~sherman/8211728/webrev Thanks, Sherman From kim.barrett at oracle.com Mon Oct 8 19:11:29 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Oct 2018 15:11:29 -0400 Subject: RFR: 8211804: Constant AO_UNUSED_MBZ uses left shift of negative value Message-ID: <6A263A19-38F2-4050-A186-72AA9E2FF9B0@oracle.com> Please review this small change to native code in the (deprecated) jdk.pack module. The existing code triggers a warning when building with gcc with -std=c++11 or -std=c++14. CR: https://bugs.openjdk.java.net/browse/JDK-8211804 Webrev: http://cr.openjdk.java.net/~kbarrett/8211804/open.00/ Testing: Mach5 tier1. From ecki at zusammenkunft.net Mon Oct 8 19:28:24 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 8 Oct 2018 21:28:24 +0200 Subject: AW: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile In-Reply-To: <8b412579-8917-57b3-2383-99c4adecd672@oracle.com> References: <4032e6e5-dfb6-0cd5-3f7b-b6ebca0cb6ea@oracle.com> <8b412579-8917-57b3-2383-99c4adecd672@oracle.com> Message-ID: <5bbbafd8.1c69fb81.5665a.1dd9@mx.google.com> getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does I guess work since the important part is make sure only one thread does the close work, however Publishing the close change to getChannel is a secondary effect of the AtomicBoolean which the new Version does not have(?). I guess the most efficient method would be to only use this as a monitor. While this is not the cleanest usage it is already used, so it does not make it worse? Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 8. Oktober 2018 21:21 An: Claes Redestad; core-libs-dev Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile On 08/10/2018 16:32, Claes Redestad wrote: > Hi, > > aligning the closing of RandomAccessFiles with the implementation in > FileInput-/OutputStream improves startup in a few tests. > > Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 This looks okay to me. -Alan From kim.barrett at oracle.com Mon Oct 8 19:34:04 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Oct 2018 15:34:04 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> Message-ID: <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> > On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov wrote: > > Kim, > > from an ARM port perspective, the stable GCC version is 4.9. The port compiles with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I agree on the overall direction and we'll commit resources to testing it further, but from an ARM port perspective it may happen JDK 12 is a little too optimistic. > > GCC x86 is a lot more stable than for ARM32 and AARCH64. It seems to me that JDK 11 being an LTS might provide an answer to this. JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat "experimental" in that it might require a more recent compiler version that hasn't received as much testing as was done for JDK 11. Similarly, the AIX/ppc platform might not be supported after JDK 11 until an improved version of the relevant compiler becomes available. I don't know if such an approach is acceptable to the community, nor do I know how such a decision might be made. But I think it would be unfortunate if such issues blocked progress in this area. From ecki at zusammenkunft.net Mon Oct 8 19:35:09 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 8 Oct 2018 21:35:09 +0200 Subject: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile In-Reply-To: <5bbbafd8.1c69fb81.5665a.1dd9@mx.google.com> References: <4032e6e5-dfb6-0cd5-3f7b-b6ebca0cb6ea@oracle.com> <8b412579-8917-57b3-2383-99c4adecd672@oracle.com> <5bbbafd8.1c69fb81.5665a.1dd9@mx.google.com> Message-ID: <5bbbb16d.1c69fb81.722fe.efc5@mx.google.com> Hello, just noticed it is probably intended to not be synchronized for the reads (since it is volatile)?. In that case using `this` monitor would also allow to remove the volatile. However not sure if that is good or bad for the Performance (close does not do DCL then anymore, but ist probably not called that often anyway) Gruss Bernd -- http://bernd.eckenfels.net Von: Bernd Eckenfels Gesendet: Montag, 8. Oktober 2018 21:28 An: core-libs-dev Betreff: AW: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile getChannel() Synchronizes only on `this` and `close()` on `closeLock`. It does I guess work since the important part is make sure only one thread does the close work, however Publishing the close change to getChannel is a secondary effect of the AtomicBoolean which the new Version does not have(?). I guess the most efficient method would be to only use this as a monitor. While this is not the cleanest usage it is already used, so it does not make it worse? Gruss Bernd -- http://bernd.eckenfels.net Von: Alan Bateman Gesendet: Montag, 8. Oktober 2018 21:21 An: Claes Redestad; core-libs-dev Betreff: Re: RFR: 8211859: (fc) Avoid initializing AtomicBoolean fromRandomAccessFile On 08/10/2018 16:32, Claes Redestad wrote: > Hi, > > aligning the closing of RandomAccessFiles with the implementation in > FileInput-/OutputStream improves startup in a few tests. > > Webrev: http://cr.openjdk.java.net/~redestad/8211859/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211859 This looks okay to me. -Alan From thomas.stuefe at gmail.com Mon Oct 8 19:42:47 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 8 Oct 2018 21:42:47 +0200 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <2C15D9F7-6403-4FCA-806B-263FEF6F0DBA@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <2C15D9F7-6403-4FCA-806B-263FEF6F0DBA@oracle.com> Message-ID: Hi Kim, On Mon, Oct 8, 2018 at 8:32 PM Kim Barrett wrote: > > > On Oct 8, 2018, at 6:48 AM, Thomas St?fe wrote: > > > > Hi Kim, > > > > is this JEP only about C++14 features or shall we discuss older > > features too? The reason I am asking is that I would like us to > > officially endorse namespaces. Not inline namespaces, just plain old > > namespaces. > > I would like to keep this JEP focused on C++11/14 usage. > > However, it presently describes a process for recording and updating > HotSpot usage. I think that process is pretty close to the de facto > process, which is rarely used successfully because it's not written > down anywhere. > > We could extract that part of the JEP out, formalize, discuss, agree, > and record it. Then you could propose a change and there would be a > process for dealing with the proposal, rather than having it slide > into oblivion because we don't know how to proceed. And the JEP could > be made a bit smaller because it could just refer to that process. > Yes, I would like that. It would be really good to have a process in place to preserve and actually live a consensus about what features we use. We have the Hotspot Style Guide, but we let it become woefully outdated in the face of new developments. I always smile when I read the "Be sparing with templates." remark - that ship has sailed long ago. --- A small remark to the text of your JEP: "As a rule of thumb, permitting features which simplify writing, and especially reading, code should be encouraged." I would like to add to that that simplifying build error analysis should also be a goal. That directly influences programmer productivity. We had some cases in the recent past where we spent a lot of time scratching our heads over walls of template related compiler errors. (not sure how to reach this goal though, since this seems to be a problem inherent in using C++ templates). Best Regards, Thomas From Alan.Bateman at oracle.com Mon Oct 8 20:01:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Oct 2018 21:01:28 +0100 Subject: RFR JDK-8211728,JarFile::versionedStream() does not filter META-INF resources in versioned stream In-Reply-To: <5BBBA980.4090602@oracle.com> References: <5BB795D1.5050200@oracle.com> <6BF08497-B527-44ED-9181-26D2D90A90C1@oracle.com> <5BBBA980.4090602@oracle.com> Message-ID: On 08/10/2018 20:01, Xueming Shen wrote: > On 10/6/18, 1:54 AM, Alan Bateman wrote: >> >> >> On 06/10/2018 09:29, Xueming Shen wrote: >>> The created mr jar file is being tested in #139 with >>> versionedStream(). Without the fix there will be a npe. >> Right but it's not testing that the versioned stream doesn't include >> META-INF/Foo.class. We need some test for this to be confident that >> the versioned stream never includes resources from META-INF in the >> versioned section. >> >> -Alan > Hi Alan, > > webrev has been updated to include the test case of testing if > META-INF/Foo.class > entry exists in versionedStream() output. > > http://cr.openjdk.java.net/~sherman/8211728/webrev Thanks for adding the test, I think it looks good now. -Alan From Alan.Bateman at oracle.com Mon Oct 8 20:10:43 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Oct 2018 21:10:43 +0100 Subject: RFR: 8211804: Constant AO_UNUSED_MBZ uses left shift of negative value In-Reply-To: <6A263A19-38F2-4050-A186-72AA9E2FF9B0@oracle.com> References: <6A263A19-38F2-4050-A186-72AA9E2FF9B0@oracle.com> Message-ID: <2e755e90-6050-d4cf-3000-a066a62ecc0b@oracle.com> On 08/10/2018 20:11, Kim Barrett wrote: > Please review this small change to native code in the (deprecated) > jdk.pack module. The existing code triggers a warning when building > with gcc with -std=c++11 or -std=c++14. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8211804 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8211804/open.00/ > This looks okay to me. -Alan From claes.redestad at oracle.com Mon Oct 8 20:31:40 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 8 Oct 2018 22:31:40 +0200 Subject: RFR: 8211859: (fc) Avoid initializing AtomicBooleanfromRandomAccessFile In-Reply-To: <5bbbb16d.1c69fb81.722fe.efc5@mx.google.com> References: <4032e6e5-dfb6-0cd5-3f7b-b6ebca0cb6ea@oracle.com> <8b412579-8917-57b3-2383-99c4adecd672@oracle.com> <5bbbafd8.1c69fb81.5665a.1dd9@mx.google.com> <5bbbb16d.1c69fb81.722fe.efc5@mx.google.com> Message-ID: <17f4c165-3733-145e-ce99-e264c02d7a8e@oracle.com> Hi, there's been a history of deadlocks when attempting to close() various streams which predates OpenJDK bug and source history, so I believe having close synchronize on this is a bad idea. This move from AtomicBoolean to a volatile for signaling should be semantically neutral and more or less partially back-tracks some more recent changes[1]. You're of course free to attempt a better solution! /Claes [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/655c81c02331 On 2018-10-08 21:35, Bernd Eckenfels wrote: > Hello, > > just noticed it is probably intended to not be synchronized for the reads (since it is volatile)?. > > In that case using `this` monitor would also allow to remove the volatile. However not sure if that is good or bad for the Performance (close does not do DCL then anymore, but ist probably not called that often anyway) > > Gruss > Bernd From aleksei.voitylov at bell-sw.com Mon Oct 8 20:45:07 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 8 Oct 2018 23:45:07 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: Kim, Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. -Aleksei On 08/10/2018 22:34, Kim Barrett wrote: >> On Oct 6, 2018, at 11:07 AM, Aleksei Voitylov wrote: >> >> Kim, >> >> from an ARM port perspective, the stable GCC version is 4.9. The port compiles with stock GCC 7.3 but a lot of testing is required before moving to GCC 7.3. I agree on the overall direction and we'll commit resources to testing it further, but from an ARM port perspective it may happen JDK 12 is a little too optimistic. >> >> GCC x86 is a lot more stable than for ARM32 and AARCH64. > It seems to me that JDK 11 being an LTS might provide an answer to this. > > JDK 12 support for C++11/14 on arm32/aarch64 might be somewhat > "experimental" in that it might require a more recent compiler version > that hasn't received as much testing as was done for JDK 11. > > Similarly, the AIX/ppc platform might not be supported after JDK 11 > until an improved version of the relevant compiler becomes available. > > I don't know if such an approach is acceptable to the community, nor > do I know how such a decision might be made. But I think it would be > unfortunate if such issues blocked progress in this area. > From joe.darcy at oracle.com Mon Oct 8 20:45:15 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 8 Oct 2018 13:45:15 -0700 Subject: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() Message-ID: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> Hello, Please review the changes to address: ??? JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() ??? http://cr.openjdk.java.net/~darcy/8058202.2/ Some discussion and explanation of the changes: The java.lang.reflect.AnnotatedType interface hierarchy was added in JDK 8 to support type annotations (http://openjdk.java.net/projects/type-annotations/) in core reflection. It offers a parallel set of interfaces to the java.lang.reflect.Type family of interfaces added in JDK 5. The separate AnnotatedType interfaces are needed since type annotations are used on type *uses* and not type declarations. For example, it is necessary to be able to model both of the types of the fields foo and bar in a case like: ??? @Nonnull String foo; ??? @Nullable String bar; so clearly the same object cannot be used for both as the annotated type of the fields since the type annotations differ. The implementation classes for the AnnotatedType family used in core reflection are in a single file AnnotatedTypeFactory.java. There are instantiated instances both of the base class AnnotatedTypeBaseImpl and its subclasses which implement the specialized subinterfaces of AnnotatedType for arrays, type variables, etc. The implementation classes do *not* declare equals, hashCode, or toString methods, which the proposed change rectifies. For equals and hashCode, the interfaces do *not* define how the equals relation should be calculated, an omission shared by the Type interfaces. While the default identity-is-equality is correct in some sense, it is not very useful as the objects returned by successive "get annotated return type" calls on the same method object will not be equal. The proposed equals implementations check if the argument object implements the same AnnotatedType subinterface (and makes sure one of the subinterfaces is *not* implemented when determining equality for AnnotatedType implementation objects) and compares the results of corresponding methods. This is analogous to the equals implementations of the Type implementation classes found in the impl classes in the sun.reflect.generics.reflectiveObjects package. The order of annotations is considered significant for equality; this is arguably overly strict, but I didn't think it was worthwhile to form sets of annotations for the purposes of equality comparison in this case. For toString to replicate the source ordering for most kinds of types, the type annotations, if any, occur textually to the left of the text representing the type as in ??? @Nonnull String or more interestingly ??? ??? @Nonnull List the latter meaning "a nonnull list where the list contains strings." However, this pattern is not followed for arrays. The annotated type ??? @Nonnull String[] means "an array of strings where the strings are nonnull" rather than "an array that is nonnull where the array contains strings." The rationale for this is explained in JSR 308 related documents such as: ??? https://checkerframework.org/jsr308/jsr308-faq.html#syntax https://checkerframework.org/jsr308/specification/java-annotation-design.html A multi-dimensional array is represented as an AnnotatedArrayType whose component type is an array type of lower dimension, and so on, bottoming out with a non-array component type. The existing toString output for the Type objects of an array uses VM style notation like "[[Ljava.lang.String" for a 2D string array. This is even less helpful for annotated type objects and therefore toString output in the style usable in source code ("String [] []") will be used instead. Starting from an AnnotatedArrayType object for a 2D array of strings, using the integer value of type annotations the encounter order for the annotations and types is: ??? @TypeAnno(2) String @TypeAnno(0) [] @TypeAnno(1) [] Therefore, for multi-dimensional arrays, the results for the nested dimensions are appended to the in-progress string builder while the results for the non-array component are pre-pended. Thanks, -Joe From kim.barrett at oracle.com Mon Oct 8 21:54:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 8 Oct 2018 17:54:03 -0400 Subject: RFR: 8211804: Constant AO_UNUSED_MBZ uses left shift of negative value In-Reply-To: <2e755e90-6050-d4cf-3000-a066a62ecc0b@oracle.com> References: <6A263A19-38F2-4050-A186-72AA9E2FF9B0@oracle.com> <2e755e90-6050-d4cf-3000-a066a62ecc0b@oracle.com> Message-ID: <82E71405-BEE3-4B91-B9CF-137E58043734@oracle.com> > On Oct 8, 2018, at 4:10 PM, Alan Bateman wrote: > > On 08/10/2018 20:11, Kim Barrett wrote: >> Please review this small change to native code in the (deprecated) >> jdk.pack module. The existing code triggers a warning when building >> with gcc with -std=c++11 or -std=c++14. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8211804 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8211804/open.00/ >> > This looks okay to me. > > -Alan Thanks! From joe.darcy at oracle.com Mon Oct 8 23:28:42 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 08 Oct 2018 16:28:42 -0700 Subject: are there src git repositories for javase In-Reply-To: <5bbb95e4.1c69fb81.33a1d.9a37@mx.google.com> References: <5bbb95e4.1c69fb81.33a1d.9a37@mx.google.com> Message-ID: <5BBBE82A.9000606@oracle.com> The Skara project (http://mail.openjdk.java.net/mailman/listinfo/skara-dev) has a JDK 12 mirror at https://github.com/Project-Skara/jdk/ -Joe On 10/8/2018 10:37 AM, Bernd Eckenfels wrote: > Hello, > > there is no official/canonical one as far as I know, but there are a few (externally maintained) Repos which are produced by mirroring the HG trees. > > I cannot endores any of them, but in GitHub you find: > > Older versions: https://github.com/openjdk-mirror > SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk > Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk > AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11 > > Gruss > Bernd > > BTW: ist not a good idea to respond to Digest mails, it messes up the threading and the subject From matcdac at gmail.com Tue Oct 9 04:59:25 2018 From: matcdac at gmail.com (Prakhar Makhija) Date: Tue, 9 Oct 2018 10:29:25 +0530 Subject: are there src git repositories for javase In-Reply-To: <5BBBE82A.9000606@oracle.com> References: <5bbb95e4.1c69fb81.33a1d.9a37@mx.google.com> <5BBBE82A.9000606@oracle.com> Message-ID: Thanks Joseph, I'll check Skara. I found one reference of "hgForest.sh" I presume it is for cloning / pulling the jdk src projects, perhaps the hg trees you are mentioning Kindly tell me the process to clone the hg trees Please also help me out with the development process here Every time is there a separate repository created, for developing a new major version of Java? - Prakhar On Tue 9 Oct, 2018, 4:59 AM Joseph D. Darcy, wrote: > The Skara project > (http://mail.openjdk.java.net/mailman/listinfo/skara-dev) has a JDK 12 > mirror at > > https://github.com/Project-Skara/jdk/ > > -Joe > > On 10/8/2018 10:37 AM, Bernd Eckenfels wrote: > > Hello, > > > > there is no official/canonical one as far as I know, but there are a few > (externally maintained) Repos which are produced by mirroring the HG trees. > > > > I cannot endores any of them, but in GitHub you find: > > > > Older versions: https://github.com/openjdk-mirror > > SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk > > Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk > > AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11 > > > > Gruss > > Bernd > > > > BTW: ist not a good idea to respond to Digest mails, it messes up the > threading and the subject > > From david.holmes at oracle.com Tue Oct 9 05:07:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Oct 2018 15:07:57 +1000 Subject: are there src git repositories for javase In-Reply-To: References: <5bbb95e4.1c69fb81.33a1d.9a37@mx.google.com> <5BBBE82A.9000606@oracle.com> Message-ID: <4638bc16-5f92-d9be-051f-8f04c03c21e1@oracle.com> Hi Prakhar, It's a bit late for Joe so allow me ... On 9/10/2018 2:59 PM, Prakhar Makhija wrote: > Thanks Joseph, I'll check Skara. > > I found one reference of "hgForest.sh" > I presume it is for cloning / pulling the jdk src projects, perhaps the hg > trees you are mentioning A leftover from when we had multiple hg repositories forming a forest to get the complete sources of the OpenJDK. No longer needed. > Kindly tell me the process to clone the hg trees hg clone https://hg.openjdk.java.net/jdk/jdk > Please also help me out with the development process here > > Every time is there a separate repository created, for developing a new > major version of Java? The jdk/jdk repository is used for all ongoing development. The actual releases then get forked off of that. See also: http://openjdk.java.net/projects/jdk/ David > - Prakhar > > On Tue 9 Oct, 2018, 4:59 AM Joseph D. Darcy, wrote: > >> The Skara project >> (http://mail.openjdk.java.net/mailman/listinfo/skara-dev) has a JDK 12 >> mirror at >> >> https://github.com/Project-Skara/jdk/ >> >> -Joe >> >> On 10/8/2018 10:37 AM, Bernd Eckenfels wrote: >>> Hello, >>> >>> there is no official/canonical one as far as I know, but there are a few >> (externally maintained) Repos which are produced by mirroring the HG trees. >>> >>> I cannot endores any of them, but in GitHub you find: >>> >>> Older versions: https://github.com/openjdk-mirror >>> SAP maintained: https://github.com/SAP/SapMachine/tree/jdk/jdk >>> Ojdkbuild: https://github.com/ojdkbuild/upstream_jdk >>> AdoptOpenJDK: https://github.com/AdoptOpenJDK/openjdk-jdk11 >>> >>> Gruss >>> Bernd >>> >>> BTW: ist not a good idea to respond to Digest mails, it messes up the >> threading and the subject >> >> From chris.hegarty at oracle.com Tue Oct 9 10:20:56 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 9 Oct 2018 11:20:56 +0100 Subject: RFR [12] 8211920: Close server socket and cleanups in test/jdk/javax/naming/module/RunBasic.java Message-ID: <5E09EC70-3500-40D4-B19C-2BF8238B8169@oracle.com> When the test fails sometimes the output is truncated, or even absent, as the test's sub-process does not complete. This may happen if the client-side encounters an issue and leaves the non-daemon server-side thread blocked in accept. The test should close the server socket when the client-side completes. This will enable the "real" error to be seen. [ thanks to Chris Yin, for finding this! ] http://cr.openjdk.java.net/~chegar/8211920.00/ While here, and since the test has been seen to fail occasionally, in the more distant past, I took the liberty of changing the binding of the server socket. It now follows the more stable pattern of using a specific interface. -Chris. P.S. the test remains on the ProblemList since it still fails, but now we can see why. 8211921 tracks the underlying issue in java.lang.invoke From daniel.fuchs at oracle.com Tue Oct 9 10:31:49 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 9 Oct 2018 11:31:49 +0100 Subject: RFR [12] 8211920: Close server socket and cleanups in test/jdk/javax/naming/module/RunBasic.java In-Reply-To: <5E09EC70-3500-40D4-B19C-2BF8238B8169@oracle.com> References: <5E09EC70-3500-40D4-B19C-2BF8238B8169@oracle.com> Message-ID: <5bbebf9a-1d26-5086-1517-41cda8bd880a@oracle.com> Looks good to me Chris! Push it! Kudos to Chris & Chris ;-) best regards, -- daniel On 09/10/2018 11:20, Chris Hegarty wrote: > When the test fails sometimes the output is truncated, or even absent, > as the test's sub-process does not complete. This may happen if the > client-side encounters an issue and leaves the non-daemon server-side > thread blocked in accept. The test should close the server socket when > the client-side completes. This will enable the "real" error to be seen. > [ thanks to Chris Yin, for finding this! ] > > http://cr.openjdk.java.net/~chegar/8211920.00/ > > While here, and since the test has been seen to fail occasionally, in > the more distant past, I took the liberty of changing the binding of the > server socket. It now follows the more stable pattern of using a > specific interface. > > -Chris. > > P.S. the test remains on the ProblemList since it still fails, but now > we can see why. 8211921 tracks the underlying issue in java.lang.invoke > From matthias.baesken at sap.com Tue Oct 9 11:40:16 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Oct 2018 11:40:16 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Message-ID: Hello, please review the following change . It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. bug and webrev : https://bugs.openjdk.java.net/browse/JDK-8211752 http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ Thanks, Matthias From Alan.Bateman at oracle.com Tue Oct 9 12:05:40 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 Oct 2018 13:05:40 +0100 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: <0694c372-5490-bd34-d3a7-ae4b34db7a07@oracle.com> On 09/10/2018 12:40, Baesken, Matthias wrote: > Hello, please review the following change . > It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. > For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. > > bug and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8211752 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ > This patch will need security review as it leaks sensitive information into exception messages. It may be that it needs to predicated on a security property. If this proposal goes ahead then the implementation needs cleanup. The upcall from the JNU_* function to jdk.internal.util is a messy I think we need to look at alternative to avoid this. Also the patch needs to be re-formatted to get it consistent with the existing code (e.g. overly long 150 character lines need to be trimmed down to be consistent with the existing code for example). -Alan From matthias.baesken at sap.com Tue Oct 9 12:12:00 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Oct 2018 12:12:00 +0000 Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: Hello, Alan commented on it : * This proposal will require a security review as it leaks sensitive information into exceptions. So I forward it to security-dev as well. If needed, we might use something similar to JDK-8207768 where a category has been added for enhanced exception messages to the java.security file . Best regards, Matthias From: Baesken, Matthias Sent: Dienstag, 9. Oktober 2018 13:40 To: core-libs-dev at openjdk.java.net Cc: Langer, Christoph ; Lindenmaier, Goetz Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Hello, please review the following change . It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. bug and webrev : https://bugs.openjdk.java.net/browse/JDK-8211752 http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ Thanks, Matthias From chris.w.dennis at gmail.com Tue Oct 9 14:48:02 2018 From: chris.w.dennis at gmail.com (Chris Dennis) Date: Tue, 9 Oct 2018 10:48:02 -0400 Subject: Collectors.Characteristics.IDENTITY_FINISH Spec Clarification Message-ID: <1D1F47D6-061F-495A-83DB-597DAB824928@gmail.com> I?m attempting to clarify the meaning/intent of the language in the specification of the identity-finish characteristic of collectors. The javadoc reads: Indicates that the finisher function is the identity function and can be elided. If set, it must be the case that an unchecked cast from A to R will succeed. In the following code the second sentence clearly indicates that the second cast from A to R must succeed. What I?m trying to confirm however is that the first sentence is intended to require that the finisher is a true identity function, so the result of the collector must be one of the instances created through the supplier, and that therefore the cast from R to A is also safe. public static void main(String[] args) { Stream a = Stream.of("foo", "bar", "baz"); Stream b = Stream.of("alice", "bob", "eve"); System.out.println(collect(Stream.of(a, b), partitioningBy(s -> s.startsWith("b"), toList()))); } public static R collect(Stream> streams, Collector collector) { if (collector.characteristics().contains(Collector.Characteristics.IDENTITY_FINISH)) { return streams.map(s -> s.collect(collector)) // Indicates that the finisher function is the identity function and can be elided. .map(r -> (A) r) .reduce(collector.combiner()) // If set, it must be the case that an unchecked cast from A to R will succeed. .map(a -> (R) a) .orElse(Stream.empty().collect(collector)); } else { return streams.flatMap(identity()).collect(collector); } } Thoughts, opinions? Thanks, Chris Dennis From forax at univ-mlv.fr Tue Oct 9 15:20:44 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 9 Oct 2018 17:20:44 +0200 (CEST) Subject: How to detect that a VM was started with --enable-preview ? Message-ID: <1901969900.345451.1539098444785.JavaMail.zimbra@u-pem.fr> Hi all, it seems that there is no simple way* to detect if a VM is started with --enable-preview or not ? R?mi * apart using JMX to sniff the VM command line with ManagementFactory.getRuntimeMXBean().getInputArguments() From Roger.Riggs at oracle.com Tue Oct 9 15:22:58 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 9 Oct 2018 11:22:58 -0400 Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: Hi Matthias, I don't think this is worth the complex implementation. The caller already has access to user.dir property and it is not used by canonicalize0 so I think it should be dropped from the exception text. In what cases, does canonicalize0 use the native CWD? The native CWD should not be needed, the caller should have filled in user.dir where needed. The second native call to get the native cwd doesn't pull its weight. Without the need for user.dir, the exception message can be created entirely in native without needing the upcall. The pathname is already known to the caller and the caller can modify or replace the exception. There should be a solution that does not require an upcall, and moves any extra work to the caller of canonicalize0. Please take a second look at the implementation, Roger On 10/09/2018 08:12 AM, Baesken, Matthias wrote: > Hello, Alan commented on it : > > > * This proposal will require a security review as it leaks sensitive information into exceptions. > > So I forward it to security-dev as well. > > If needed, we might use something similar to JDK-8207768 where a category has been added for enhanced exception messages to the > java.security file . > > Best regards, Matthias > > From: Baesken, Matthias > Sent: Dienstag, 9. Oktober 2018 13:40 > To: core-libs-dev at openjdk.java.net > Cc: Langer, Christoph ; Lindenmaier, Goetz > Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue > > > Hello, please review the following change . > It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. > For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. > > bug and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8211752 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ > > Thanks, Matthias -- Thanks, Roger From sean.coffey at oracle.com Tue Oct 9 15:27:41 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 9 Oct 2018 16:27:41 +0100 Subject: How to detect that a VM was started with --enable-preview ? In-Reply-To: <1901969900.345451.1539098444785.JavaMail.zimbra@u-pem.fr> References: <1901969900.345451.1539098444785.JavaMail.zimbra@u-pem.fr> Message-ID: would `jcmd VM.info | grep jvm_args:` help ? or `jcmd VM.command_line` regards, Sean. On 09/10/2018 16:20, Remi Forax wrote: > Hi all, > it seems that there is no simple way* to detect if a VM is started with --enable-preview or not ? > > R?mi > * apart using JMX to sniff the VM command line with ManagementFactory.getRuntimeMXBean().getInputArguments() From forax at univ-mlv.fr Tue Oct 9 15:47:28 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 9 Oct 2018 17:47:28 +0200 (CEST) Subject: How to detect that a VM was started with --enable-preview ? In-Reply-To: References: <1901969900.345451.1539098444785.JavaMail.zimbra@u-pem.fr> Message-ID: <1410249162.348367.1539100048476.JavaMail.zimbra@u-pem.fr> Ah, sorry, i mean detecting if the VM was started with --enable-preview when you are running a code on that VM. Basically, i want to programmatically know if i can generate and load a class with the minor version equals to 65535 on that VM or not ? cheers, R?mi ----- Mail original ----- > De: "Se?n Coffey" > ?: "Remi Forax" , "core-libs-dev" > Envoy?: Mardi 9 Octobre 2018 17:27:41 > Objet: Re: How to detect that a VM was started with --enable-preview ? > would `jcmd VM.info | grep jvm_args:` help ? or `jcmd > VM.command_line` > > regards, > Sean. > > On 09/10/2018 16:20, Remi Forax wrote: >> Hi all, >> it seems that there is no simple way* to detect if a VM is started with >> --enable-preview or not ? >> >> R?mi >> * apart using JMX to sniff the VM command line with > > ManagementFactory.getRuntimeMXBean().getInputArguments() From joel.borggren.franck at gmail.com Tue Oct 9 18:00:48 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Tue, 9 Oct 2018 20:00:48 +0200 Subject: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() In-Reply-To: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> Message-ID: Hi Joe, Good to see this happening. In general looks good to me, a few nits below. AnnotatedTypeBaseImpl contains comments indicating from which superclass or interface the overridden methods comes. I'd either add // Object at line 207 or delete line 145 and 177 for consistency. Even though this isn't performance critical by far the allocation at line 215 still bugs me a bit given that the common case will most certainly be no annotations. Why the inverted logic line 250-253, IIRC you should be able to test if it is an AnnotatedBaseTypeImpl, or? For equalsTypeAndAnnotations and baseHashCode lines 232-244 equals test for owner type equality while hashcode doesn't include owner type. I must confess I no longer remember the equals-hashCode contract but I assume this is intentional. Cheers /Joel On Mon, Oct 8, 2018 at 10:45 PM joe darcy wrote: > > Hello, > > Please review the changes to address: > > JDK-8058202 : AnnotatedType implementations don't override > toString(), equals(), hashCode() > http://cr.openjdk.java.net/~darcy/8058202.2/ > > Some discussion and explanation of the changes: > > The java.lang.reflect.AnnotatedType interface hierarchy was added in JDK > 8 to support type annotations > (http://openjdk.java.net/projects/type-annotations/) in core reflection. > It offers a parallel set of interfaces to the java.lang.reflect.Type > family of interfaces added in JDK 5. The separate AnnotatedType > interfaces are needed since type annotations are used on type *uses* and > not type declarations. For example, it is necessary to be able to model > both of the types of the fields foo and bar in a case like: > > @Nonnull String foo; > @Nullable String bar; > > so clearly the same object cannot be used for both as the annotated type > of the fields since the type annotations differ. > > The implementation classes for the AnnotatedType family used in core > reflection are in a single file AnnotatedTypeFactory.java. There are > instantiated instances both of the base class AnnotatedTypeBaseImpl and > its subclasses which implement the specialized subinterfaces of > AnnotatedType for arrays, type variables, etc. > > The implementation classes do *not* declare equals, hashCode, or > toString methods, which the proposed change rectifies. > > For equals and hashCode, the interfaces do *not* define how the equals > relation should be calculated, an omission shared by the Type > interfaces. While the default identity-is-equality is correct in some > sense, it is not very useful as the objects returned by successive "get > annotated return type" calls on the same method object will not be equal. > > The proposed equals implementations check if the argument object > implements the same AnnotatedType subinterface (and makes sure one of > the subinterfaces is *not* implemented when determining equality for > AnnotatedType implementation objects) and compares the results of > corresponding methods. This is analogous to the equals implementations > of the Type implementation classes found in the impl classes in the > sun.reflect.generics.reflectiveObjects package. > > The order of annotations is considered significant for equality; this is > arguably overly strict, but I didn't think it was worthwhile to form > sets of annotations for the purposes of equality comparison in this case. > > For toString to replicate the source ordering for most kinds of types, > the type annotations, if any, occur textually to the left of the text > representing the type as in > > @Nonnull String > > or more interestingly > > @Nonnull List > > the latter meaning "a nonnull list where the list contains strings." > > However, this pattern is not followed for arrays. The annotated type > > @Nonnull String[] > > means "an array of strings where the strings are nonnull" rather than > "an array that is nonnull where the array contains strings." The > rationale for this is explained in JSR 308 related documents such as: > > https://checkerframework.org/jsr308/jsr308-faq.html#syntax > https://checkerframework.org/jsr308/specification/java-annotation-design.html > > A multi-dimensional array is represented as an AnnotatedArrayType whose > component type is an array type of lower dimension, and so on, bottoming > out with a non-array component type. The existing toString output for > the Type objects of an array uses VM style notation like > "[[Ljava.lang.String" for a 2D string array. This is even less helpful > for annotated type objects and therefore toString output in the style > usable in source code ("String [] []") will be used instead. Starting > from an AnnotatedArrayType object for a 2D array of strings, using the > integer value of type annotations the encounter order for the > annotations and types is: > > @TypeAnno(2) String @TypeAnno(0) [] @TypeAnno(1) [] > > Therefore, for multi-dimensional arrays, the results for the nested > dimensions are appended to the in-progress string builder while the > results for the non-array component are pre-pended. > > Thanks, > > -Joe > From mandy.chung at oracle.com Tue Oct 9 18:09:46 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 Oct 2018 11:09:46 -0700 Subject: How to detect that a VM was started with --enable-preview ? In-Reply-To: <1410249162.348367.1539100048476.JavaMail.zimbra@u-pem.fr> References: <1901969900.345451.1539098444785.JavaMail.zimbra@u-pem.fr> <1410249162.348367.1539100048476.JavaMail.zimbra@u-pem.fr> Message-ID: I think this RFE is what you are looking for: ??? https://bugs.openjdk.java.net/browse/JDK-8194138 Mandy On 10/9/18 8:47 AM, forax at univ-mlv.fr wrote: > Ah, sorry, > i mean detecting if the VM was started with --enable-preview when you are running a code on that VM. > > Basically, i want to programmatically know if i can generate and load a class with the minor version equals to 65535 on that VM or not ? > > cheers, > R?mi > > ----- Mail original ----- >> De: "Se?n Coffey" >> ?: "Remi Forax" , "core-libs-dev" >> Envoy?: Mardi 9 Octobre 2018 17:27:41 >> Objet: Re: How to detect that a VM was started with --enable-preview ? >> would `jcmd VM.info | grep jvm_args:` help ? or `jcmd >> VM.command_line` >> >> regards, >> Sean. >> >> On 09/10/2018 16:20, Remi Forax wrote: >>> Hi all, >>> it seems that there is no simple way* to detect if a VM is started with >>> --enable-preview or not ? >>> >>> R?mi >>> * apart using JMX to sniff the VM command line with >>> ManagementFactory.getRuntimeMXBean().getInputArguments() From forax at univ-mlv.fr Tue Oct 9 18:47:18 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 9 Oct 2018 20:47:18 +0200 (CEST) Subject: How to detect that a VM was started with --enable-preview ? In-Reply-To: References: <1901969900.345451.1539098444785.JavaMail.zimbra@u-pem.fr> <1410249162.348367.1539100048476.JavaMail.zimbra@u-pem.fr> Message-ID: <1695683364.368178.1539110838059.JavaMail.zimbra@u-pem.fr> > De: "mandy chung" > ?: "Remi Forax" , "Se?n Coffey" > Cc: "core-libs-dev" > Envoy?: Mardi 9 Octobre 2018 20:09:46 > Objet: Re: How to detect that a VM was started with --enable-preview ? > I think this RFE is what you are looking for: > [ https://bugs.openjdk.java.net/browse/JDK-8194138 | > https://bugs.openjdk.java.net/browse/JDK-8194138 ] > Mandy yes ! Having the feature version of the current runtime (Runtime.version().feature()) already give me the highest major version of the classfile that the current VM can recognize, but not the minor one. thanks, R?mi > On 10/9/18 8:47 AM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >> Ah, sorry, >> i mean detecting if the VM was started with --enable-preview when you are >> running a code on that VM. >> Basically, i want to programmatically know if i can generate and load a class >> with the minor version equals to 65535 on that VM or not ? >> cheers, >> R?mi >> ----- Mail original ----- >>> De: "Se?n Coffey" [ mailto:sean.coffey at oracle.com | ] >>> ?: "Remi Forax" [ mailto:forax at univ-mlv.fr | ] , >>> "core-libs-dev" [ mailto:core-libs-dev at openjdk.java.net | >>> ] Envoy?: Mardi 9 Octobre 2018 17:27:41 >>> Objet: Re: How to detect that a VM was started with --enable-preview ? >>> would `jcmd VM.info | grep jvm_args:` help ? or `jcmd >>> VM.command_line` >>> regards, >>> Sean. >>> On 09/10/2018 16:20, Remi Forax wrote: >>>> Hi all, >>>> it seems that there is no simple way* to detect if a VM is started with >>>> --enable-preview or not ? >>>> R?mi >>>> * apart using JMX to sniff the VM command line with >>>> ManagementFactory.getRuntimeMXBean().getInputArguments() From xueming.shen at oracle.com Tue Oct 9 19:07:14 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 09 Oct 2018 12:07:14 -0700 Subject: RFR JDK-8211880,Broken links in java.util.jar Message-ID: <5BBCFC62.2070706@oracle.com> Hi, Please help review the doc-link-only update for JDK-8211880 issue: https://bugs.openjdk.java.net/browse/JDK-8211880 webrev: http://cr.openjdk.java.net/~sherman/8211880/webrev/ Thanks, Sherman From martinrb at google.com Tue Oct 9 19:14:05 2018 From: martinrb at google.com (Martin Buchholz) Date: Tue, 9 Oct 2018 12:14:05 -0700 Subject: RFR JDK-8211880,Broken links in java.util.jar In-Reply-To: <5BBCFC62.2070706@oracle.com> References: <5BBCFC62.2070706@oracle.com> Message-ID: LGTM On Tue, Oct 9, 2018 at 12:07 PM, Xueming Shen wrote: > Hi, > > Please help review the doc-link-only update for JDK-8211880 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211880 > webrev: http://cr.openjdk.java.net/~sherman/8211880/webrev/ > > Thanks, > Sherman > From mandy.chung at oracle.com Tue Oct 9 19:14:38 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 Oct 2018 12:14:38 -0700 Subject: RFR JDK-8211880,Broken links in java.util.jar In-Reply-To: <5BBCFC62.2070706@oracle.com> References: <5BBCFC62.2070706@oracle.com> Message-ID: <24971a6b-2f15-0586-5e1e-e4d81f67369f@oracle.com> +1 Mandy On 10/9/18 12:07 PM, Xueming Shen wrote: > Hi, > > Please help review the doc-link-only update for JDK-8211880 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211880 > webrev: http://cr.openjdk.java.net/~sherman/8211880/webrev/ > > Thanks, > Sherman From Alan.Bateman at oracle.com Tue Oct 9 19:14:38 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 Oct 2018 20:14:38 +0100 Subject: RFR JDK-8211880,Broken links in java.util.jar In-Reply-To: <5BBCFC62.2070706@oracle.com> References: <5BBCFC62.2070706@oracle.com> Message-ID: <98caf19f-9a73-dc08-6906-3b21ae6f8d77@oracle.com> On 09/10/2018 20:07, Xueming Shen wrote: > Hi, > > Please help review the doc-link-only update for JDK-8211880 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211880 > webrev: http://cr.openjdk.java.net/~sherman/8211880/webrev/ This looks okay. -Alan From lance.andersen at oracle.com Tue Oct 9 19:21:15 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 Oct 2018 15:21:15 -0400 Subject: RFR JDK-8211880,Broken links in java.util.jar In-Reply-To: <5BBCFC62.2070706@oracle.com> References: <5BBCFC62.2070706@oracle.com> Message-ID: <70CBE589-71A5-4AE5-8C94-917552708340@oracle.com> +1 > On Oct 9, 2018, at 3:07 PM, Xueming Shen wrote: > > Hi, > > Please help review the doc-link-only update for JDK-8211880 > > issue: https://bugs.openjdk.java.net/browse/JDK-8211880 > webrev: http://cr.openjdk.java.net/~sherman/8211880/webrev/ > > Thanks, > Sherman Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From iris.clark at oracle.com Tue Oct 9 19:22:02 2018 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 9 Oct 2018 19:22:02 +0000 (UTC) Subject: RFR JDK-8211880,Broken links in java.util.jar In-Reply-To: <5BBCFC62.2070706@oracle.com> References: <5BBCFC62.2070706@oracle.com> Message-ID: <3f076d16-ab63-4aac-b1ba-73c5c02a8125@default> Hi, Sherman. > issue: https://bugs.openjdk.java.net/browse/JDK-8211880 > webrev: http://cr.openjdk.java.net/~sherman/8211880/webrev/ Looks good. iris From kim.barrett at oracle.com Tue Oct 9 23:17:24 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Oct 2018 19:17:24 -0400 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound Message-ID: [I'm not sure whether core-libs is the right list for java.desktop changes.] Please review this trivial fix of a build failure on MacOSX when compiling with C++11/14 enabled. An int value is being used in an initializer where an unsigned int is needed, which is not permitted since C++11. The solution taken is to cast the value in the initializer. A "better" solution would be to change the type of the value, but that has substantial fannout because there are many places in our code where signed ints were used instead of the unsigned ints used by the underlying MacOSX framework. CR: https://bugs.openjdk.java.net/browse/JDK-8211962 Webrev: http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ Testing: mach5 tier1 on MacOSX (really just verifying it builds). From philip.race at oracle.com Tue Oct 9 23:22:01 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 09 Oct 2018 16:22:01 -0700 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound In-Reply-To: References: Message-ID: <5BBD3819.8080607@oracle.com> Wrong list. Try over on sound-dev, -phil. On 10/9/18, 4:17 PM, Kim Barrett wrote: > [I'm not sure whether core-libs is the right list for java.desktop changes.] > > Please review this trivial fix of a build failure on MacOSX when > compiling with C++11/14 enabled. An int value is being used in an > initializer where an unsigned int is needed, which is not permitted > since C++11. The solution taken is to cast the value in the > initializer. A "better" solution would be to change the type of the > value, but that has substantial fannout because there are many places > in our code where signed ints were used instead of the unsigned ints > used by the underlying MacOSX framework. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8211962 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ > > Testing: > mach5 tier1 on MacOSX (really just verifying it builds). > > From brian.burkhalter at oracle.com Tue Oct 9 23:22:55 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 Oct 2018 16:22:55 -0700 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound In-Reply-To: References: Message-ID: <20B87A5C-A1E9-4B11-9C79-3EFC740421BB@oracle.com> Looping in 2d-dev. > On Oct 9, 2018, at 4:17 PM, Kim Barrett wrote: > > [I'm not sure whether core-libs is the right list for java.desktop changes.] > > Please review this trivial fix of a build failure on MacOSX when > compiling with C++11/14 enabled. An int value is being used in an > initializer where an unsigned int is needed, which is not permitted > since C++11. The solution taken is to cast the value in the > initializer. A "better" solution would be to change the type of the > value, but that has substantial fannout because there are many places > in our code where signed ints were used instead of the unsigned ints > used by the underlying MacOSX framework. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8211962 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ > > Testing: > mach5 tier1 on MacOSX (really just verifying it builds). > > From jonathan.gibbons at oracle.com Tue Oct 9 23:50:00 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 09 Oct 2018 16:50:00 -0700 Subject: RFR: JDK-8211952: Broken links in java.time API Message-ID: <5BBD3EA8.70208@oracle.com> Please review a scripted edit to fix references to the serialized-form.html file in java.time.** classes. The edits were made by the following command, to replace the leading `../` in a reference to serialized-form.html with `{@docRoot}`. sed --in-place -e 's|"[./]*/serialized-form.html|"{@docRoot}/serialized-form.html|g' $(grep -rl -F '../serialized-form' open/src/java.base/share/classes/java/time) I've posted a webrev, but you may find it easier to just scan through the patch itself. JBS: https://bugs.openjdk.java.net/browse/JDK-8211952 Webrev: http://cr.openjdk.java.net/~jjg/8211952/webrev.00/ -- Jon From lance.andersen at oracle.com Tue Oct 9 23:55:58 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 Oct 2018 19:55:58 -0400 Subject: RFR: JDK-8211952: Broken links in java.time API In-Reply-To: <5BBD3EA8.70208@oracle.com> References: <5BBD3EA8.70208@oracle.com> Message-ID: Patch looks fine Jon > On Oct 9, 2018, at 7:50 PM, Jonathan Gibbons wrote: > > Please review a scripted edit to fix references to the serialized-form.html file in java.time.** classes. > > The edits were made by the following command, to replace the leading `../` in a reference to serialized-form.html with `{@docRoot}`. > > sed --in-place -e 's|"[./]*/serialized-form.html|"{@docRoot}/serialized-form.html|g' $(grep -rl -F '../serialized-form' open/src/java.base/share/classes/java/time) > > I've posted a webrev, but you may find it easier to just scan through the patch itself. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211952 > Webrev: http://cr.openjdk.java.net/~jjg/8211952/webrev.00/ > > -- Jon Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From kim.barrett at oracle.com Wed Oct 10 01:24:35 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 9 Oct 2018 21:24:35 -0400 Subject: RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound In-Reply-To: <5BBD3819.8080607@oracle.com> References: <5BBD3819.8080607@oracle.com> Message-ID: <2D98E070-6426-4747-984B-5E71F3C00F45@oracle.com> > On Oct 9, 2018, at 7:22 PM, Philip Race wrote: > > Wrong list. Try over on sound-dev, Thanks. I didn?t notice that one when looking through the list of lists. > > -phil. > > On 10/9/18, 4:17 PM, Kim Barrett wrote: >> [I'm not sure whether core-libs is the right list for java.desktop changes.] >> >> Please review this trivial fix of a build failure on MacOSX when >> compiling with C++11/14 enabled. An int value is being used in an >> initializer where an unsigned int is needed, which is not permitted >> since C++11. The solution taken is to cast the value in the >> initializer. A "better" solution would be to change the type of the >> value, but that has substantial fannout because there are many places >> in our code where signed ints were used instead of the unsigned ints >> used by the underlying MacOSX framework. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8211962 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ >> >> Testing: >> mach5 tier1 on MacOSX (really just verifying it builds). From amaembo at gmail.com Wed Oct 10 03:33:33 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Wed, 10 Oct 2018 10:33:33 +0700 Subject: Convert old-style array declarations (was: Re: ByteArrayOutputStream should not have a new writeBytes method in Java) In-Reply-To: References: <8fadc9eb-eab0-a5fe-6d08-658f0e07f30a@oracle.com> Message-ID: Hello! So the conversion was successfully performed for client components: https://bugs.openjdk.java.net/browse/JDK-8211300 http://hg.openjdk.java.net/jdk/client/rev/2e330da7cbf4 https://bugs.openjdk.java.net/browse/JDK-8211693 http://hg.openjdk.java.net/jdk/client/rev/de9486d74a74 Now we can move to something else. Let's limit the array declaration conversion to core-libs for now. I created an issue JDK-8211981. For me the problem now is to determine which modules belong to core-libs. I tried to find this information. The only thing I found is this apparently outdated page: http://openjdk.java.net/groups/core-libs/ It lists packages, but not modules, and links to Java 8 spec. Probably it's time to update it? To me it seems that the following modules belong to core-libs: java.base, java.naming, java.rmi, java.scripting, java.sql, java.sql.rowset, java.xml, java.xml.crypto, jdk.unsupported, jdk.xml.dom. Anything missing or added by mistake? With best regards, Tagir Valeev. On Mon, Oct 1, 2018 at 10:40 AM Tagir Valeev wrote: > > Hello! > > Ok, let's start with smaller thing which is java.desktop. Created a > JBS issue and posted a patch here: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-October/009486.html > > Jonathan, > > > Although cleanup like this is nice, I'll give a word of warning that pervasive > > changes like that can sometimes cause difficulties when there are lots of > > changes in code which is undergoing different lines of development in different > > branches or repos. If nothing else, I'd consider doing it on a per-component > > or per-module basis. > > I'm not sure I have enough time to post 70+ reviews for every module > and track all of them. My volunteering abilities are quite limited :-) > I think I can manage up to 3-4 separate changesets including already > posted java.desktop change. If you have suggestions on how to split > this to several big parts, you are welcome (I don't know how > "components" are mapped to modules, probably components are big > enough?). Or probably we can cover only part of modules for now and > wait for the next volunteer to pick up this. > > With best regards, > Tagir Valeev. > > > On Sat, Sep 29, 2018 at 5:41 AM Sergey Bylokhov > wrote: > > > > I can review the changes in java.desktop, please use these email alias > > awt-dev/2d-dev/swing-dev. > > > > On 28/09/2018 04:13, Alan Bateman wrote: > > > As regards doing the entire source base then I think that would be good. > > > Due to the complexity of testing, changes to the java.desktop module are > > > pushed to jdk/client repo rather than jdk/jdk so if it's not too awkward > > > then it might be helper if the patch for java.desktop were a separate > > > change that gets pushed to jdk/client rather than jdk/jdk. > > > > > > -- > > Best regards, Sergey. From ying.z.zhou at oracle.com Wed Oct 10 06:19:41 2018 From: ying.z.zhou at oracle.com (Ying Zhou) Date: Wed, 10 Oct 2018 14:19:41 +0800 Subject: [12]RFR of JDK-8210403:Refactor java.util.Locale:i18n shell tests to plain java tests Message-ID: <46debed1-8c0f-962b-f266-2aef25aa35d6@oracle.com> Hello, test/java/util/Locale/LocaleCategory.sh test/java/util/Locale/LocaleProviders.sh Please review this patch to refactor above shell script tests to java. bug: https://bugs.openjdk.java.net/browse/JDK-8210403 webrev: http://cr.openjdk.java.net/~dzhou/8210403/webrev.00/ Thanks, Daisy From joe.darcy at oracle.com Wed Oct 10 06:26:47 2018 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 9 Oct 2018 23:26:47 -0700 Subject: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() In-Reply-To: References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> Message-ID: Hi Joel, Thanks for the review; slightly revised version at ??? http://cr.openjdk.java.net/~darcy/8058202.3/ Comments below. On 10/9/2018 11:00 AM, Joel Borggr?n-Franck wrote: > Hi Joe, > > Good to see this happening. In general looks good to me, a few nits below. > > AnnotatedTypeBaseImpl contains comments indicating from which > superclass or interface the overridden methods comes. I'd either add > // Object at line 207 or delete line 145 and 177 for consistency. Okay; comments added to follow that local convention. > > Even though this isn't performance critical by far the allocation at > line 215 still bugs me a bit given that the common case will most > certainly be no annotations. Sure; refactored to avoid the allocation. > > Why the inverted logic line 250-253, IIRC you should be able to test > if it is an AnnotatedBaseTypeImpl, or? I was aiming to avoid testing for the impl class directly to not directly tie the classes to this particular implementation of the AnnotatedType hierarchy. However, inter-operability based on the specs would need the equals and hashCode behavior to be defined. > > For equalsTypeAndAnnotations and baseHashCode lines 232-244 equals > test for owner type equality while hashcode doesn't include owner > type. I must confess I no longer remember the equals-hashCode contract > but I assume this is intentional. Good catch; equals and hashCode checks made consistent. Some refactoring and hardening of the test included too. Delta-diffs below. Thanks, -Joe diff webrev.2/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java webrev/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java 2c2 ? * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights reserved. 207c207 ???????? @Override // java.lang.Object 215d214 ??? ??? StringJoiner sj = new StringJoiner(" "); 228,229c228,231 ??? ??? return sj.toString(); >???????????? } else { > ??? ??? return ""; > ??? ??? } 244c246,247 ???????????????? Objects.hash((Object[])getAnnotations()) ^ > ??? ??? Objects.hash(getAnnotatedOwnerType()); diff webrev.2/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java webrev/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java 142d141 < 157,168c156,158 ??? ??? checkTypesForEquality(m.getAnnotatedReturnType(), > ??? ??? ??? ??? ? m.getAnnotatedReturnType(), > ??? ??? ??? ??? ? true); 171a162,185 >???? private static void checkTypesForEquality(AnnotatedType annotType1, > ??? ??? ??? ??? ??? ????? AnnotatedType annotType2, > ??? ??? ??? ??? ??? ????? boolean expected) { > ??? boolean comparison = annotType1.equals(annotType2); > > ??? if (comparison) { > ??? ??? int hash1 = annotType1.hashCode(); > ??? ??? int hash2 = annotType1.hashCode(); > ??? ??? if (hash1 != hash2) { > ??? ??? errors++; > ??? ??? System.err.format("Equal AnnotatedTypes with unequal hash codes: %n%s%n%s%n", > ??? ??? ??? ??? ? annotType1.toString(), annotType2.toString()); > ??? ??? } > ??? } > > ??? if (comparison != expected) { > ??? ??? errors++; > ??? ??? System.err.println(annotType1); > ??? ??? System.err.println(expected ? " is not equal to " : " is equal to "); > ??? ??? System.err.println(annotType2); > ??? ??? System.err.println(); > ??? } >???? } > 184,196c198,200 checkTypesForEquality(methods[i].getAnnotatedReturnType(), > ??? ??? ??? ??? ??? ? methods[j].getAnnotatedReturnType(), > ??? ??? ??? ??? ??? ? false); 209,210c213 ???????? System.err.println("Testing that presence/absence of annotations matters for equals comparison."); 212,226c215,230 ??? String methodName = null; >???????? for (Method method :? clazz1.getDeclaredMethods()) { > ??? ??? if ("void".equals(method.getReturnType().toString())) { > ??? ??? continue; > ??? ??? } > > ??? ??? methodName = method.getName(); > ??? ??? try { > ??? ??? checkTypesForEquality(method.getAnnotatedReturnType(), > clazz2.getDeclaredMethod(methodName).getAnnotatedReturnType(), > ??? ??? ??? ??? ????? false); > ??? ??? } catch (Exception e) { > ??? ??? errors++; > ??? ??? System.err.println("Method " + methodName + " not found."); > ??? ??? } > ??? } 230a235 >???????? System.err.println("Testing wildcards"); 242,248c247 ??? checkTypesForEquality(awt1, awt2, false); 254d252 < From joel.borggren.franck at gmail.com Wed Oct 10 06:40:04 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Wed, 10 Oct 2018 08:40:04 +0200 Subject: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() In-Reply-To: References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> Message-ID: Hej Joe, New version looks good! Thanks for the explanations, makes sense to me. Cheers /Joel On Wed, 10 Oct 2018 at 08:27, joe darcy wrote: > Hi Joel, > > Thanks for the review; slightly revised version at > > http://cr.openjdk.java.net/~darcy/8058202.3/ > > Comments below. > > > On 10/9/2018 11:00 AM, Joel Borggr?n-Franck wrote: > > Hi Joe, > > > > Good to see this happening. In general looks good to me, a few nits > below. > > > > AnnotatedTypeBaseImpl contains comments indicating from which > > superclass or interface the overridden methods comes. I'd either add > > // Object at line 207 or delete line 145 and 177 for consistency. > > Okay; comments added to follow that local convention. > > > > > Even though this isn't performance critical by far the allocation at > > line 215 still bugs me a bit given that the common case will most > > certainly be no annotations. > > Sure; refactored to avoid the allocation. > > > > > Why the inverted logic line 250-253, IIRC you should be able to test > > if it is an AnnotatedBaseTypeImpl, or? > > I was aiming to avoid testing for the impl class directly to not > directly tie the classes to this particular implementation of the > AnnotatedType hierarchy. However, inter-operability based on the specs > would need the equals and hashCode behavior to be defined. > > > > > For equalsTypeAndAnnotations and baseHashCode lines 232-244 equals > > test for owner type equality while hashcode doesn't include owner > > type. I must confess I no longer remember the equals-hashCode contract > > but I assume this is intentional. > > Good catch; equals and hashCode checks made consistent. > > Some refactoring and hardening of the test included too. > > Delta-diffs below. > > Thanks, > > -Joe > > diff > webrev.2/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java > > webrev/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java > > > 2c2 > < * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights > reserved. > --- > > * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights > reserved. > 207c207 > < @Override > --- > > @Override // java.lang.Object > 215d214 > < StringJoiner sj = new StringJoiner(" "); > 216a216 > > StringJoiner sj = new StringJoiner(" "); > 228,229c228,231 > < } > < return sj.toString(); > --- > > return sj.toString(); > > } else { > > return ""; > > } > 244c246,247 > < Objects.hash((Object[])getAnnotations()); > --- > > Objects.hash((Object[])getAnnotations()) ^ > > Objects.hash(getAnnotatedOwnerType()); > > diff > webrev.2/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java > > webrev/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java > > > 142d141 > < > 157,168c156,158 > < AnnotatedType annotType1 = m.getAnnotatedReturnType(); > < AnnotatedType annotType2 = m.getAnnotatedReturnType(); > < > < boolean valid = annotType1.equals(annotType2); > < > < if (!valid) { > < errors++; > < System.err.println(annotType1); > < System.err.println(" is not equal to "); > < System.err.println(annotType2); > < System.err.println(); > < } > --- > > checkTypesForEquality(m.getAnnotatedReturnType(), > > m.getAnnotatedReturnType(), > > true); > 171a162,185 > > private static void checkTypesForEquality(AnnotatedType annotType1, > > AnnotatedType annotType2, > > boolean expected) { > > boolean comparison = annotType1.equals(annotType2); > > > > if (comparison) { > > int hash1 = annotType1.hashCode(); > > int hash2 = annotType1.hashCode(); > > if (hash1 != hash2) { > > errors++; > > System.err.format("Equal AnnotatedTypes with unequal hash > codes: %n%s%n%s%n", > > annotType1.toString(), annotType2.toString()); > > } > > } > > > > if (comparison != expected) { > > errors++; > > System.err.println(annotType1); > > System.err.println(expected ? " is not equal to " : " is > equal to "); > > System.err.println(annotType2); > > System.err.println(); > > } > > } > > > 184,196c198,200 > < AnnotatedType annotType1 = > methods[i].getAnnotatedReturnType(); > < AnnotatedType annotType2 = > methods[j].getAnnotatedReturnType(); > < > < boolean valid = !annotType1.equals(annotType2); > < > < if (!valid) { > < errors++; > < System.err.println(annotType1); > < System.err.println(" is equal to "); > < System.err.println(annotType2); > < System.err.println(); > < } > < > --- > > checkTypesForEquality(methods[i].getAnnotatedReturnType(), > > methods[j].getAnnotatedReturnType(), > > false); > 209,210c213 > < Method[] methods1 = clazz1.getDeclaredMethods(); > < Method[] methods2 = clazz2.getDeclaredMethods(); > --- > > System.err.println("Testing that presence/absence of > annotations matters for equals comparison."); > 212,226c215,230 > < // Skip 0th element since void cannoted be annotated > < for (int i = 1; i < methods1.length; i++) { > < AnnotatedType annotType1 = > methods1[i].getAnnotatedReturnType(); > < AnnotatedType annotType2 = > methods2[i].getAnnotatedReturnType(); > < > < boolean valid = !annotType1.equals(annotType2); > < > < if (!valid) { > < errors++; > < System.err.println(annotType1); > < System.err.println(" is equal to "); > < System.err.println(annotType2); > < System.err.println(); > < } > < } > --- > > String methodName = null; > > for (Method method : clazz1.getDeclaredMethods()) { > > if ("void".equals(method.getReturnType().toString())) { > > continue; > > } > > > > methodName = method.getName(); > > try { > > checkTypesForEquality(method.getAnnotatedReturnType(), > > clazz2.getDeclaredMethod(methodName).getAnnotatedReturnType(), > > false); > > } catch (Exception e) { > > errors++; > > System.err.println("Method " + methodName + " not found."); > > } > > } > 230a235 > > System.err.println("Testing wildcards"); > 242,248c247 > < if (awt1.equals(awt2)) { > < errors++; > < System.err.println(awt1); > < System.err.println(" is equal to "); > < System.err.println(awt2); > < System.err.println(); > < } > --- > > checkTypesForEquality(awt1, awt2, false); > 254d252 > < > From xueming.shen at oracle.com Wed Oct 10 07:16:50 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 10 Oct 2018 00:16:50 -0700 Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files In-Reply-To: References: Message-ID: <5BBDA762.3040001@oracle.com> Hi Langer, Here are some of my comments. ZipEntry: Optional> getPosixPermissions() (1) Is "Optional" really necessary here. it's a little inconsistent compared to the rest of methods in the class. a "null" return might be just fine? (2) Needs a

    to separate the first line of the spec from the rest (3) The wording probably needs more consideration. For example, it might be more straightforward to use some similar wording from other methods, for example ... When read from a ZIP file, this is the posix permission stored in the {@codeexternal file attributes} field of the zip file entry'scentral directory record, if there is one. Also, a @ImplNote might be the better place for "it's not available when read from ZIS"? void setPosixPermissions( Set permissions) I can see the possible use case of using "null" as a special value to reset the permission field (and my proposal of simply returning a null from getPosixPermissions() when there is no one, brings some symmetry here?) ZipUtil: (1) those POSIX_... constants don't need to be public? (2) I like the "stream" style implementation of permsTo/FromFlags pair, but have some concerns regarding their cost. "stream" is relative expensive (when you take a look at those supporting class underneath), as these two are supposed to be invoked for every entry inside a zip file, they can be hundreds and thousands ... just wonder, given most of the entries likely to have the "same" permission set inside a "normal" zip/jar file, is it worth to put in some cache mechanism here, especially for the "get" method, is it designed to return a read-only set of permission? (in which we can use some mechanism here). That said PosixFileAttributes.getPermissions() actually purposely returns a modifiable set of permissions. It might be worth some discussion here, as the ZipEntry.getPosixPermission() needs to specify it, if it's going to return a immutable set. Test: These days it is discouraged to check in a binary zip file as a test target. It is preferred to create the testing zip file on the fly. -Sherman On 9/25/18, 7:57 AM, Langer, Christoph wrote: > > Hi all, > > I had asked for opinions regarding adding posix permission support to > JDK?s zip handling libraries and tools [1]. Since I didn?t get clear > ?no, you can?t do this? answers, I?m now concretely proposing some > enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool. > > I have reopened the long standing bug report (6194856) which had been > set to ?Won?t fix? quite recently for this purpose. > > Here are the technical details: > > The ZIP format specifications by infozip and pkware ([2] and [3]) do > not explicitly specify the handling of posix file permissions. But it > seems to be common sense that if file attribute compatibility is set > to ?Unix? in the upper byte of CEN field ?version made by?, the file > permissions bits are stored in CEN field ?external file attributes?, > byte 3 and 4. My changes try to honor this in the least obtrusive way. ?? > > The following changes are proposed: > > java.util.zip.ZipEntry: > > it will have an additional field ?posixPerms?. A value of -1 means ?no > permission information?, positive values will contain the flag values. > > There will be 2 new public methods to read/set the permission information: > > public Optional> > getPosixPermissions() > > public void > setPosixPermissions(Set permissions) > > The usage of type ?Optional? reflects that posix permissions are not > necessarily present in a zip file > > java.util.zip.ZipFile: > > it will have the capability to read the CEN fields and > set posixPerms if available > > java.util.zip.ZipOutputStream: > > it will store entries with associated posix > permissions as unix type in the CEN, together with the bit mask for > the permissions > > jdk.jartool: > > I propose to add and option "--preserve-posix" or short "-o" to honor > the posix bits that may be stored inside zip/jar files. By default the > option is not set and hence posix permissions are ignored. If the flag > is set and the file system that the jar tool is running on supports > posix, posix file permissions that exist in the file system will be > stored in newly created/update archives or restored to the file system > if such information is present in the archive. > > jdk.zipfs: > > I added the capability for posix file permissions in > the implementation. I decided to support PosixFileAttributes by > subclassing ZipFileAttributes from this superclass as well as > subclassing ZipFileAttributeView from PosixFileAttributeView. However, > as PosixFileAttributes also include groups and owners, I would throw > UnsupportedOperationExceptions in case of invoking methods to handle > these attributes. But this approach seems to be most consistent with > e.g. Files.setPosixFilePermissions and Files.getPosixFilePermissions. > > java.nio.file.attribute.PosixFilePermissions: > > As this class presents a collection of static helpers, > I added definitions for the posix file bit masks together with methods > to convert between Sets of PosixFilePermission to bit masks containing > the according switches and vice versa. These definitions could > theoretically also be moved inside the java.util.zip or jdk.zipfs > implementations where they wouldn?t be exposed as public APIs. > However, in that case the code would probably need to be duplicated. > > I?ve also created two jtreg testcases for both, java.util.zip and > jdk.nio.zipfs. > > The changes also contain a few further code cleanups. > > Here are the links: > > Bug: https://bugs.openjdk.java.net/browse/JDK-6194856 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.0/ > > > I?ll write a CSR once there?s some substantial feedback to my endeavor. > > Thanks in advance for reviewing/commenting. > > Best regards > > Christoph > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055375.html > > [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip > > [3] https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT > From daniel.fuchs at oracle.com Wed Oct 10 10:39:43 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 10 Oct 2018 11:39:43 +0100 Subject: RFR [12] - 8211960: broken links in java.util.logging Message-ID: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> Hi, Please find below a doc-only fix for: 8211960: broken links in java.util.logging https://bugs.openjdk.java.net/browse/JDK-8211960 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html The original link was intended to refer to java.util.Formatter#syntax, which is in another module (and no longer in the parent directory). Rather than try to navigate the class/module hierarchy to link to that same anchor, this patch proposes to link to String#format instead, which has all the appropriate information and which is what the implementation is specified to use anyway. best regards, -- daniel From chris.hegarty at oracle.com Wed Oct 10 10:54:19 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 10 Oct 2018 11:54:19 +0100 Subject: RFR [12] - 8211960: broken links in java.util.logging In-Reply-To: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> References: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> Message-ID: On 10/10/18 11:39, Daniel Fuchs wrote: > Hi, > > Please find below a doc-only fix for: > > 8211960: broken links in java.util.logging > https://bugs.openjdk.java.net/browse/JDK-8211960 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html Looks good. -Chris. From mandy.chung at oracle.com Wed Oct 10 15:32:30 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Oct 2018 08:32:30 -0700 Subject: RFR [12] - 8211960: broken links in java.util.logging In-Reply-To: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> References: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> Message-ID: On 10/10/18 3:39 AM, Daniel Fuchs wrote: > Hi, > > Please find below a doc-only fix for: > > 8211960: broken links in java.util.logging > https://bugs.openjdk.java.net/browse/JDK-8211960 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html > Alternatively, this can link to java.util.Formatter class as the text is "format string".? It seems that Formatter class fits better with the SimpleFormatter class description than String.format. Mandy From rhillegas at comcast.net Wed Oct 10 15:37:57 2018 From: rhillegas at comcast.net (Richard Hillegas) Date: Wed, 10 Oct 2018 08:37:57 -0700 Subject: generated code and jigsaw modules In-Reply-To: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> Message-ID: Thanks again to R?mi and Alan for their advice. Unfortunately, I have not been able to make either approach work, given another complexity of Derby's class loading. Let me explain that additional issue. Derby lets users load jar files into the database. There they live as named blobs of bytes. The jar files contain user-defined data types, functions, procedures, and aggregators, which are coded in Java and can be used in SQL statements. Derby lets users wire these jar files into a custom classpath which drives a custom ClassLoader at query-execution time. I have not been able to make this custom ClassLoader work with either R?mi or Alan's approach. Note that a Derby engine manages many databases and each database can have its own custom ClassLoader. I like the simplicity of R?mi's approach: java.lang.invoke.MethodHandles.lookup().defineClass(generatedClassBytes) This approach does indeed put the generated class where I want it: inside the Derby engine module. Unfortunately, the ClassLoader of the generated class is the application class loader. I can't figure out how to force the generated class to use the custom ClassLoader instead. As a consequence,? the generated class cannot resolve user-defined functions which live inside jar files in the database. Poking the customer ClassLoader into the thread's context class loader before calling MethodHandles.lookup() doesn't work. Alan's approach is a bit more complicated. It involves following the pattern in com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl. It involves generating a temporary module for each generated class and then adding more export directives to the engine module so that the generated module can call back into the engine. I have to say I'm a little confused about the implications of slow memory leaks with this approach. I don't know what happens to these generated modules and export directives when the generated class is garbage-collected. More immediately, however, I am up against the same problem which plagues R?mi's approach: how do I get the generated module to resolve classes in the custom ClassLoader? More specifically, I am stuck trying to get the generated module to require the user-written modules, that is, the user-written jar files. What I am missing is the ability to retrieve the module names of these jar files so that I can craft requires directives. The only way I know to get a module name is to use ModuleFinder.of(Path...). Unfortunately, the Path interface is an abstraction for file systems and is not a good fit for locating a blob of bytes stored inside a database. I would appreciate any further advice about how to get over these speed bumps. Thanks, -Rick On 10/4/18 9:10 AM, Richard Hillegas wrote: > I am looking for advice about how to tighten up module encapsulation > while generating byte code on the fly. I ask this question on behalf > of Apache Derby, a pure-Java relational database whose original code > dates back to Java 1.2. I want to reduce Derby's attack-surface when > running with a module path. > > First a little context: A relational database is an interpreter for > the SQL language. It converts SQL queries into byte code which then > runs on a virtual machine embedded in the interpreter. In Derby's > case, the virtual machine is the Java VM and the byte code is simply > Java byte code. That is, a Derby query plan is a class whose byte code > is generated on the fly at run time. > > I have converted the Apache Derby codeline into a set of jigsaw > modules: https://issues.apache.org/jira/browse/DERBY-6945. > Unfortunately, I had to punch holes in the encapsulation of the main > Derby module so that the generated query plans could call back into > the Derby engine. That is because, by default, generated query plans > load into the catch-all, unnamed module. Note that all of these > generated classes live in a single package which does not belong to > any named module. > > 1) Is it possible to load generated code into a named module? > > 2) Alternatively, can someone recommend another approach for > preserving module encapsulation while generating classes on the fly? > > I would appreciate any advice or examples which you can recommend. > > Thanks, > -Rick > > From daniel.fuchs at oracle.com Wed Oct 10 15:44:20 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 10 Oct 2018 16:44:20 +0100 Subject: RFR [12] - 8211960: broken links in java.util.logging In-Reply-To: References: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> Message-ID: <11dbe820-4dff-5801-4628-aa8dd392b79b@oracle.com> Hi Mandy, On 10/10/2018 16:32, Mandy Chung wrote: > > > On 10/10/18 3:39 AM, Daniel Fuchs wrote: >> Hi, >> >> Please find below a doc-only fix for: >> >> 8211960: broken links in java.util.logging >> https://bugs.openjdk.java.net/browse/JDK-8211960 >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html >> > > Alternatively, this can link to java.util.Formatter class as the text is > "format string".? It seems that Formatter class fits better with the > SimpleFormatter class description than String.format. Right - I was afraid of possible confusion between java.util.logging.Formatter and java.util.Formatter, and the spec shows a call to String.format(....) when explaining how the LogRecord is formatted... But if you still think that {@linkplain java.util.Formatter format string} is a better link - let me know - I'll make the change. best regards, -- daniel > > Mandy > > From naoto.sato at oracle.com Wed Oct 10 16:50:15 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 10 Oct 2018 09:50:15 -0700 Subject: [12]RFR of JDK-8210403:Refactor java.util.Locale:i18n shell tests to plain java tests In-Reply-To: <46debed1-8c0f-962b-f266-2aef25aa35d6@oracle.com> References: <46debed1-8c0f-962b-f266-2aef25aa35d6@oracle.com> Message-ID: <9a25ed50-207f-9347-b791-445c990da445@oracle.com> Looks OK to me. Naoto On 10/9/18 11:19 PM, Ying Zhou wrote: > Hello, > > test/java/util/Locale/LocaleCategory.sh > test/java/util/Locale/LocaleProviders.sh > > Please review this patch to refactor above shell script tests to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8210403 > > webrev: http://cr.openjdk.java.net/~dzhou/8210403/webrev.00/ > > > Thanks, > > Daisy > From Alan.Bateman at oracle.com Wed Oct 10 16:53:45 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2018 17:53:45 +0100 Subject: generated code and jigsaw modules In-Reply-To: References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> Message-ID: On 10/10/2018 16:37, Richard Hillegas wrote: > : > > java.lang.invoke.MethodHandles.lookup().defineClass(generatedClassBytes) > > This approach does indeed put the generated class where I want it: > inside the Derby engine module. Unfortunately, the ClassLoader of the > generated class is the application class loader. I can't figure out > how to force the generated class to use the custom ClassLoader instead. MethodHandles.lookup() creates a Lookup to the caller of the method so I assume you must be calling it from Derby code on the class path. If you want the class generated in the same runtime package as the code loaded from the database then you'll need to get a Lookup object to a class in that runtime package, perhaps with privateLookupIn. > > Alan's approach is a bit more complicated. It involves following the > pattern in com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl. > It involves generating a temporary module for each generated class and > then adding more export directives to the engine module so that the > generated module can call back into the engine. I have to say I'm a > little confused about the implications of slow memory leaks with this > approach. I don't know what happens to these generated modules and > export directives when the generated class is garbage-collected. > > More immediately, however, I am up against the same problem which > plagues R?mi's approach: how do I get the generated module to resolve > classes in the custom ClassLoader? More specifically, I am stuck > trying to get the generated module to require the user-written > modules, that is, the user-written jar files. What I am missing is the > ability to retrieve the module names of these jar files so that I can > craft requires directives. The only way I know to get a module name is > to use ModuleFinder.of(Path...). Unfortunately, the Path interface is > an abstraction for file systems and is not a good fit for locating a > blob of bytes stored inside a database. My mail wasn't suggesting an approach, I was just pointing out an example of code in the JDK that creates a dynamic module to encapsulate generated code. It just happens that there is one class in that module. As regards classes in the database then it would require developing your own ModuleFinder that can find modules in the database. There was an example on jigsaw-dev recently where someone was looking for a ModuleFinder to find modules in WAR files [1] which might be useful to get an idea on what is involved. -Alan [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-September/013924.html From mandy.chung at oracle.com Wed Oct 10 16:56:11 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Oct 2018 09:56:11 -0700 Subject: RFR [12] - 8211960: broken links in java.util.logging In-Reply-To: <11dbe820-4dff-5801-4628-aa8dd392b79b@oracle.com> References: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> <11dbe820-4dff-5801-4628-aa8dd392b79b@oracle.com> Message-ID: On 10/10/18 8:44 AM, Daniel Fuchs wrote: > Hi Mandy, > > On 10/10/2018 16:32, Mandy Chung wrote: >> >> Alternatively, this can link to java.util.Formatter class as the text >> is "format string".? It seems that Formatter class fits better with >> the SimpleFormatter class description than String.format. > > Right - I was afraid of possible confusion between > java.util.logging.Formatter and java.util.Formatter, and the > spec shows a call to String.format(....) when explaining how > the LogRecord is formatted... > > But if you still think that > {@linkplain java.util.Formatter format string} > is a better link - let me know - I'll make the change. The javadoc of SimpleFormatter::format(LogRecord) method does describe the format argument is a java.util.Formatter format string.?? Also the class description also links to this method.? So I think these two broken links can simply be removed and the spec about the formatting is in the SimpleFormatter::format method javadoc.? What do you think? Mandy From ivan.gerasimov at oracle.com Wed Oct 10 17:22:01 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 10 Oct 2018 10:22:01 -0700 Subject: RFR (XS) 8211396 : Broken link in javadoc for private java.util.regex.Pattern#normalize() Message-ID: <5a5fc67e-1952-7951-81c1-25cc90aa88f5@oracle.com> Hello! The javadoc refers to the enum values as java.text.Normalizer.Form.NFC, while it should be java.text.Normalizer.Form#NFC. Also an unpaired parenthesis was removed. Would you please help review the trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211396 WEBREV: http://cr.openjdk.java.net/~igerasim/8211396/00/webrev/ -- With kind regards, Ivan Gerasimov From jonathan.gibbons at oracle.com Wed Oct 10 17:29:39 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 10 Oct 2018 10:29:39 -0700 Subject: RFR (XS) 8211396 : Broken link in javadoc for private java.util.regex.Pattern#normalize() In-Reply-To: <5a5fc67e-1952-7951-81c1-25cc90aa88f5@oracle.com> References: <5a5fc67e-1952-7951-81c1-25cc90aa88f5@oracle.com> Message-ID: Looks good to me. -- Jon On 10/10/18 10:22 AM, Ivan Gerasimov wrote: > Hello! > > The javadoc refers to the enum values as > java.text.Normalizer.Form.NFC, while it should be > java.text.Normalizer.Form#NFC. > > Also an unpaired parenthesis was removed. > > Would you please help review the trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211396 > WEBREV: http://cr.openjdk.java.net/~igerasim/8211396/00/webrev/ > From xueming.shen at oracle.com Wed Oct 10 17:35:14 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 10 Oct 2018 10:35:14 -0700 Subject: RFR (XS) 8211396 : Broken link in javadoc for private java.util.regex.Pattern#normalize() In-Reply-To: <5a5fc67e-1952-7951-81c1-25cc90aa88f5@oracle.com> References: <5a5fc67e-1952-7951-81c1-25cc90aa88f5@oracle.com> Message-ID: <5BBE3852.20606@oracle.com> +1 On 10/10/18, 10:22 AM, Ivan Gerasimov wrote: > Hello! > > The javadoc refers to the enum values as > java.text.Normalizer.Form.NFC, while it should be > java.text.Normalizer.Form#NFC. > > Also an unpaired parenthesis was removed. > > Would you please help review the trivial fix? > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8211396 > WEBREV: http://cr.openjdk.java.net/~igerasim/8211396/00/webrev/ > From mandy.chung at oracle.com Wed Oct 10 20:38:07 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Oct 2018 13:38:07 -0700 Subject: Review Request: JDK-8211921,,AssertionError in MethodHandles$Lookup.defineClass Message-ID: <2f97dfab-bfcc-723d-2b71-b1bf89ab82a0@oracle.com> The assertion in Lookup::defineClass ensures that the resulting Class is defined with the same loader in the same package in the same protection domain as the lookup class.? When a class is defined to the boot loader, its protection domain is set to null which implies AllPermission but Class::getProtectionDomain however does not guarantee to return the same PD instance.? Hence the assertion may fail when 2+ threads are getting PD at the same time. This assertion is not strictly necessary and test/jdk/java/lang/invoke/DefineClassTest.java verifies these properties of the resulting Class.? I propose to remove this assertion. diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java @@ -969,9 +969,6 @@ ???????????? ProtectionDomain pd = (loader != null) ? lookupClassProtectionDomain() : null; ???????????? String source = "__Lookup_defineClass__"; ???????????? Class clazz = SharedSecrets.getJavaLangAccess().defineClass(loader, cn, bytes, pd, source); -??????????? assert clazz.getClassLoader() == lookupClass.getClassLoader() -??????????????????? && clazz.getPackageName().equals(lookupClass.getPackageName()) -??????????????????? && protectionDomain(clazz) == lookupClassProtectionDomain(); ???????????? return clazz; ???????? } Mandy From Alan.Bateman at oracle.com Wed Oct 10 20:41:40 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Oct 2018 21:41:40 +0100 Subject: Review Request: JDK-8211921,,AssertionError in MethodHandles$Lookup.defineClass In-Reply-To: <2f97dfab-bfcc-723d-2b71-b1bf89ab82a0@oracle.com> References: <2f97dfab-bfcc-723d-2b71-b1bf89ab82a0@oracle.com> Message-ID: On 10/10/2018 21:38, Mandy Chung wrote: > : > > This assertion is not strictly necessary and > test/jdk/java/lang/invoke/DefineClassTest.java verifies these > properties of the resulting Class.? I propose to remove this > assertion. An alternative is to just drop the PD check from the assertion, the check that defining class loader and package should never fail. Either is okay with me. -Alan From mandy.chung at oracle.com Wed Oct 10 21:03:48 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Oct 2018 14:03:48 -0700 Subject: Review Request: JDK-8211921,,AssertionError in MethodHandles$Lookup.defineClass In-Reply-To: References: <2f97dfab-bfcc-723d-2b71-b1bf89ab82a0@oracle.com> Message-ID: On 10/10/18 1:41 PM, Alan Bateman wrote: > > > On 10/10/2018 21:38, Mandy Chung wrote: >> : >> >> This assertion is not strictly necessary and >> test/jdk/java/lang/invoke/DefineClassTest.java verifies these >> properties of the resulting Class.? I propose to remove this >> assertion. > An alternative is to just drop the PD check from the assertion, the > check that defining class loader and package should never fail. Either > is okay with me. If the loader or package is not the one expected, it's a serious bug and also the DefineClassTest test will catch it.? I opt to take this out as the assertion does not seem adding much value. thanks Mandy From rhillegas at comcast.net Thu Oct 11 00:33:42 2018 From: rhillegas at comcast.net (Richard Hillegas) Date: Wed, 10 Oct 2018 17:33:42 -0700 Subject: generated code and jigsaw modules In-Reply-To: References: <73180d63-2298-1146-26d8-85208c1cdd17@comcast.net> Message-ID: <5907f18f-978f-925c-a8e0-50338a5bc3c7@comcast.net> Thanks, Alan. This is very helpful. On 10/10/18 9:53 AM, Alan Bateman wrote: > On 10/10/2018 16:37, Richard Hillegas wrote: >> : >> >> java.lang.invoke.MethodHandles.lookup().defineClass(generatedClassBytes) >> >> This approach does indeed put the generated class where I want it: >> inside the Derby engine module. Unfortunately, the ClassLoader of the >> generated class is the application class loader. I can't figure out >> how to force the generated class to use the custom ClassLoader instead. > MethodHandles.lookup() creates a Lookup to the caller of the method so > I assume you must be calling it from Derby code on the class path. If > you want the class generated in the same runtime package as the code > loaded from the database then you'll need to get a Lookup object to a > class in that runtime package, perhaps with privateLookupIn. > >> >> Alan's approach is a bit more complicated. It involves following the >> pattern in >> com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl. It >> involves generating a temporary module for each generated class and >> then adding more export directives to the engine module so that the >> generated module can call back into the engine. I have to say I'm a >> little confused about the implications of slow memory leaks with this >> approach. I don't know what happens to these generated modules and >> export directives when the generated class is garbage-collected. >> >> More immediately, however, I am up against the same problem which >> plagues R?mi's approach: how do I get the generated module to resolve >> classes in the custom ClassLoader? More specifically, I am stuck >> trying to get the generated module to require the user-written >> modules, that is, the user-written jar files. What I am missing is >> the ability to retrieve the module names of these jar files so that I >> can craft requires directives. The only way I know to get a module >> name is to use ModuleFinder.of(Path...). Unfortunately, the Path >> interface is an abstraction for file systems and is not a good fit >> for locating a blob of bytes stored inside a database. > My mail wasn't suggesting an approach, I was just pointing out an > example of code in the JDK that creates a dynamic module to > encapsulate generated code. It just happens that there is one class in > that module. > > As regards classes in the database then it would require developing > your own ModuleFinder that can find modules in the database. There was > an example on jigsaw-dev recently where someone was looking for a > ModuleFinder to find modules in WAR files [1] which might be useful to > get an idea on what is involved. > > -Alan > > [1] > http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-September/013924.html > > > > > From joe.darcy at oracle.com Thu Oct 11 00:45:49 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 10 Oct 2018 17:45:49 -0700 Subject: 8152910: Get performance improvement with Stable annotation In-Reply-To: <1D0F24A9-8A24-42B9-9226-3520EB1B063C@oracle.com> References: <1D0F24A9-8A24-42B9-9226-3520EB1B063C@oracle.com> Message-ID: <5BBE9D3D.6070707@oracle.com> Looks fine Brian; thanks, -Joe On 10/1/2018 2:31 PM, Brian Burkhalter wrote: > Please review at your convenience: > > https://bugs.openjdk.java.net/browse/JDK-8152910 > > JMH benchmarks do show a slight but measurable performance improvement with the below patch applied. > > Thanks, > > Brian > > --- a/src/java.base/share/classes/java/math/BigInteger.java > +++ b/src/java.base/share/classes/java/math/BigInteger.java > @@ -41,6 +41,7 @@ > import jdk.internal.math.DoubleConsts; > import jdk.internal.math.FloatConsts; > import jdk.internal.HotSpotIntrinsicCandidate; > +import jdk.internal.vm.annotation.Stable; > > /** > * Immutable arbitrary-precision integers. All operations behave as if > @@ -1219,8 +1220,10 @@ > * Initialize static constant array when class is loaded. > */ > private static final int MAX_CONSTANT = 16; > - private static BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; > - private static BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; > + @Stable > + private static final BigInteger posConst[] = new BigInteger[MAX_CONSTANT+1]; > + @Stable > + private static final BigInteger negConst[] = new BigInteger[MAX_CONSTANT+1]; > From huaming.li at oracle.com Thu Oct 11 02:40:15 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 11 Oct 2018 10:40:15 +0800 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary Message-ID: <3c68dd68-2d0e-15fa-c95a-05e3d283f1e0@oracle.com> Would you please review the following patch? bug: ? https://bugs.openjdk.java.net/browse/JDK-8186610 ? https://bugs.openjdk.java.net/browse/JDK-8211976 webrev: http://cr.openjdk.java.net/~mli/8186610/ Thank you -Hamlin From igor.ignatyev at oracle.com Thu Oct 11 03:08:46 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 03:08:46 +0000 (UTC) Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary Message-ID: Hi Hamlin, as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common test library, and 8211976 suggests moving it closer to tests. could you please explain why you decided to put it into the library instead? Thanks, -- Igor ----- Original Message ----- From: huaming.li at oracle.com To: core-libs-dev at openjdk.java.net Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada Pacific Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary Would you please review the following patch? bug: ? https://bugs.openjdk.java.net/browse/JDK-8186610 ? https://bugs.openjdk.java.net/browse/JDK-8211976 webrev: http://cr.openjdk.java.net/~mli/8186610/ Thank you -Hamlin From huaming.li at oracle.com Thu Oct 11 03:26:05 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 11 Oct 2018 11:26:05 +0800 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: References: Message-ID: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> Hi Igor, Would you please clarify your concern further? I mean why ModuleTargetHelper can be put to top level when it use non-public APIs e.g. jdk.internal.module.*? Thank you -Hamlin On 2018/10/11 11:08 AM, Igor Ignatyev wrote: > Hi Hamlin, > > as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common test library, and 8211976 suggests moving it closer to tests. could you please explain why you decided to put it into the library instead? > > Thanks, > -- Igor > > ----- Original Message ----- > From: huaming.li at oracle.com > To: core-libs-dev at openjdk.java.net > Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada Pacific > Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary > > Would you please review the following patch? > > bug: > > ? https://bugs.openjdk.java.net/browse/JDK-8186610 > > ? https://bugs.openjdk.java.net/browse/JDK-8211976 > > webrev: http://cr.openjdk.java.net/~mli/8186610/ > > > Thank you > > -Hamlin > From igor.ignatyev at oracle.com Thu Oct 11 03:38:40 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 10 Oct 2018 20:38:40 -0700 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> References: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> Message-ID: <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> b/c this will make test library modularization[1] somewhat troublesome, also I ain't sure if ModuleTargetHelper really needs to be placed into the top-level library regardless of its dependency on non-public API. "promoting" test library class to the top-level library comes w/ increased maintenance costs, the parent task[2] explains that in more details. [1] https://bugs.openjdk.java.net/browse/JDK-8211358 [2] https://bugs.openjdk.java.net/browse/JDK-8211290 -- Igor > On Oct 10, 2018, at 8:26 PM, Hamlin Li wrote: > > Hi Igor, > > Would you please clarify your concern further? I mean why ModuleTargetHelper can be put to top level when it use non-public APIs e.g. jdk.internal.module.*? > > Thank you > > -Hamlin > > On 2018/10/11 11:08 AM, Igor Ignatyev wrote: >> Hi Hamlin, >> >> as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common test library, and 8211976 suggests moving it closer to tests. could you please explain why you decided to put it into the library instead? >> >> Thanks, >> -- Igor >> >> ----- Original Message ----- >> From: huaming.li at oracle.com >> To: core-libs-dev at openjdk.java.net >> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada Pacific >> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary >> >> Would you please review the following patch? >> >> bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8186610 >> >> https://bugs.openjdk.java.net/browse/JDK-8211976 >> >> webrev: http://cr.openjdk.java.net/~mli/8186610/ >> >> >> Thank you >> >> -Hamlin >> > From weijun.wang at oracle.com Thu Oct 11 03:47:54 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 11 Oct 2018 11:47:54 +0800 Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary In-Reply-To: References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com> <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com> Message-ID: <26823CE9-8C75-4AB3-9FCA-ED5B53960589@oracle.com> Do we have a plan to move away from the deprecated methods? Is there a flag I can set to check how many classes are using them? --Max > On Sep 30, 2018, at 11:00 PM, Alan Bateman wrote: > > On 27/09/2018 00:38, Igor Ignatyev wrote: >> here is the webrevs w/ JarUtils from default package inserted into jdk.test.lib.util.JarUtils: >> whole patch: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html >>> 655 lines changed: 239 ins; 355 del; 61 mod; >> incremental: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html >>> 476 lines changed: 239 ins; 203 del; 34 mod; >> >> doing that, I noticed that both updateJarFile and createJarFile don't close Stream from Files::find, the current patch fixes that. >> > I see you've also deprecated the String methods in the old class - good! I'd probably carry over test/jdk/lib/testlibrary/JarUtils.java without changing the format but your IDE must be setup differently and it will get changed again by whoever next changes it so I think it's okay. > > The update to tests using this look fine. > > -Alan From james at lightbend.com Thu Oct 11 04:06:23 2018 From: james at lightbend.com (James Roper) Date: Thu, 11 Oct 2018 15:06:23 +1100 Subject: Why Stream.concat is a static method - type variable contravariance Message-ID: With the work I'm doing at the moment at creating a Reactive Streams equivalent to java.util.stream, I've often wondered why Stream.concat is a static method, rather than an instance method concating the given stream onto this. But I think the reason has just dawned on me, and I wanted to confirm that I'm correct. Java doesn't support contravariant type variables - it does for type declarations, but not type variables. To put more concretely, if I had a Stream, and I wanted to concat a Stream, this is a valid thing to do, the resulting stream would be Stream. But doing that with an instance method would require something like this: public Stream concat(Stream b); Which is not supported (specifically, type variable declaration is not supported). In contrast, what we have in the actual API: public static Stream concat(Stream a, Stream b); does allow me to concat a Stream and Stream with a resulting type of Stream. Is this right, or are there other reasons? Also, is there any possibility that Java might support contravariance in type variables in future? My reason for wanting it is to provide the following method for reactive streams: public Publisher onErrorResumeWith(Function> f); The intent of this method is when a stream encounters an error, the passed function is invoked with the error, and that function returns a publisher that gets concated to the current stream instead of the error being emitted. This could possibly be implemented with a static method: public static Publisher onErrorResumeWith(Publisher a, Function f); But unlike concat, this method feels and reads much better as an instance method, as a static method it's a little confusing. Regards, James -- *James Roper* *Senior Developer, Office of the CTO* Lightbend ? Build reactive apps! Twitter: @jroper From amy.lu at oracle.com Thu Oct 11 06:13:44 2018 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 11 Oct 2018 14:13:44 +0800 Subject: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 In-Reply-To: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com> References: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com> Message-ID: Ping ~ It's no longer running this test in a separate job as test OOM issue (JDK-8199265) fixed. Thanks, Amy On 2018/9/4 5:46 PM, Amy Lu wrote: > test/jdk/java/util/Arrays/TimSortStackSize2.java > > This test was demoted to tier2 due to JDK-8199265 (test fails with > OOM). This issue has been fixed (in jdk-11+20) and test has been run > (in tier2) without failure happening after that. > > Let's move it back to tier1. > > bug: https://bugs.openjdk.java.net/browse/JDK-8210353 > webrev: http://cr.openjdk.java.net/~amlu/8210353/webrev.00/ > > Thanks, > Amy > > diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups > --- a/test/jdk/TEST.groups > +++ b/test/jdk/TEST.groups > @@ -35,8 +35,7 @@ > ???? :jdk_lang > > ?tier1_part2 = \ > -??? :jdk_util \ > -??? -java/util/Arrays/TimSortStackSize2.java > +??? :jdk_util > > ?tier1_part3 = \ > ???? :jdk_math \ > @@ -67,9 +66,7 @@ > ???? -sun/nio/cs/ISO8859x.java \ > ???? :jdk_other \ > ???? :jdk_text \ > -??? :jdk_time \ > -??? java/util/Arrays/TimSortStackSize2.java > - > +??? :jdk_time > > ?tier2_part3 = \ > ???? :jdk_net > diff --git a/test/jdk/java/util/Arrays/TimSortStackSize2.java > b/test/jdk/java/util/Arrays/TimSortStackSize2.java > --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java > +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java > @@ -25,7 +25,6 @@ > ? * @test > ? * @bug 8072909 > ? * @summary Test TimSort stack size on big arrays > - * @key intermittent > ? * @library /lib/testlibrary /test/lib > ? * @modules java.management > ? *????????? java.base/jdk.internal > From forax at univ-mlv.fr Thu Oct 11 06:27:21 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 11 Oct 2018 08:27:21 +0200 (CEST) Subject: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 In-Reply-To: References: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com> Message-ID: <1427462186.14360.1539239241513.JavaMail.zimbra@u-pem.fr> Looks good ! R?mi ----- Mail original ----- > De: "Amy Lu" > ?: "core-libs-dev" > Envoy?: Jeudi 11 Octobre 2018 08:13:44 > Objet: Re: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 > Ping ~ > > It's no longer running this test in a separate job as test OOM issue > (JDK-8199265) fixed. > > Thanks, > Amy > > On 2018/9/4 5:46 PM, Amy Lu wrote: >> test/jdk/java/util/Arrays/TimSortStackSize2.java >> >> This test was demoted to tier2 due to JDK-8199265 (test fails with >> OOM). This issue has been fixed (in jdk-11+20) and test has been run >> (in tier2) without failure happening after that. >> >> Let's move it back to tier1. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210353 >> webrev: http://cr.openjdk.java.net/~amlu/8210353/webrev.00/ >> >> Thanks, >> Amy >> >> diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups >> --- a/test/jdk/TEST.groups >> +++ b/test/jdk/TEST.groups >> @@ -35,8 +35,7 @@ >> ???? :jdk_lang >> >> ?tier1_part2 = \ >> -??? :jdk_util \ >> -??? -java/util/Arrays/TimSortStackSize2.java >> +??? :jdk_util >> >> ?tier1_part3 = \ >> ???? :jdk_math \ >> @@ -67,9 +66,7 @@ >> ???? -sun/nio/cs/ISO8859x.java \ >> ???? :jdk_other \ >> ???? :jdk_text \ >> -??? :jdk_time \ >> -??? java/util/Arrays/TimSortStackSize2.java >> - >> +??? :jdk_time >> >> ?tier2_part3 = \ >> ???? :jdk_net >> diff --git a/test/jdk/java/util/Arrays/TimSortStackSize2.java >> b/test/jdk/java/util/Arrays/TimSortStackSize2.java >> --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java >> +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java >> @@ -25,7 +25,6 @@ >> ? * @test >> ? * @bug 8072909 >> ? * @summary Test TimSort stack size on big arrays >> - * @key intermittent >> ? * @library /lib/testlibrary /test/lib >> ? * @modules java.management >> ? *????????? java.base/jdk.internal From amy.lu at oracle.com Thu Oct 11 06:29:53 2018 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 11 Oct 2018 14:29:53 +0800 Subject: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 In-Reply-To: <1427462186.14360.1539239241513.JavaMail.zimbra@u-pem.fr> References: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com> <1427462186.14360.1539239241513.JavaMail.zimbra@u-pem.fr> Message-ID: <1e844a7f-05a9-7a70-891f-e60b3d882e49@oracle.com> Thank you R?mi! /Amy On 2018/10/11 2:27 PM, Remi Forax wrote: > Looks good ! > > R?mi > > ----- Mail original ----- >> De: "Amy Lu" >> ?: "core-libs-dev" >> Envoy?: Jeudi 11 Octobre 2018 08:13:44 >> Objet: Re: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 >> Ping ~ >> >> It's no longer running this test in a separate job as test OOM issue >> (JDK-8199265) fixed. >> >> Thanks, >> Amy >> >> On 2018/9/4 5:46 PM, Amy Lu wrote: >>> test/jdk/java/util/Arrays/TimSortStackSize2.java >>> >>> This test was demoted to tier2 due to JDK-8199265 (test fails with >>> OOM). This issue has been fixed (in jdk-11+20) and test has been run >>> (in tier2) without failure happening after that. >>> >>> Let's move it back to tier1. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210353 >>> webrev: http://cr.openjdk.java.net/~amlu/8210353/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups >>> --- a/test/jdk/TEST.groups >>> +++ b/test/jdk/TEST.groups >>> @@ -35,8 +35,7 @@ >>> ???? :jdk_lang >>> >>> ?tier1_part2 = \ >>> -??? :jdk_util \ >>> -??? -java/util/Arrays/TimSortStackSize2.java >>> +??? :jdk_util >>> >>> ?tier1_part3 = \ >>> ???? :jdk_math \ >>> @@ -67,9 +66,7 @@ >>> ???? -sun/nio/cs/ISO8859x.java \ >>> ???? :jdk_other \ >>> ???? :jdk_text \ >>> -??? :jdk_time \ >>> -??? java/util/Arrays/TimSortStackSize2.java >>> - >>> +??? :jdk_time >>> >>> ?tier2_part3 = \ >>> ???? :jdk_net >>> diff --git a/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> b/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> @@ -25,7 +25,6 @@ >>> ? * @test >>> ? * @bug 8072909 >>> ? * @summary Test TimSort stack size on big arrays >>> - * @key intermittent >>> ? * @library /lib/testlibrary /test/lib >>> ? * @modules java.management >>> ? *????????? java.base/jdk.internal From huaming.li at oracle.com Thu Oct 11 06:31:56 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 11 Oct 2018 14:31:56 +0800 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> References: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> Message-ID: <51f9c3e8-8d33-0b0b-271e-150a5784317c@oracle.com> Thank you clarifying Igor. Moving ModuleTargetHelper to local folder has a drawback: it's hard for future maintainer to found it if they need to use it in other places, that make it an "*invisible*" library class. Although I don't fully agree with you, I have updated the webrev as you suggested: http://cr.openjdk.java.net/~mli/8186610/webrev.01/ Thank you -Hamlin On 2018/10/11 11:38 AM, Igor Ignatyev wrote: > b/c this will make test library modularization[1] somewhat > troublesome, also I ain't sure if ModuleTargetHelper really needs to > be placed into the top-level library regardless of its dependency on > non-public API. "promoting" test library class to the top-level > library comes w/ increased maintenance costs, the parent task[2] > explains that in more details. > > [1] https://bugs.openjdk.java.net/browse/JDK-8211358 > [2] https://bugs.openjdk.java.net/browse/JDK-8211290 > > -- Igor > >> On Oct 10, 2018, at 8:26 PM, Hamlin Li > > wrote: >> >> Hi Igor, >> >> Would you please clarify your concern further? I mean why >> ModuleTargetHelper can be put to top level when it use non-public >> APIs e.g. jdk.internal.module.*? >> >> Thank you >> >> -Hamlin >> >> On 2018/10/11 11:08 AM, Igor Ignatyev wrote: >>> Hi Hamlin, >>> >>> as ModuleTargetHelper uses non-public API, I'd prefer not to have in >>> a common test library, and 8211976 suggests moving it closer to >>> tests. could you please explain why you decided to put it into the >>> library instead? >>> >>> Thanks, >>> -- Igor >>> >>> ----- Original Message ----- >>> From: huaming.li at oracle.com >>> To: core-libs-dev at openjdk.java.net >>> >>> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada >>> Pacific >>> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary >>> >>> Would you please review the following patch? >>> >>> bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8186610 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8211976 >>> >>> webrev: http://cr.openjdk.java.net/~mli/8186610/ >>> >>> >>> >>> Thank you >>> >>> -Hamlin >>> >> > From Alan.Bateman at oracle.com Thu Oct 11 06:35:56 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Oct 2018 07:35:56 +0100 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: References: Message-ID: <5ccb79dc-c845-f037-50b3-b24d25d85bca@oracle.com> On 11/10/2018 04:08, Igor Ignatyev wrote: > Hi Hamlin, > > as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common test library, and 8211976 suggests moving it closer to tests. could you please explain why you decided to put it into the library instead? > Right, ModuleTargetHelper is just a helper classes in the jlink tests, it's not general purpose and not suitable to put into the test infrastructure directory. -Alan From amy.lu at oracle.com Thu Oct 11 08:47:11 2018 From: amy.lu at oracle.com (Amy Lu) Date: Thu, 11 Oct 2018 16:47:11 +0800 Subject: RFR of JDK-8209768: Refactor java/util/prefs/CheckUserPrefsStorage.sh to plain java test Message-ID: <9c7dab1b-9ffc-2187-08b1-b30e958bae84@oracle.com> java/util/prefs/CheckUserPrefsStorage.sh Please review this patch to refactor above shell script test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8209768 webrev: http://cr.openjdk.java.net/~amlu/8209768/webrev.00/ Thanks, Amy From daniel.fuchs at oracle.com Thu Oct 11 11:54:28 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 11 Oct 2018 12:54:28 +0100 Subject: RFR [12] - 8211960: broken links in java.util.logging In-Reply-To: References: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> <11dbe820-4dff-5801-4628-aa8dd392b79b@oracle.com> Message-ID: <0614fc03-cee6-6eb3-0354-6507ef5cadc2@oracle.com> Hi Mandy, On 10/10/2018 17:56, Mandy Chung wrote: > The javadoc of SimpleFormatter::format(LogRecord) method does > describe the format argument is a java.util.Formatter format string. > Also the class description also links to this method. So I think these > two broken links can simply be removed and the spec about the formatting > is in the SimpleFormatter::format method javadoc. What do you think? I agree, this is probably the better solution: http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.01/index.html best regards, -- daniel On 10/10/18 3:39 AM, Daniel Fuchs wrote: > > 8211960: broken links in java.util.logging > https://bugs.openjdk.java.net/browse/JDK-8211960 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.00/index.html > From lance.andersen at oracle.com Thu Oct 11 11:55:26 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 11 Oct 2018 07:55:26 -0400 Subject: RFR 8212045: Add back tests removed from HashesTest.java and AddExportsTest.java Message-ID: <2F61942B-8856-4AD9-95F7-F93C259F89FB@oracle.com> Hi all,, Catching up on this issue from my todo list which adds a test back to HashesTest.java and AddExportsTest.java which were removed as part of the Java EE module removal(The original changes to remove the tests can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ ) The webrev can be found for the change at http://cr.openjdk.java.net/~lancea/8212045/webrev.00/index.html To help make the review easier, here is a diff of the tests comparing the new changes to the tests prior to the Java EE module removal: ???? HashesTest.java diff ?????? $ hg diff -r 47216 test/jdk/tools/jmod/hashes/HashesTest.java diff -r 71c04702a3d5 test/jdk/tools/jmod/hashes/HashesTest.java --- a/test/jdk/tools/jmod/hashes/HashesTest.java Tue Sep 12 19:03:39 2017 +0200 +++ b/test/jdk/tools/jmod/hashes/HashesTest.java Thu Jun 14 12:34:52 2018 -0400 @@ -1,5 +1,5 @@ /** - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -247,19 +247,17 @@ Path dest = Paths.get("test4"); HashesTest ht = new HashesTest(dest); ht.makeModule("m1"); - ht.makeModule("java.xml.bind", "m1"); - ht.makeModule("java.xml.ws", "java.xml.bind"); - ht.makeModule("m2", "java.xml.ws"); + ht.makeModule("java.compiler", "m1"); + ht.makeModule("m2", "java.compiler"); ht.makeJmod("m1"); ht.makeJmod("m2"); - ht.makeJmod("java.xml.ws"); - ht.makeJmod("java.xml.bind", + ht.makeJmod("java.compiler", "--module-path", ht.lib.toString() + File.pathSeparator + mpath, - "--hash-modules", "^java.xml.*|^m.*"); + "--hash-modules", "java\\.(?!se)|^m.*"); - ht.checkHashes("java.xml.bind", "java.xml.ws", "m2"); + ht.checkHashes("java.compiler", "m2"); } @Test ????????? AddExports.java Diff ??????? $ hg diff -r 47216 test/jdk/tools/launcher/modules/addexports/AddExportsTest.java diff -r 71c04702a3d5 test/jdk/tools/launcher/modules/addexports/AddExportsTest.java --- a/test/jdk/tools/launcher/modules/addexports/AddExportsTest.java Tue Sep 12 19:03:39 2017 +0200 +++ b/test/jdk/tools/launcher/modules/addexports/AddExportsTest.java Fri Jun 15 15:17:56 2018 -0400 @@ -24,7 +24,7 @@ /** * @test * @library /lib/testlibrary /test/lib - * @modules java.transaction + * @modules java.compiler * jdk.compiler * @build AddExportsTest jdk.test.lib.compiler.CompilerUtils jdk.testlibrary.* * @run testng AddExportsTest @@ -58,7 +58,7 @@ private static final String TEST1_MODULE = "m1"; private static final String TEST1_MAIN_CLASS = "jdk.test1.Main"; - // test module m2 uses java.transaction internals + // test module m2 uses java.compiler internals private static final String TEST2_MODULE = "m2"; private static final String TEST2_MAIN_CLASS = "jdk.test2.Main"; @@ -78,18 +78,18 @@ "--add-exports", "java.base/jdk.internal.misc=m1"); assertTrue(compiled, "module " + TEST1_MODULE + " did not compile"); - // javac -d upgrademods/java.transaction src/java.transaction/** + // javac -d upgrademods/java.compiler src/java.compiler/** compiled = CompilerUtils.compile( - SRC_DIR.resolve("java.transaction"), - UPGRADE_MODS_DIRS.resolve("java.transaction")); - assertTrue(compiled, "module java.transaction did not compile"); + SRC_DIR.resolve("java.compiler"), + UPGRADE_MODS_DIRS.resolve("java.compiler")); + assertTrue(compiled, "module java.compiler did not compile"); // javac --upgrade-module-path upgrademods -d mods/m2 src/m2/** compiled = CompilerUtils.compile( SRC_DIR.resolve(TEST2_MODULE), MODS_DIR.resolve(TEST2_MODULE), "--upgrade-module-path", UPGRADE_MODS_DIRS.toString(), - "--add-exports", "java.transaction/javax.transaction.internal=m2"); + "--add-exports", "java.compiler/javax.tools.internal=m2"); assertTrue(compiled, "module " + TEST2_MODULE + " did not compile"); // javac -d mods/m3 src/m3/** @@ -168,11 +168,11 @@ */ public void testWithUpgradedModule() throws Exception { - // java --add-exports java.transaction/javax.transaction.internal=m2 + // java --add-exports java.compiler/javax.tools.internal=m2 // --upgrade-module-path upgrademods --module-path mods -m ... String mid = TEST2_MODULE + "/" + TEST2_MAIN_CLASS; int exitValue = executeTestJava( - "--add-exports", "java.transaction/javax.transaction.internal=m2", + "--add-exports", "java.compiler/javax.tools.internal=m2", "--upgrade-module-path", UPGRADE_MODS_DIRS.toString(), "--module-path", MODS_DIR.toString(), "-m", mid) ljanders-mac:open ljanders$ -------------------- The mach 5 jdk tier1, tier2, and tier3 tests ran without error Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Thu Oct 11 12:26:36 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Oct 2018 13:26:36 +0100 Subject: RFR 8211922: Remove test/jdk/javax/naming/module/RunBasic.java from the ProblemList Message-ID: <8AA8E5FF-62E0-4EE9-85A3-3F6165BE2D76@oracle.com> Now that 8211921 has been fixed, this test can be removed from the ProblemList. Several hundred test runs have been stable. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -874,8 +874,6 @@ javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all -javax/naming/module/RunBasic.java 8211850 generic-all - ############################################################################ ########################################################################### -Chris. From lance.andersen at oracle.com Thu Oct 11 12:27:49 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 11 Oct 2018 08:27:49 -0400 Subject: RFR 8211922: Remove test/jdk/javax/naming/module/RunBasic.java from the ProblemList In-Reply-To: <8AA8E5FF-62E0-4EE9-85A3-3F6165BE2D76@oracle.com> References: <8AA8E5FF-62E0-4EE9-85A3-3F6165BE2D76@oracle.com> Message-ID: <20E00F43-577B-43FB-BDDC-E28CE97BC751@oracle.com> +1 > On Oct 11, 2018, at 8:26 AM, Chris Hegarty wrote: > > Now that 8211921 has been fixed, this test can be removed > from the ProblemList. Several hundred test runs have been > stable. > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -874,8 +874,6 @@ > > javax/rmi/ssl/SSLSocketParametersTest.sh 8162906 generic-all > > -javax/naming/module/RunBasic.java 8211850 generic-all > - > ############################################################################ > > ########################################################################### > > > -Chris. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From pavel.rappo at oracle.com Thu Oct 11 12:28:07 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Thu, 11 Oct 2018 13:28:07 +0100 Subject: RFR [12] 8212001: Verify exported symbols in java.base (libjava) Message-ID: <409B05A8-1804-4301-8BCD-9E19998E4617@oracle.com> Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8212001/webrev.00 This is yet another clean-up kind of change. It seals unnecessarily exported functions. This time from libjava. Also couldn't help fixing a typo. Not only does it soothe aesthetic discomfort, it also helps with search (including correct indexing). This change has been built and tested on all supported platforms. A note for reviewers. I noticed an asymmetry in the following declarations[^1]: JNIEXPORT jint handleRead(FD fd, void *buf, jint len); JNIEXPORT jlong JNICALL handleLseek(FD fd, jlong offset, jint whence); These functions seem to be used in exactly the same way (from libzip). Is there any reason for this difference (JNICALL)? [^1]: http://cr.openjdk.java.net/~prappo/8212001/webrev.00/src/java.base/windows/native/libjava/io_util_md.h.html (lines 48, 52 and 53) From chris.hegarty at oracle.com Thu Oct 11 12:30:41 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Oct 2018 13:30:41 +0100 Subject: RFR [12] 8212001: Verify exported symbols in java.base (libjava) In-Reply-To: <409B05A8-1804-4301-8BCD-9E19998E4617@oracle.com> References: <409B05A8-1804-4301-8BCD-9E19998E4617@oracle.com> Message-ID: <92D81181-9F02-4A73-AA32-4C5DC3B88F0E@oracle.com> > On 11 Oct 2018, at 13:28, Pavel Rappo wrote: > > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8212001/webrev.00 This looks good. Thanks Pavel. -Chris. From Roger.Riggs at oracle.com Thu Oct 11 13:10:19 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Oct 2018 09:10:19 -0400 Subject: RFR [12] 8212001: Verify exported symbols in java.base (libjava) In-Reply-To: <92D81181-9F02-4A73-AA32-4C5DC3B88F0E@oracle.com> References: <409B05A8-1804-4301-8BCD-9E19998E4617@oracle.com> <92D81181-9F02-4A73-AA32-4C5DC3B88F0E@oracle.com> Message-ID: Hi Pavel, Looks fine. The JNICALL macro is used by the C compiler to force a particular native calling convention (API). ABI - Application binary interface that defines the stack and register usage when calling native functions. On Windows it is defined as __stdcall, which is the default so there is no change in behavior if it is missing. See src/java.base/*/native/include/jni_md.h It seems most native function declarations include JNICALL. Possibly this should be a separate cleanup but being consistent within each native source file would be a good start. Roger On 10/11/2018 08:30 AM, Chris Hegarty wrote: >> On 11 Oct 2018, at 13:28, Pavel Rappo wrote: >> >> Hello, >> >> Please review the following change: >> >> http://cr.openjdk.java.net/~prappo/8212001/webrev.00 > This looks good. Thanks Pavel. > > -Chris. > From krishna.addepalli at oracle.com Thu Oct 11 13:38:46 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Thu, 11 Oct 2018 13:38:46 +0000 (UTC) Subject: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound In-Reply-To: <20B87A5C-A1E9-4B11-9C79-3EFC740421BB@oracle.com> References: <20B87A5C-A1E9-4B11-9C79-3EFC740421BB@oracle.com> Message-ID: <585042e6-7292-4fde-9f9c-5bb05dbfe279@default> Hi Kim, An alternative way to fix it would be to declare the loop variable itself as unsigned, since the channels can never be negative, but that would require you to cast to int in two places. Also, when casting, it is better to use static_cast, rather than C style casting. Thanks, Krishna -----Original Message----- From: Brian Burkhalter Sent: Wednesday, October 10, 2018 4:53 AM To: Kim Barrett ; 2d-dev <2d-dev at openjdk.java.net> Cc: Java Core Libs Subject: Re: [OpenJDK 2D-Dev] RFR: 8211962: Implicit narrowing in MacOSX java.desktop jsound Looping in 2d-dev. > On Oct 9, 2018, at 4:17 PM, Kim Barrett wrote: > > [I'm not sure whether core-libs is the right list for java.desktop > changes.] > > Please review this trivial fix of a build failure on MacOSX when > compiling with C++11/14 enabled. An int value is being used in an > initializer where an unsigned int is needed, which is not permitted > since C++11. The solution taken is to cast the value in the > initializer. A "better" solution would be to change the type of the > value, but that has substantial fannout because there are many places > in our code where signed ints were used instead of the unsigned ints > used by the underlying MacOSX framework. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8211962 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8211962/open.00/ > > Testing: > mach5 tier1 on MacOSX (really just verifying it builds). > > From martinrb at google.com Thu Oct 11 13:54:30 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 11 Oct 2018 06:54:30 -0700 Subject: Why Stream.concat is a static method - type variable contravariance In-Reply-To: References: Message-ID: Is this the problem discussed here? http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#Lower%20Bound%20Type%20Parameters%20of%20Methods (I think I ran into this myself and think the java language should be fixed to allow "Lower Bound Type Parameters of Methods") On Wed, Oct 10, 2018 at 9:06 PM, James Roper wrote: > With the work I'm doing at the moment at creating a Reactive Streams > equivalent to java.util.stream, I've often wondered why Stream.concat is a > static method, rather than an instance method concating the given stream > onto this. But I think the reason has just dawned on me, and I wanted to > confirm that I'm correct. > > Java doesn't support contravariant type variables - it does for type > declarations, but not type variables. > > To put more concretely, if I had a Stream, and I wanted to concat > a Stream, this is a valid thing to do, the resulting stream would > be Stream. But doing that with an instance method would require > something like this: > > public Stream concat(Stream b); > > Which is not supported (specifically, type variable declaration > is not supported). In contrast, what we have in the actual API: > > public static Stream concat(Stream a, Stream T> b); > > does allow me to concat a Stream and Stream with a > resulting type of Stream. > > Is this right, or are there other reasons? Also, is there any possibility > that Java might support contravariance in type variables in future? My > reason for wanting it is to provide the following method for reactive > streams: > > public Publisher onErrorResumeWith(Function Throwable, ? extends Publisher> f); > > The intent of this method is when a stream encounters an error, the passed > function is invoked with the error, and that function returns a publisher > that gets concated to the current stream instead of the error being > emitted. This could possibly be implemented with a static method: > > public static Publisher onErrorResumeWith(Publisher a, > Function f); > > But unlike concat, this method feels and reads much better as an instance > method, as a static method it's a little confusing. > > Regards, > > James > > -- > *James Roper* > *Senior Developer, Office of the CTO* > > Lightbend ? Build reactive apps! > Twitter: @jroper > From matthias.baesken at sap.com Thu Oct 11 14:47:56 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 11 Oct 2018 14:47:56 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: Hello Bob, > Hi Bob, > no problem , we can wait a few days until the final version of Win server > 2019 is out, and check the buildNumber again : > seems Windows server 2019 is GA now : https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows-server-2019-now-generally-available/ > > We don?t usually add logic to the JDK related to unreleased operating system > > previews. so I think we can process with the review . Still have to find out the buildNumber of the GA version, probably it has been incremented again . Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Dienstag, 2. Oktober 2018 17:03 > To: Bob Vandette > Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; > Moldenhauer, Niclas > Subject: RE: RFR : 8211106: [windows] Update OS detection code to > recognize Windows Server 2019 > > Hi Bob, > no problem , we can wait a few days until the final version of Win server > 2019 is out, and check the buildNumber again : > > https://cloudblogs.microsoft.com/windowsserver/2018/09/24/windows- > server-2019-announcing-general-availability-in-october/ > > says : > "In October, customers will have access to Windows Server 2019 through all > the channels! > We will publish a blog post to mark the availability of Windows Server 2019 > soon." > > > > > > The latest preview release is build 17744. Are you testing on that release? > > > > I was testing on a system with build number 17677 ( Windows Server 2019 > preview , seems older than what you are seeing) > and 17723 . > > > Best regards, Matthias > > > > -----Original Message----- > > From: Bob Vandette > > Sent: Dienstag, 2. Oktober 2018 16:09 > > To: Baesken, Matthias > > Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; > > Moldenhauer, Niclas > > Subject: Re: RFR : 8211106: [windows] Update OS detection code to > > recognize Windows Server 2019 > > > > Matthias, > > > > We don?t usually add logic to the JDK related to unreleased operating > system > > previews. > > > > Has the ReleaseID been updated on the system you are testing on? > > > > This is the documented way of determining the OS version you are running > > on? > > > > The latest preview release is build 17744. Are you testing on that release? > > > > https://techcommunity.microsoft.com/t5/Windows-Server- > > Insiders/Windows-Server-2019-version-info/td-p/234472 > > > > > > Bob. > > > > > > > On Oct 2, 2018, at 9:01 AM, Baesken, Matthias > > wrote: > > > > > > Hello, please review change 8211106 . > > > > > > It updates the Windows OS detection code to recognize Windows > Server > > 2019 . > > > > > > For this we have to look at the build number (dwBuildNumber of > > OSVERSIONINFOEX), > > > > > > https://docs.microsoft.com/en-us/windows/desktop/api/Winnt/ns- > winnt- > > _osversioninfoexa > > > > > > > > > because dwMajorVersion and dwMinorVersion are the same for > > Windows server 2016 and 2019 . > > > > > > The build number used to compare ( 17677 ) is for Windows Server 2019 > > preview , most likely the final version will have a higher build number but > > this is fine for the coding . > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8211106 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ > > > > > > > > > Thanks, Matthias From brian.goetz at oracle.com Thu Oct 11 16:09:45 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 11 Oct 2018 12:09:45 -0400 Subject: Why Stream.concat is a static method - type variable contravariance In-Reply-To: References: Message-ID: <13146dc3-bf6a-f7c4-eba6-bf1220a49a6a@oracle.com> It would surely be convenient; I've wished for this a few times. But, there's a reason for this choice, and its not just laziness; contravariant type variables have some pretty scary challenges. See, for example, this paper: ??? http://www.cis.upenn.edu/~bcpierce/papers/variance.pdf in which it is shown that contravariance is one of the ingredients in a witches brew that leads to undecideability of type checking. On 10/11/2018 12:06 AM, James Roper wrote: > With the work I'm doing at the moment at creating a Reactive Streams > equivalent to java.util.stream, I've often wondered why Stream.concat is a > static method, rather than an instance method concating the given stream > onto this. But I think the reason has just dawned on me, and I wanted to > confirm that I'm correct. > > Java doesn't support contravariant type variables - it does for type > declarations, but not type variables. > > To put more concretely, if I had a Stream, and I wanted to concat > a Stream, this is a valid thing to do, the resulting stream would > be Stream. But doing that with an instance method would require > something like this: > > public Stream concat(Stream b); > > Which is not supported (specifically, type variable declaration > is not supported). In contrast, what we have in the actual API: > > public static Stream concat(Stream a, Stream T> b); > > does allow me to concat a Stream and Stream with a > resulting type of Stream. > > Is this right, or are there other reasons? Also, is there any possibility > that Java might support contravariance in type variables in future? My > reason for wanting it is to provide the following method for reactive > streams: > > public Publisher onErrorResumeWith(Function Throwable, ? extends Publisher> f); > > The intent of this method is when a stream encounters an error, the passed > function is invoked with the error, and that function returns a publisher > that gets concated to the current stream instead of the error being > emitted. This could possibly be implemented with a static method: > > public static Publisher onErrorResumeWith(Publisher a, > Function f); > > But unlike concat, this method feels and reads much better as an instance > method, as a static method it's a little confusing. > > Regards, > > James > From Roger.Riggs at oracle.com Thu Oct 11 16:58:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Oct 2018 12:58:27 -0400 Subject: RFR 8192939: Remove Finalize methods from FileInputStream and FileOutputStream Message-ID: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> The finalizer methods of FileInputStream and FileOutputStream were deprecated for removal in JDK 9 and its time to remove them and the alternate mechanism to call close when the streams are found to be unreachable.? The Cleaner has been used since JDK 9 to close file descriptors that become unreferenced. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-io-finalize-8192939/index.html CSR: ? https://bugs.openjdk.java.net/browse/JDK-8212050 Thanks, Roger From volker.simonis at gmail.com Thu Oct 11 17:01:02 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Oct 2018 19:01:02 +0200 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* Message-ID: Hi, the change "CODETOOLS-7902290: introduce error state of @requires properties" [1] which was recently pushed to the codetools repo, breaks all JTreg tests which have a require clause that queries a non final (i.e. no "vm.opt.final") VM option. For example the test "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which uses "@requires vm.opt.DeoptimizeALot != true" will now fail with: test result: Error. Error evaluating expression: name not defined: vm.opt.DeoptimizeALot This is because com.sun.javatest.regtest.config.RegressionContext.get() was changed to return null instead of the string "null" for unknown properties. Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot" is indeed not defined (as many other "vm.opt" properties, see below). So it turns out that all the tests which @required a "vm.opt" option did run in a faulty configuration until now. I could for example easily fix "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding the corresponding option in VMProps.java: $ hg diff diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java --- a/test/jtreg-ext/requires/VMProps.java Thu Oct 11 10:11:18 2018 -0400 +++ b/test/jtreg-ext/requires/VMProps.java Thu Oct 11 18:51:37 2018 +0200 @@ -266,6 +266,8 @@ vmOptFinalFlag(map, "ClassUnloading"); vmOptFinalFlag(map, "UseCompressedOops"); vmOptFinalFlag(map, "EnableJVMCI"); + String value = String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot")); + map.put("vm.opt.DeoptimizeALot", value); } Following is a list of all "vm.opt" options used in @requires clauses without being defined in VMProps.java: vm.opt.AggressiveOpts vm.opt.ClassUnloading vm.opt.ClassUnloadingWithConcurrentMark vm.opt.DeoptimizeALot vm.opt.DisableExplicitGC vm.opt.ExplicitGCInvokesConcurrent vm.opt.FlightRecorder vm.opt.G1HeapRegionSize vm.opt.Inline vm.opt.MaxGCPauseMillis vm.opt.StartFlightRecording vm.opt.SurvivorAlignmentInBytes vm.opt.TieredCompilation vm.opt.TieredStopAtLevel vm.opt.TieredStopAtLevel==4) vm.opt.TieredStopAtLevel==null vm.opt.UseJVMCICompiler What's the current plan? Do we want to add all these options in VMProps.java? Or should we better add all the -XX VM options together to VMProps such that they can all be freely used within @requires clauses? Thank you and best regards, Volker PS: I've noticed that there's "8209807: improve handling exception in requires.VMProps" [2] to apparently adapt VMProps.java to CODETOOLS-7902290 but I've tried the attached webrev and it doesn't help with the described problem. [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 [2] https://bugs.openjdk.java.net/browse/JDK-8209807 From jonathan.gibbons at oracle.com Thu Oct 11 17:13:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Oct 2018 10:13:20 -0700 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* In-Reply-To: References: Message-ID: Volker, Thanks for the report.? I'll take a look shortly. -- Jon On 10/11/18 10:01 AM, Volker Simonis wrote: > Hi, > > the change "CODETOOLS-7902290: introduce error state of @requires > properties" [1] which was recently pushed to the codetools repo, > breaks all JTreg tests which have a require clause that queries a non > final (i.e. no "vm.opt.final") VM option. > > For example the test > "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which > uses "@requires vm.opt.DeoptimizeALot != true" will now fail with: > > test result: Error. Error evaluating expression: name not defined: > vm.opt.DeoptimizeALot > > This is because > com.sun.javatest.regtest.config.RegressionContext.get() was changed to > return null instead of the string "null" for unknown properties. > Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot" > is indeed not defined (as many other "vm.opt" properties, see below). > So it turns out that all the tests which @required a "vm.opt" option > did run in a faulty configuration until now. > > I could for example easily fix > "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding > the corresponding option in VMProps.java: > > $ hg diff > diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java > --- a/test/jtreg-ext/requires/VMProps.java Thu Oct 11 10:11:18 2018 -0400 > +++ b/test/jtreg-ext/requires/VMProps.java Thu Oct 11 18:51:37 2018 +0200 > @@ -266,6 +266,8 @@ > vmOptFinalFlag(map, "ClassUnloading"); > vmOptFinalFlag(map, "UseCompressedOops"); > vmOptFinalFlag(map, "EnableJVMCI"); > + String value = String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot")); > + map.put("vm.opt.DeoptimizeALot", value); > } > > Following is a list of all "vm.opt" options used in @requires clauses > without being defined in VMProps.java: > > vm.opt.AggressiveOpts > vm.opt.ClassUnloading > vm.opt.ClassUnloadingWithConcurrentMark > vm.opt.DeoptimizeALot > vm.opt.DisableExplicitGC > vm.opt.ExplicitGCInvokesConcurrent > vm.opt.FlightRecorder > vm.opt.G1HeapRegionSize > vm.opt.Inline > vm.opt.MaxGCPauseMillis > vm.opt.StartFlightRecording > vm.opt.SurvivorAlignmentInBytes > vm.opt.TieredCompilation > vm.opt.TieredStopAtLevel > vm.opt.TieredStopAtLevel==4) > vm.opt.TieredStopAtLevel==null > vm.opt.UseJVMCICompiler > > What's the current plan? Do we want to add all these options in > VMProps.java? Or should we better add all the -XX VM options together > to VMProps such that they can all be freely used within @requires > clauses? > > Thank you and best regards, > Volker > > PS: I've noticed that there's "8209807: improve handling exception in > requires.VMProps" [2] to apparently adapt VMProps.java to > CODETOOLS-7902290 but I've tried the attached webrev and it doesn't > help with the described problem. > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 > [2] https://bugs.openjdk.java.net/browse/JDK-8209807 From Alan.Bateman at oracle.com Thu Oct 11 17:15:23 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Oct 2018 18:15:23 +0100 Subject: RFR 8192939: Remove Finalize methods from FileInputStream and FileOutputStream In-Reply-To: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> References: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> Message-ID: <87b42378-4d28-5a53-8824-dd48cae51b90@oracle.com> On 11/10/2018 17:58, Roger Riggs wrote: > The finalizer methods of FileInputStream and FileOutputStream were > deprecated for removal > in JDK 9 and its time to remove them and the alternate mechanism to > call close > when the streams are found to be unreachable.? The Cleaner has been > used since JDK 9 to > close file descriptors that become unreferenced. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-io-finalize-8192939/index.html > > CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8212050 This looks okay and CSR captures the subtle behavioral issue and the source compatible issue with this removal. -Alan. From jonathan.gibbons at oracle.com Thu Oct 11 17:16:08 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Oct 2018 10:16:08 -0700 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* In-Reply-To: References: Message-ID: <1025735f-94ca-12a3-78f8-b895fb1b4b2e@oracle.com> Volker, It's a typo/oops on my part.? I'll fix it. -- Jon On 10/11/18 10:13 AM, Jonathan Gibbons wrote: > Volker, > > Thanks for the report.? I'll take a look shortly. > > -- Jon > > > On 10/11/18 10:01 AM, Volker Simonis wrote: >> Hi, >> >> the change "CODETOOLS-7902290: introduce error state of @requires >> properties" [1] which was recently pushed to the codetools repo, >> breaks all JTreg tests which have a require clause that queries a non >> final (i.e. no "vm.opt.final") VM option. >> >> For example the test >> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which >> uses "@requires vm.opt.DeoptimizeALot != true" will now fail with: >> >> test result: Error. Error evaluating expression: name not defined: >> vm.opt.DeoptimizeALot >> >> This is because >> com.sun.javatest.regtest.config.RegressionContext.get() was changed to >> return null instead of the string "null" for unknown properties. >> Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot" >> is indeed not defined (as many other "vm.opt" properties, see below). >> So it turns out that all the tests which @required a "vm.opt" option >> did run in a faulty configuration until now. >> >> I could for example easily fix >> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding >> the corresponding option in VMProps.java: >> >> $ hg diff >> diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java >> --- a/test/jtreg-ext/requires/VMProps.java????? Thu Oct 11 10:11:18 >> 2018 -0400 >> +++ b/test/jtreg-ext/requires/VMProps.java????? Thu Oct 11 18:51:37 >> 2018 +0200 >> @@ -266,6 +266,8 @@ >> ????????? vmOptFinalFlag(map, "ClassUnloading"); >> ????????? vmOptFinalFlag(map, "UseCompressedOops"); >> ????????? vmOptFinalFlag(map, "EnableJVMCI"); >> +??????? String value = >> String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot")); >> +??????? map.put("vm.opt.DeoptimizeALot", value); >> ????? } >> >> Following is a list of all "vm.opt" options used in @requires clauses >> without being defined in VMProps.java: >> >> vm.opt.AggressiveOpts >> vm.opt.ClassUnloading >> vm.opt.ClassUnloadingWithConcurrentMark >> vm.opt.DeoptimizeALot >> vm.opt.DisableExplicitGC >> vm.opt.ExplicitGCInvokesConcurrent >> vm.opt.FlightRecorder >> vm.opt.G1HeapRegionSize >> vm.opt.Inline >> vm.opt.MaxGCPauseMillis >> vm.opt.StartFlightRecording >> vm.opt.SurvivorAlignmentInBytes >> vm.opt.TieredCompilation >> vm.opt.TieredStopAtLevel >> vm.opt.TieredStopAtLevel==4) >> vm.opt.TieredStopAtLevel==null >> vm.opt.UseJVMCICompiler >> >> What's the current plan? Do we want to add all these options in >> VMProps.java? Or should we better add all the -XX VM options together >> to VMProps such that they can all be freely used within @requires >> clauses? >> >> Thank you and best regards, >> Volker >> >> PS: I've noticed that there's "8209807: improve handling exception in >> requires.VMProps" [2] to apparently adapt VMProps.java to >> CODETOOLS-7902290 but I've tried the attached webrev and it doesn't >> help with the described problem. >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 >> [2] https://bugs.openjdk.java.net/browse/JDK-8209807 > From iris.clark at oracle.com Thu Oct 11 17:41:29 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 11 Oct 2018 17:41:29 +0000 (UTC) Subject: RFR 8192939: Remove Finalize methods from FileInputStream and FileOutputStream In-Reply-To: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> References: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> Message-ID: <1ed8b58d-c3e3-4f27-8cd6-0655bd7a7be6@default> Hi, Roger. > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-io-finalize-8192939/index.html > > CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8212050 Your changes look good. For the regression testing, do you need to add a "noreg" label to the bug or add the bugid to the "@bug" tag in the tests? Thanks, Iris From Roger.Riggs at oracle.com Thu Oct 11 13:52:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Oct 2018 09:52:00 -0400 Subject: RFR 8192939: Remove Finalize methods from FileInputStream and FileOutputStream In-Reply-To: <1ed8b58d-c3e3-4f27-8cd6-0655bd7a7be6@default> References: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> <1ed8b58d-c3e3-4f27-8cd6-0655bd7a7be6@default> Message-ID: <41b350c1-3ab3-c9db-08c3-cfefc8dd0cec@oracle.com> Thanks Iris, Alan, noreg-self label added. On 10/11/2018 01:41 PM, Iris Clark wrote: > Hi, Roger. > >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-io-finalize-8192939/index.html >> >> CSR: >> ? https://bugs.openjdk.java.net/browse/JDK-8212050 > Your changes look good. > > For the regression testing, do you need to add a "noreg" label to the bug or add the bugid to the "@bug" tag in the tests? > > Thanks, > Iris From Roger.Riggs at oracle.com Thu Oct 11 14:09:20 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Oct 2018 10:09:20 -0400 Subject: RFR 8212045: Add back tests removed from HashesTest.java and AddExportsTest.java In-Reply-To: <2F61942B-8856-4AD9-95F7-F93C259F89FB@oracle.com> References: <2F61942B-8856-4AD9-95F7-F93C259F89FB@oracle.com> Message-ID: <603ea4ef-3064-ad5c-3f0d-9795a0af6251@oracle.com> Look fine Lance. On 10/11/2018 07:55 AM, Lance Andersen wrote: > Hi all,, > > Catching up on this issue from my todo list which adds a test back to HashesTest.java and AddExportsTest.java which were removed as part of the Java EE module removal(The original changes to remove the tests can be found at: http://cr.openjdk.java.net/~lancea/8190378/open_changes/tests_webrev/ ) > > > The webrev can be found for the change at http://cr.openjdk.java.net/~lancea/8212045/webrev.00/index.html > > > To help make the review easier, here is a diff of the tests comparing the new changes to the tests prior to the Java EE module removal: > > ???? > HashesTest.java diff > ?????? > $ hg diff -r 47216 test/jdk/tools/jmod/hashes/HashesTest.java > diff -r 71c04702a3d5 test/jdk/tools/jmod/hashes/HashesTest.java > --- a/test/jdk/tools/jmod/hashes/HashesTest.java Tue Sep 12 19:03:39 2017 +0200 > +++ b/test/jdk/tools/jmod/hashes/HashesTest.java Thu Jun 14 12:34:52 2018 -0400 > @@ -1,5 +1,5 @@ > /** > - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -247,19 +247,17 @@ > Path dest = Paths.get("test4"); > HashesTest ht = new HashesTest(dest); > ht.makeModule("m1"); > - ht.makeModule("java.xml.bind", "m1"); > - ht.makeModule("java.xml.ws", "java.xml.bind"); > - ht.makeModule("m2", "java.xml.ws"); > + ht.makeModule("java.compiler", "m1"); > + ht.makeModule("m2", "java.compiler"); > > ht.makeJmod("m1"); > ht.makeJmod("m2"); > - ht.makeJmod("java.xml.ws"); > - ht.makeJmod("java.xml.bind", > + ht.makeJmod("java.compiler", > "--module-path", > ht.lib.toString() + File.pathSeparator + mpath, > - "--hash-modules", "^java.xml.*|^m.*"); > + "--hash-modules", "java\\.(?!se)|^m.*"); > > - ht.checkHashes("java.xml.bind", "java.xml.ws", "m2"); > + ht.checkHashes("java.compiler", "m2"); > } > > @Test > > ????????? > > AddExports.java Diff > > ??????? > $ hg diff -r 47216 test/jdk/tools/launcher/modules/addexports/AddExportsTest.java > diff -r 71c04702a3d5 test/jdk/tools/launcher/modules/addexports/AddExportsTest.java > --- a/test/jdk/tools/launcher/modules/addexports/AddExportsTest.java Tue Sep 12 19:03:39 2017 +0200 > +++ b/test/jdk/tools/launcher/modules/addexports/AddExportsTest.java Fri Jun 15 15:17:56 2018 -0400 > @@ -24,7 +24,7 @@ > /** > * @test > * @library /lib/testlibrary /test/lib > - * @modules java.transaction > + * @modules java.compiler > * jdk.compiler > * @build AddExportsTest jdk.test.lib.compiler.CompilerUtils jdk.testlibrary.* > * @run testng AddExportsTest > @@ -58,7 +58,7 @@ > private static final String TEST1_MODULE = "m1"; > private static final String TEST1_MAIN_CLASS = "jdk.test1.Main"; > > - // test module m2 uses java.transaction internals > + // test module m2 uses java.compiler internals > private static final String TEST2_MODULE = "m2"; > private static final String TEST2_MAIN_CLASS = "jdk.test2.Main"; > > @@ -78,18 +78,18 @@ > "--add-exports", "java.base/jdk.internal.misc=m1"); > assertTrue(compiled, "module " + TEST1_MODULE + " did not compile"); > > - // javac -d upgrademods/java.transaction src/java.transaction/** > + // javac -d upgrademods/java.compiler src/java.compiler/** > compiled = CompilerUtils.compile( > - SRC_DIR.resolve("java.transaction"), > - UPGRADE_MODS_DIRS.resolve("java.transaction")); > - assertTrue(compiled, "module java.transaction did not compile"); > + SRC_DIR.resolve("java.compiler"), > + UPGRADE_MODS_DIRS.resolve("java.compiler")); > + assertTrue(compiled, "module java.compiler did not compile"); > > // javac --upgrade-module-path upgrademods -d mods/m2 src/m2/** > compiled = CompilerUtils.compile( > SRC_DIR.resolve(TEST2_MODULE), > MODS_DIR.resolve(TEST2_MODULE), > "--upgrade-module-path", UPGRADE_MODS_DIRS.toString(), > - "--add-exports", "java.transaction/javax.transaction.internal=m2"); > + "--add-exports", "java.compiler/javax.tools.internal=m2"); > assertTrue(compiled, "module " + TEST2_MODULE + " did not compile"); > > // javac -d mods/m3 src/m3/** > @@ -168,11 +168,11 @@ > */ > public void testWithUpgradedModule() throws Exception { > > - // java --add-exports java.transaction/javax.transaction.internal=m2 > + // java --add-exports java.compiler/javax.tools.internal=m2 > // --upgrade-module-path upgrademods --module-path mods -m ... > String mid = TEST2_MODULE + "/" + TEST2_MAIN_CLASS; > int exitValue = executeTestJava( > - "--add-exports", "java.transaction/javax.transaction.internal=m2", > + "--add-exports", "java.compiler/javax.tools.internal=m2", > "--upgrade-module-path", UPGRADE_MODS_DIRS.toString(), > "--module-path", MODS_DIR.toString(), > "-m", mid) > ljanders-mac:open ljanders$ > > -------------------- > > The mach 5 jdk tier1, tier2, and tier3 tests ran without error > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > -- Thanks, Roger From igor.ignatyev at oracle.com Thu Oct 11 18:51:32 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 11:51:32 -0700 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: <51f9c3e8-8d33-0b0b-271e-150a5784317c@oracle.com> References: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> <51f9c3e8-8d33-0b0b-271e-150a5784317c@oracle.com> Message-ID: <91B13BAD-2CCE-4CEA-B89D-D4D5D620F406@oracle.com> Hi Hamlin, the key point here, ModuleTargetHelper.java is not a "library" class, it's a part of tools/jlink/plugins/SystemModuleDescriptors/ tests. thanks for updating webrev, I have one nit --- given ModuleUtils is the only class in jdk/test/lib/module package, I doubt we need to introduce this package, ModuleUtils can be put into j.t.l.util package. -- Igor. > On Oct 10, 2018, at 11:31 PM, Hamlin Li wrote: > > Thank you clarifying Igor. > > Moving ModuleTargetHelper to local folder has a drawback: it's hard for future maintainer to found it if they need to use it in other places, that make it an "invisible" library class. > Although I don't fully agree with you, I have updated the webrev as you suggested: http://cr.openjdk.java.net/~mli/8186610/webrev.01/ > Thank you > > -Hamlin > > On 2018/10/11 11:38 AM, Igor Ignatyev wrote: >> b/c this will make test library modularization[1] somewhat troublesome, also I ain't sure if ModuleTargetHelper really needs to be placed into the top-level library regardless of its dependency on non-public API. "promoting" test library class to the top-level library comes w/ increased maintenance costs, the parent task[2] explains that in more details. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211358 >> [2] https://bugs.openjdk.java.net/browse/JDK-8211290 >> >> -- Igor >> >>> On Oct 10, 2018, at 8:26 PM, Hamlin Li > wrote: >>> >>> Hi Igor, >>> >>> Would you please clarify your concern further? I mean why ModuleTargetHelper can be put to top level when it use non-public APIs e.g. jdk.internal.module.*? >>> >>> Thank you >>> >>> -Hamlin >>> >>> On 2018/10/11 11:08 AM, Igor Ignatyev wrote: >>>> Hi Hamlin, >>>> >>>> as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common test library, and 8211976 suggests moving it closer to tests. could you please explain why you decided to put it into the library instead? >>>> >>>> Thanks, >>>> -- Igor >>>> >>>> ----- Original Message ----- >>>> From: huaming.li at oracle.com >>>> To: core-libs-dev at openjdk.java.net >>>> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada Pacific >>>> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary >>>> >>>> Would you please review the following patch? >>>> >>>> bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8186610 >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8211976 >>>> >>>> webrev: http://cr.openjdk.java.net/~mli/8186610/ >>>> >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>> >> > From igor.ignatyev at oracle.com Thu Oct 11 18:55:44 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 11:55:44 -0700 Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary In-Reply-To: <26823CE9-8C75-4AB3-9FCA-ED5B53960589@oracle.com> References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com> <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com> <26823CE9-8C75-4AB3-9FCA-ED5B53960589@oracle.com> Message-ID: Hi Max, we do have a plan to remove these deprecated methods as part of 8211289[1]. I don't know if there a flag which you can use to get all classes which use deprecated methods. you can however analyze source or bytecode of tests, to see if they have dependency on these methods, but again I ain't aware of tools (rather than grep) which can help you to do that in jtreg test suite. [1] https://bugs.openjdk.java.net/browse/JDK-8211289 -- Igor > On Oct 10, 2018, at 8:47 PM, Weijun Wang wrote: > > Do we have a plan to move away from the deprecated methods? Is there a flag I can set to check how many classes are using them? > > --Max > >> On Sep 30, 2018, at 11:00 PM, Alan Bateman wrote: >> >> On 27/09/2018 00:38, Igor Ignatyev wrote: >>> here is the webrevs w/ JarUtils from default package inserted into jdk.test.lib.util.JarUtils: >>> whole patch: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html >>>> 655 lines changed: 239 ins; 355 del; 61 mod; >>> incremental: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html >>>> 476 lines changed: 239 ins; 203 del; 34 mod; >>> >>> doing that, I noticed that both updateJarFile and createJarFile don't close Stream from Files::find, the current patch fixes that. >>> >> I see you've also deprecated the String methods in the old class - good! I'd probably carry over test/jdk/lib/testlibrary/JarUtils.java without changing the format but your IDE must be setup differently and it will get changed again by whoever next changes it so I think it's okay. >> >> The update to tests using this look fine. >> >> -Alan > From joe.darcy at oracle.com Thu Oct 11 19:12:15 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Oct 2018 12:12:15 -0700 Subject: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() In-Reply-To: References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> Message-ID: <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> Hi Werner, On 10/10/2018 1:23 PM, Werner Dietl wrote: > Hi Joe, all, > > the logic looks good to me. > > In the tests I'm wondering whether to include an annotated wildcard > bound. There is: > > 307 public @AnnotType(11) Set<@AnnotType(13) ? extends Number> > fooNumberSet2() {return null;} > > but nothing like > > Set fooNumberSet2() {return null;} > > I wouldn't expect problems for this, but a test would exercise some of > the code that gets added. You were correct to probe at the bounds on the wildcard components; the code that was reviewed and pushed does not print annotations on the bounds. I'll work on an update to handle this and similar cases where there are embedded types that could have annotations. Thanks, -Joe > > Best, > cu, WMD. > > > > > On Wed, Oct 10, 2018 at 2:40 AM Joel Borggr?n-Franck > wrote: >> Hej Joe, >> >> New version looks good! >> >> Thanks for the explanations, makes sense to me. >> >> Cheers >> /Joel >> >> On Wed, 10 Oct 2018 at 08:27, joe darcy wrote: >>> Hi Joel, >>> >>> Thanks for the review; slightly revised version at >>> >>> http://cr.openjdk.java.net/~darcy/8058202.3/ >>> >>> Comments below. >>> >>> >>> On 10/9/2018 11:00 AM, Joel Borggr?n-Franck wrote: >>>> Hi Joe, >>>> >>>> Good to see this happening. In general looks good to me, a few nits below. >>>> >>>> AnnotatedTypeBaseImpl contains comments indicating from which >>>> superclass or interface the overridden methods comes. I'd either add >>>> // Object at line 207 or delete line 145 and 177 for consistency. >>> Okay; comments added to follow that local convention. >>> >>>> Even though this isn't performance critical by far the allocation at >>>> line 215 still bugs me a bit given that the common case will most >>>> certainly be no annotations. >>> Sure; refactored to avoid the allocation. >>> >>>> Why the inverted logic line 250-253, IIRC you should be able to test >>>> if it is an AnnotatedBaseTypeImpl, or? >>> I was aiming to avoid testing for the impl class directly to not >>> directly tie the classes to this particular implementation of the >>> AnnotatedType hierarchy. However, inter-operability based on the specs >>> would need the equals and hashCode behavior to be defined. >>> >>>> For equalsTypeAndAnnotations and baseHashCode lines 232-244 equals >>>> test for owner type equality while hashcode doesn't include owner >>>> type. I must confess I no longer remember the equals-hashCode contract >>>> but I assume this is intentional. >>> Good catch; equals and hashCode checks made consistent. >>> >>> Some refactoring and hardening of the test included too. >>> >>> Delta-diffs below. >>> >>> Thanks, >>> >>> -Joe >>> >>> diff >>> webrev.2/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java >>> webrev/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java >>> >>> 2c2 >>> < * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights >>> reserved. >>> --- >>> > * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights >>> reserved. >>> 207c207 >>> < @Override >>> --- >>> > @Override // java.lang.Object >>> 215d214 >>> < StringJoiner sj = new StringJoiner(" "); >>> 216a216 >>> > StringJoiner sj = new StringJoiner(" "); >>> 228,229c228,231 >>> < } >>> < return sj.toString(); >>> --- >>> > return sj.toString(); >>> > } else { >>> > return ""; >>> > } >>> 244c246,247 >>> < Objects.hash((Object[])getAnnotations()); >>> --- >>> > Objects.hash((Object[])getAnnotations()) ^ >>> > Objects.hash(getAnnotatedOwnerType()); >>> >>> diff >>> webrev.2/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java >>> webrev/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java >>> >>> 142d141 >>> < >>> 157,168c156,158 >>> < AnnotatedType annotType1 = m.getAnnotatedReturnType(); >>> < AnnotatedType annotType2 = m.getAnnotatedReturnType(); >>> < >>> < boolean valid = annotType1.equals(annotType2); >>> < >>> < if (!valid) { >>> < errors++; >>> < System.err.println(annotType1); >>> < System.err.println(" is not equal to "); >>> < System.err.println(annotType2); >>> < System.err.println(); >>> < } >>> --- >>> > checkTypesForEquality(m.getAnnotatedReturnType(), >>> > m.getAnnotatedReturnType(), >>> > true); >>> 171a162,185 >>> > private static void checkTypesForEquality(AnnotatedType annotType1, >>> > AnnotatedType annotType2, >>> > boolean expected) { >>> > boolean comparison = annotType1.equals(annotType2); >>> > >>> > if (comparison) { >>> > int hash1 = annotType1.hashCode(); >>> > int hash2 = annotType1.hashCode(); >>> > if (hash1 != hash2) { >>> > errors++; >>> > System.err.format("Equal AnnotatedTypes with unequal hash >>> codes: %n%s%n%s%n", >>> > annotType1.toString(), annotType2.toString()); >>> > } >>> > } >>> > >>> > if (comparison != expected) { >>> > errors++; >>> > System.err.println(annotType1); >>> > System.err.println(expected ? " is not equal to " : " is >>> equal to "); >>> > System.err.println(annotType2); >>> > System.err.println(); >>> > } >>> > } >>> > >>> 184,196c198,200 >>> < AnnotatedType annotType1 = >>> methods[i].getAnnotatedReturnType(); >>> < AnnotatedType annotType2 = >>> methods[j].getAnnotatedReturnType(); >>> < >>> < boolean valid = !annotType1.equals(annotType2); >>> < >>> < if (!valid) { >>> < errors++; >>> < System.err.println(annotType1); >>> < System.err.println(" is equal to "); >>> < System.err.println(annotType2); >>> < System.err.println(); >>> < } >>> < >>> --- >>> > checkTypesForEquality(methods[i].getAnnotatedReturnType(), >>> > methods[j].getAnnotatedReturnType(), >>> > false); >>> 209,210c213 >>> < Method[] methods1 = clazz1.getDeclaredMethods(); >>> < Method[] methods2 = clazz2.getDeclaredMethods(); >>> --- >>> > System.err.println("Testing that presence/absence of >>> annotations matters for equals comparison."); >>> 212,226c215,230 >>> < // Skip 0th element since void cannoted be annotated >>> < for (int i = 1; i < methods1.length; i++) { >>> < AnnotatedType annotType1 = >>> methods1[i].getAnnotatedReturnType(); >>> < AnnotatedType annotType2 = >>> methods2[i].getAnnotatedReturnType(); >>> < >>> < boolean valid = !annotType1.equals(annotType2); >>> < >>> < if (!valid) { >>> < errors++; >>> < System.err.println(annotType1); >>> < System.err.println(" is equal to "); >>> < System.err.println(annotType2); >>> < System.err.println(); >>> < } >>> < } >>> --- >>> > String methodName = null; >>> > for (Method method : clazz1.getDeclaredMethods()) { >>> > if ("void".equals(method.getReturnType().toString())) { >>> > continue; >>> > } >>> > >>> > methodName = method.getName(); >>> > try { >>> > checkTypesForEquality(method.getAnnotatedReturnType(), >>> > clazz2.getDeclaredMethod(methodName).getAnnotatedReturnType(), >>> > false); >>> > } catch (Exception e) { >>> > errors++; >>> > System.err.println("Method " + methodName + " not found."); >>> > } >>> > } >>> 230a235 >>> > System.err.println("Testing wildcards"); >>> 242,248c247 >>> < if (awt1.equals(awt2)) { >>> < errors++; >>> < System.err.println(awt1); >>> < System.err.println(" is equal to "); >>> < System.err.println(awt2); >>> < System.err.println(); >>> < } >>> --- >>> > checkTypesForEquality(awt1, awt2, false); >>> 254d252 >>> < > > From Roger.Riggs at oracle.com Thu Oct 11 19:14:54 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Oct 2018 15:14:54 -0400 Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary In-Reply-To: References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com> <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com> <26823CE9-8C75-4AB3-9FCA-ED5B53960589@oracle.com> Message-ID: Hi Igor, The IDEs including IntelliJ can pretty easily search for usages of various methods whereever they occur in the source tree. And they can do the refactoring as well. $.02, Roger On 10/11/2018 02:55 PM, Igor Ignatyev wrote: > Hi Max, > > we do have a plan to remove these deprecated methods as part of 8211289[1]. > > I don't know if there a flag which you can use to get all classes which use deprecated methods. you can however analyze source or bytecode of tests, to see if they have dependency on these methods, but again I ain't aware of tools (rather than grep) which can help you to do that in jtreg test suite. > > [1] https://bugs.openjdk.java.net/browse/JDK-8211289 > > -- Igor > >> On Oct 10, 2018, at 8:47 PM, Weijun Wang wrote: >> >> Do we have a plan to move away from the deprecated methods? Is there a flag I can set to check how many classes are using them? >> >> --Max >> >>> On Sep 30, 2018, at 11:00 PM, Alan Bateman wrote: >>> >>> On 27/09/2018 00:38, Igor Ignatyev wrote: >>>> here is the webrevs w/ JarUtils from default package inserted into jdk.test.lib.util.JarUtils: >>>> whole patch: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html >>>>> 655 lines changed: 239 ins; 355 del; 61 mod; >>>> incremental: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html >>>>> 476 lines changed: 239 ins; 203 del; 34 mod; >>>> doing that, I noticed that both updateJarFile and createJarFile don't close Stream from Files::find, the current patch fixes that. >>>> >>> I see you've also deprecated the String methods in the old class - good! I'd probably carry over test/jdk/lib/testlibrary/JarUtils.java without changing the format but your IDE must be setup differently and it will get changed again by whoever next changes it so I think it's okay. >>> >>> The update to tests using this look fine. >>> >>> -Alan -- Thanks, Roger From igor.ignatyev at oracle.com Thu Oct 11 19:22:42 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 12:22:42 -0700 Subject: RFR(M) : 8211171 : move JarUtils to top-level testlibrary In-Reply-To: References: <813D7BB2-3D15-4517-9B0E-D205065DBFF6@oracle.com> <6ad225f4-adfa-8466-aa67-804ce055be82@oracle.com> <26823CE9-8C75-4AB3-9FCA-ED5B53960589@oracle.com> Message-ID: <1B3FEEC9-273A-4D2B-A946-438D5A8A1001@oracle.com> Hi Roger, that's true, but due to layout of tests in jtreg test suites, it requires special configurations and still doesn't work in all cases. with that being said, in case of JarUtils methods, it should work fine. -- Igor > On Oct 11, 2018, at 12:14 PM, Roger Riggs wrote: > > Hi Igor, > > The IDEs including IntelliJ can pretty easily search for usages of various methods > whereever they occur in the source tree. And they can do the refactoring as well. > > $.02, Roger > > On 10/11/2018 02:55 PM, Igor Ignatyev wrote: >> Hi Max, >> >> we do have a plan to remove these deprecated methods as part of 8211289[1]. >> >> I don't know if there a flag which you can use to get all classes which use deprecated methods. you can however analyze source or bytecode of tests, to see if they have dependency on these methods, but again I ain't aware of tools (rather than grep) which can help you to do that in jtreg test suite. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8211289 >> >> -- Igor >> >>> On Oct 10, 2018, at 8:47 PM, Weijun Wang wrote: >>> >>> Do we have a plan to move away from the deprecated methods? Is there a flag I can set to check how many classes are using them? >>> >>> --Max >>> >>>> On Sep 30, 2018, at 11:00 PM, Alan Bateman wrote: >>>> >>>> On 27/09/2018 00:38, Igor Ignatyev wrote: >>>>> here is the webrevs w/ JarUtils from default package inserted into jdk.test.lib.util.JarUtils: >>>>> whole patch: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.01/index.html >>>>>> 655 lines changed: 239 ins; 355 del; 61 mod; >>>>> incremental: http://cr.openjdk.java.net/~iignatyev//8211171/webrev.0-1/index.html >>>>>> 476 lines changed: 239 ins; 203 del; 34 mod; >>>>> doing that, I noticed that both updateJarFile and createJarFile don't close Stream from Files::find, the current patch fixes that. >>>>> >>>> I see you've also deprecated the String methods in the old class - good! I'd probably carry over test/jdk/lib/testlibrary/JarUtils.java without changing the format but your IDE must be setup differently and it will get changed again by whoever next changes it so I think it's okay. >>>> >>>> The update to tests using this look fine. >>>> >>>> -Alan > > -- > Thanks, Roger From kim.barrett at oracle.com Thu Oct 11 19:23:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 11 Oct 2018 15:23:03 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: > On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov wrote: > > Kim, > > Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. My impression is that most of these were not toolchain issues per se. Rather, they were broken or incomplete changes in platform-dependent code that weren't tested on these "alternative" platforms before being pushed. Oracle has provided dev-submit so that non-Oracle folks can do some minimal testing on all the platforms that Oracle supports. I know that I would sometimes like to have similarly "easy" testing for various platforms not supported by Oracle. I didn't suggest "no testing" if there is a compiler version that supports the new language standards but has not yet been fully product-qualified by the people who are using it. I think gcc on arm may be in that category. But I think it would be very disappointing if the complete lack of a usable version of some compiler were to completely block us in this area. (Unfortunately, such a lack appears to be the situation for XLC compiler used for the AIX/ppc port.) The proposal is not very aggressive. > We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. I'm understand that it takes time and effort to do a toolchain upgrade. And turning on support for new language version without changing the toolchain version isn't really all that different. This proposal didn't suddenly appear out of nowhere. There has been wistful discussion about using new language features for a long time, with an understanding that going anywhere with that was difficult because of some popular toolchain deficiencies (notably MSVC++) and the need to upgrade others. There have been ongoing efforts in this direction, e.g. various changes to support building with C++11/14 support enabled. Oracle made toolchain upgrades in JDK 11, in part to support the language standard change. (Unfortunately, the relevant toolchain upgrade JEP was labelled "Confidential", even though a lot of the work was in the open, and some of it was explicitly about dealing with differences arising from turning on C++11/14.) I think JDK 12 for this JEP is reasonable goal at this stage. Of course, that goal might not be achieved, for a variety of reasons. That's why it is not yet in the Targeted state and why there is a formal process for moving to that state; there's still work to be done, and we'll have to see how that work proceeds. > With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. From mandy.chung at oracle.com Thu Oct 11 19:36:20 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Oct 2018 12:36:20 -0700 Subject: RFR [12] - 8211960: broken links in java.util.logging In-Reply-To: <0614fc03-cee6-6eb3-0354-6507ef5cadc2@oracle.com> References: <265652cb-0c8e-c64a-76bb-9122be9b56f7@oracle.com> <11dbe820-4dff-5801-4628-aa8dd392b79b@oracle.com> <0614fc03-cee6-6eb3-0354-6507ef5cadc2@oracle.com> Message-ID: <7f2dc2e8-9a25-eca6-f084-6782b20783ec@oracle.com> On 10/11/18 4:54 AM, Daniel Fuchs wrote: > Hi Mandy, > > On 10/10/2018 17:56, Mandy Chung wrote: >> The javadoc of SimpleFormatter::format(LogRecord) method does >> describe the format argument is a java.util.Formatter format string. >> Also the class description also links to this method.? So I think these >> two broken links can simply be removed and the spec about the formatting >> is in the SimpleFormatter::format method javadoc.? What do you think? > > > I agree, this is probably the better solution: > > http://cr.openjdk.java.net/~dfuchs/webrev_8211960/webrev.01/index.html Looks good. + * @see #format(LogRecord) This might not be needed since it's linked from {@linkplain #format(LogRecord) format} the log messages. No need for a new webrev. Thanks Mandy From mandy.chung at oracle.com Thu Oct 11 19:55:30 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 11 Oct 2018 12:55:30 -0700 Subject: RFR 8192939: Remove Finalize methods from FileInputStream and FileOutputStream In-Reply-To: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> References: <25bf7660-7a8c-bceb-a671-907115f0f300@oracle.com> Message-ID: <1c59fb5c-f3e8-4ba7-2048-bf5a769b806b@oracle.com> On 10/11/18 9:58 AM, Roger Riggs wrote: > The finalizer methods of FileInputStream and FileOutputStream were > deprecated for removal > in JDK 9 and its time to remove them and the alternate mechanism to > call close > when the streams are found to be unreachable.? The Cleaner has been > used since JDK 9 to > close file descriptors that become unreferenced. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-io-finalize-8192939/index.html > > CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8212050 Looks good. Mandy From volker.simonis at gmail.com Thu Oct 11 20:59:49 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 11 Oct 2018 22:59:49 +0200 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* In-Reply-To: <1025735f-94ca-12a3-78f8-b895fb1b4b2e@oracle.com> References: <1025735f-94ca-12a3-78f8-b895fb1b4b2e@oracle.com> Message-ID: Jonathan Gibbons schrieb am Do. 11. Okt. 2018 um 19:16: > Volker, > > It's a typo/oops on my part. I'll fix it. > Hi John, thanks for looking at this issue! What do you mean with ? typo?? Returning null instead of the string ?null?? That would ?fix? the corresponding tests in the sense that they would run again, however still with bogus results for all the @requires guards which check the ?vm.opt.*? options. Shouldn?t we fix that as well? Regards, Volker > -- Jon > > > On 10/11/18 10:13 AM, Jonathan Gibbons wrote: > > Volker, > > > > Thanks for the report. I'll take a look shortly. > > > > -- Jon > > > > > > On 10/11/18 10:01 AM, Volker Simonis wrote: > >> Hi, > >> > >> the change "CODETOOLS-7902290: introduce error state of @requires > >> properties" [1] which was recently pushed to the codetools repo, > >> breaks all JTreg tests which have a require clause that queries a non > >> final (i.e. no "vm.opt.final") VM option. > >> > >> For example the test > >> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which > >> uses "@requires vm.opt.DeoptimizeALot != true" will now fail with: > >> > >> test result: Error. Error evaluating expression: name not defined: > >> vm.opt.DeoptimizeALot > >> > >> This is because > >> com.sun.javatest.regtest.config.RegressionContext.get() was changed to > >> return null instead of the string "null" for unknown properties. > >> Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot" > >> is indeed not defined (as many other "vm.opt" properties, see below). > >> So it turns out that all the tests which @required a "vm.opt" option > >> did run in a faulty configuration until now. > >> > >> I could for example easily fix > >> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding > >> the corresponding option in VMProps.java: > >> > >> $ hg diff > >> diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java > >> --- a/test/jtreg-ext/requires/VMProps.java Thu Oct 11 10:11:18 > >> 2018 -0400 > >> +++ b/test/jtreg-ext/requires/VMProps.java Thu Oct 11 18:51:37 > >> 2018 +0200 > >> @@ -266,6 +266,8 @@ > >> vmOptFinalFlag(map, "ClassUnloading"); > >> vmOptFinalFlag(map, "UseCompressedOops"); > >> vmOptFinalFlag(map, "EnableJVMCI"); > >> + String value = > >> String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot")); > >> + map.put("vm.opt.DeoptimizeALot", value); > >> } > >> > >> Following is a list of all "vm.opt" options used in @requires clauses > >> without being defined in VMProps.java: > >> > >> vm.opt.AggressiveOpts > >> vm.opt.ClassUnloading > >> vm.opt.ClassUnloadingWithConcurrentMark > >> vm.opt.DeoptimizeALot > >> vm.opt.DisableExplicitGC > >> vm.opt.ExplicitGCInvokesConcurrent > >> vm.opt.FlightRecorder > >> vm.opt.G1HeapRegionSize > >> vm.opt.Inline > >> vm.opt.MaxGCPauseMillis > >> vm.opt.StartFlightRecording > >> vm.opt.SurvivorAlignmentInBytes > >> vm.opt.TieredCompilation > >> vm.opt.TieredStopAtLevel > >> vm.opt.TieredStopAtLevel==4) > >> vm.opt.TieredStopAtLevel==null > >> vm.opt.UseJVMCICompiler > >> > >> What's the current plan? Do we want to add all these options in > >> VMProps.java? Or should we better add all the -XX VM options together > >> to VMProps such that they can all be freely used within @requires > >> clauses? > >> > >> Thank you and best regards, > >> Volker > >> > >> PS: I've noticed that there's "8209807: improve handling exception in > >> requires.VMProps" [2] to apparently adapt VMProps.java to > >> CODETOOLS-7902290 but I've tried the attached webrev and it doesn't > >> help with the described problem. > >> > >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 > >> [2] https://bugs.openjdk.java.net/browse/JDK-8209807 > > > > From igor.ignatyev at oracle.com Thu Oct 11 21:09:30 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 14:09:30 -0700 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* In-Reply-To: References: <1025735f-94ca-12a3-78f8-b895fb1b4b2e@oracle.com> Message-ID: Hi Volker, vm.opt.* options are set by jtreg (RegressionContext::processVMOptions), and their value is expected to be "null" if a flag hasn't been passed to JDK under tests via -javaoptions or -vmoptions. I don't think there is something to fix (at least not in jtreg). -- Igor > On Oct 11, 2018, at 1:59 PM, Volker Simonis wrote: > > Jonathan Gibbons schrieb am Do. 11. Okt. 2018 > um 19:16: > >> Volker, >> >> It's a typo/oops on my part. I'll fix it. >> > > Hi John, > > thanks for looking at this issue! > > What do you mean with ? typo?? Returning null instead of the string ?null?? > > That would ?fix? the corresponding tests in the sense that they would run > again, however still with bogus results for all the @requires guards which > check the ?vm.opt.*? options. Shouldn?t we fix that as well? > > Regards, > Volker > > > >> -- Jon >> >> >> On 10/11/18 10:13 AM, Jonathan Gibbons wrote: >>> Volker, >>> >>> Thanks for the report. I'll take a look shortly. >>> >>> -- Jon >>> >>> >>> On 10/11/18 10:01 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> the change "CODETOOLS-7902290: introduce error state of @requires >>>> properties" [1] which was recently pushed to the codetools repo, >>>> breaks all JTreg tests which have a require clause that queries a non >>>> final (i.e. no "vm.opt.final") VM option. >>>> >>>> For example the test >>>> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which >>>> uses "@requires vm.opt.DeoptimizeALot != true" will now fail with: >>>> >>>> test result: Error. Error evaluating expression: name not defined: >>>> vm.opt.DeoptimizeALot >>>> >>>> This is because >>>> com.sun.javatest.regtest.config.RegressionContext.get() was changed to >>>> return null instead of the string "null" for unknown properties. >>>> Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot" >>>> is indeed not defined (as many other "vm.opt" properties, see below). >>>> So it turns out that all the tests which @required a "vm.opt" option >>>> did run in a faulty configuration until now. >>>> >>>> I could for example easily fix >>>> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding >>>> the corresponding option in VMProps.java: >>>> >>>> $ hg diff >>>> diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java >>>> --- a/test/jtreg-ext/requires/VMProps.java Thu Oct 11 10:11:18 >>>> 2018 -0400 >>>> +++ b/test/jtreg-ext/requires/VMProps.java Thu Oct 11 18:51:37 >>>> 2018 +0200 >>>> @@ -266,6 +266,8 @@ >>>> vmOptFinalFlag(map, "ClassUnloading"); >>>> vmOptFinalFlag(map, "UseCompressedOops"); >>>> vmOptFinalFlag(map, "EnableJVMCI"); >>>> + String value = >>>> String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot")); >>>> + map.put("vm.opt.DeoptimizeALot", value); >>>> } >>>> >>>> Following is a list of all "vm.opt" options used in @requires clauses >>>> without being defined in VMProps.java: >>>> >>>> vm.opt.AggressiveOpts >>>> vm.opt.ClassUnloading >>>> vm.opt.ClassUnloadingWithConcurrentMark >>>> vm.opt.DeoptimizeALot >>>> vm.opt.DisableExplicitGC >>>> vm.opt.ExplicitGCInvokesConcurrent >>>> vm.opt.FlightRecorder >>>> vm.opt.G1HeapRegionSize >>>> vm.opt.Inline >>>> vm.opt.MaxGCPauseMillis >>>> vm.opt.StartFlightRecording >>>> vm.opt.SurvivorAlignmentInBytes >>>> vm.opt.TieredCompilation >>>> vm.opt.TieredStopAtLevel >>>> vm.opt.TieredStopAtLevel==4) >>>> vm.opt.TieredStopAtLevel==null >>>> vm.opt.UseJVMCICompiler >>>> >>>> What's the current plan? Do we want to add all these options in >>>> VMProps.java? Or should we better add all the -XX VM options together >>>> to VMProps such that they can all be freely used within @requires >>>> clauses? >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> PS: I've noticed that there's "8209807: improve handling exception in >>>> requires.VMProps" [2] to apparently adapt VMProps.java to >>>> CODETOOLS-7902290 but I've tried the attached webrev and it doesn't >>>> help with the described problem. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8209807 >>> >> >> From huaming.li at oracle.com Fri Oct 12 00:54:51 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 12 Oct 2018 08:54:51 +0800 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: <91B13BAD-2CCE-4CEA-B89D-D4D5D620F406@oracle.com> References: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> <51f9c3e8-8d33-0b0b-271e-150a5784317c@oracle.com> <91B13BAD-2CCE-4CEA-B89D-D4D5D620F406@oracle.com> Message-ID: Hi Igor, It's updated in place http://cr.openjdk.java.net/~mli/8186610/webrev.01/, please help to review again/./ Thank you -Hamlin On 2018/10/12 2:51 AM, Igor Ignatyev wrote: > Hi Hamlin, > > the key point here,?ModuleTargetHelper.java is not a "library" class, > it's a part of?tools/jlink/plugins/SystemModuleDescriptors/ tests. > > thanks for updating webrev, I have one nit --- given?ModuleUtils is > the only class in?jdk/test/lib/module package, I doubt we need to > introduce this package, ModuleUtils can be put into j.t.l.util package. > > -- Igor. > >> On Oct 10, 2018, at 11:31 PM, Hamlin Li > > wrote: >> >> Thank you clarifying Igor. >> >> Moving ModuleTargetHelper to local folder has a drawback: it's hard >> for future maintainer to found it if they need to use it in other >> places, that make it an "*invisible*" library class. >> >> Although I don't fully agree with you, I have updated the webrev as >> you suggested: http://cr.openjdk.java.net/~mli/8186610/webrev.01/ >> >> Thank you >> >> -Hamlin >> >> >> On 2018/10/11 11:38 AM, Igor Ignatyev wrote: >>> b/c this will make test library modularization[1] somewhat >>> troublesome, also I ain't sure if ModuleTargetHelper really needs to >>> be placed into the top-level library regardless of its dependency on >>> non-public API. "promoting" test library class to the top-level >>> library comes w/ increased maintenance costs, the parent task[2] >>> explains that in more details. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8211358 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8211290 >>> >>> -- Igor >>> >>>> On Oct 10, 2018, at 8:26 PM, Hamlin Li >>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> Would you please clarify your concern further? I mean why >>>> ModuleTargetHelper can be put to top level when it use non-public >>>> APIs e.g. jdk.internal.module.*? >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>>> On 2018/10/11 11:08 AM, Igor Ignatyev wrote: >>>>> Hi Hamlin, >>>>> >>>>> as ModuleTargetHelper uses non-public API, I'd prefer not to have >>>>> in a common test library, and 8211976 suggests moving it closer to >>>>> tests. could you please explain why you decided to put it into the >>>>> library instead? >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>> ----- Original Message ----- >>>>> From: huaming.li at oracle.com >>>>> To: core-libs-dev at openjdk.java.net >>>>> >>>>> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada >>>>> Pacific >>>>> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary >>>>> >>>>> Would you please review the following patch? >>>>> >>>>> bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8186610 >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8211976 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mli/8186610/ >>>>> >>>>> >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>> >>> >> > From joe.darcy at oracle.com Fri Oct 12 01:11:44 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Oct 2018 18:11:44 -0700 Subject: JDK 12 RFR of JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods Message-ID: Hello, Prompted by recent work on the toString implementations of AnnotatedType objects (http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055937.html), I rediscovered a long-standing limitation of toGenericString on Type objects that can be addressed: ??? JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods Please review the small CSR ??? https://bugs.openjdk.java.net/browse/JDK-8212094 and webrev: ??? http://cr.openjdk.java.net/~darcy/6304578.0/ Thanks, -Joe From igor.ignatyev at oracle.com Fri Oct 12 01:31:08 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 18:31:08 -0700 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: References: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> <51f9c3e8-8d33-0b0b-271e-150a5784317c@oracle.com> <91B13BAD-2CCE-4CEA-B89D-D4D5D620F406@oracle.com> Message-ID: LGTM -- Igor > On Oct 11, 2018, at 5:54 PM, Hamlin Li wrote: > > Hi Igor, > > It's updated in place http://cr.openjdk.java.net/~mli/8186610/webrev.01/ , please help to review again. > > Thank you > > -Hamlin > > On 2018/10/12 2:51 AM, Igor Ignatyev wrote: >> Hi Hamlin, >> >> the key point here, ModuleTargetHelper.java is not a "library" class, it's a part of tools/jlink/plugins/SystemModuleDescriptors/ tests. >> >> thanks for updating webrev, I have one nit --- given ModuleUtils is the only class in jdk/test/lib/module package, I doubt we need to introduce this package, ModuleUtils can be put into j.t.l.util package. >> >> -- Igor. >> >>> On Oct 10, 2018, at 11:31 PM, Hamlin Li > wrote: >>> >>> Thank you clarifying Igor. >>> >>> Moving ModuleTargetHelper to local folder has a drawback: it's hard for future maintainer to found it if they need to use it in other places, that make it an "invisible" library class. >>> Although I don't fully agree with you, I have updated the webrev as you suggested: http://cr.openjdk.java.net/~mli/8186610/webrev.01/ >>> Thank you >>> >>> -Hamlin >>> >>> On 2018/10/11 11:38 AM, Igor Ignatyev wrote: >>>> b/c this will make test library modularization[1] somewhat troublesome, also I ain't sure if ModuleTargetHelper really needs to be placed into the top-level library regardless of its dependency on non-public API. "promoting" test library class to the top-level library comes w/ increased maintenance costs, the parent task[2] explains that in more details. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8211358 >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8211290 >>>> >>>> -- Igor >>>> >>>>> On Oct 10, 2018, at 8:26 PM, Hamlin Li > wrote: >>>>> >>>>> Hi Igor, >>>>> >>>>> Would you please clarify your concern further? I mean why ModuleTargetHelper can be put to top level when it use non-public APIs e.g. jdk.internal.module.*? >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>>> On 2018/10/11 11:08 AM, Igor Ignatyev wrote: >>>>>> Hi Hamlin, >>>>>> >>>>>> as ModuleTargetHelper uses non-public API, I'd prefer not to have in a common test library, and 8211976 suggests moving it closer to tests. could you please explain why you decided to put it into the library instead? >>>>>> >>>>>> Thanks, >>>>>> -- Igor >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: huaming.li at oracle.com >>>>>> To: core-libs-dev at openjdk.java.net >>>>>> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada Pacific >>>>>> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary >>>>>> >>>>>> Would you please review the following patch? >>>>>> >>>>>> bug: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8186610 >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8211976 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~mli/8186610/ >>>>>> >>>>>> >>>>>> Thank you >>>>>> >>>>>> -Hamlin >>>>>> >>>>> >>>> >>> >> > From fenix_young at hotmail.com Fri Oct 12 03:09:28 2018 From: fenix_young at hotmail.com (xiaofeng Young) Date: Fri, 12 Oct 2018 03:09:28 +0000 Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary In-Reply-To: References: <6a0aae74-77c0-5d10-4d50-baa9db6fce10@oracle.com> <3E633FDD-9B34-436F-A507-EB5441E920E0@oracle.com> <51f9c3e8-8d33-0b0b-271e-150a5784317c@oracle.com> <91B13BAD-2CCE-4CEA-B89D-D4D5D620F406@oracle.com>, Message-ID: Hi Hamlin, the patch looks good, just note to update Copyright dates. -Felix Yang ________________________________ From: core-libs-dev on behalf of Hamlin Li Sent: Friday, October 12, 2018 8:54:51 AM To: Igor Ignatyev Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary Hi Igor, It's updated in place http://cr.openjdk.java.net/~mli/8186610/webrev.01/, please help to review again/./ Thank you -Hamlin On 2018/10/12 2:51 AM, Igor Ignatyev wrote: > Hi Hamlin, > > the key point here, ModuleTargetHelper.java is not a "library" class, > it's a part of tools/jlink/plugins/SystemModuleDescriptors/ tests. > > thanks for updating webrev, I have one nit --- given ModuleUtils is > the only class in jdk/test/lib/module package, I doubt we need to > introduce this package, ModuleUtils can be put into j.t.l.util package. > > -- Igor. > >> On Oct 10, 2018, at 11:31 PM, Hamlin Li > > wrote: >> >> Thank you clarifying Igor. >> >> Moving ModuleTargetHelper to local folder has a drawback: it's hard >> for future maintainer to found it if they need to use it in other >> places, that make it an "*invisible*" library class. >> >> Although I don't fully agree with you, I have updated the webrev as >> you suggested: http://cr.openjdk.java.net/~mli/8186610/webrev.01/ >> >> Thank you >> >> -Hamlin >> >> >> On 2018/10/11 11:38 AM, Igor Ignatyev wrote: >>> b/c this will make test library modularization[1] somewhat >>> troublesome, also I ain't sure if ModuleTargetHelper really needs to >>> be placed into the top-level library regardless of its dependency on >>> non-public API. "promoting" test library class to the top-level >>> library comes w/ increased maintenance costs, the parent task[2] >>> explains that in more details. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8211358 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8211290 >>> >>> -- Igor >>> >>>> On Oct 10, 2018, at 8:26 PM, Hamlin Li >>> > wrote: >>>> >>>> Hi Igor, >>>> >>>> Would you please clarify your concern further? I mean why >>>> ModuleTargetHelper can be put to top level when it use non-public >>>> APIs e.g. jdk.internal.module.*? >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >>>> On 2018/10/11 11:08 AM, Igor Ignatyev wrote: >>>>> Hi Hamlin, >>>>> >>>>> as ModuleTargetHelper uses non-public API, I'd prefer not to have >>>>> in a common test library, and 8211976 suggests moving it closer to >>>>> tests. could you please explain why you decided to put it into the >>>>> library instead? >>>>> >>>>> Thanks, >>>>> -- Igor >>>>> >>>>> ----- Original Message ----- >>>>> From: huaming.li at oracle.com >>>>> To: core-libs-dev at openjdk.java.net >>>>> >>>>> Sent: Wednesday, October 10, 2018 7:40:34 PM GMT -08:00 US/Canada >>>>> Pacific >>>>> Subject: RFR of JDK-8186610,move ModuleUtils to top-level testlibrary >>>>> >>>>> Would you please review the following patch? >>>>> >>>>> bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8186610 >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8211976 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mli/8186610/ >>>>> >>>>> >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>>> >>> >> > From huaming.li at oracle.com Fri Oct 12 05:23:38 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 12 Oct 2018 13:23:38 +0800 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary Message-ID: would you please review the following patch? bug: ? https://bugs.openjdk.java.net/browse/JDK-8211974 ? https://bugs.openjdk.java.net/browse/JDK-8211972 ? https://bugs.openjdk.java.net/browse/JDK-8211973 ? https://bugs.openjdk.java.net/browse/JDK-8211979 webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ Thank you -Hamlin From igor.ignatyev at oracle.com Fri Oct 12 05:34:59 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Oct 2018 22:34:59 -0700 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary In-Reply-To: References: Message-ID: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> Hi Hamlin, could you please move jdk.test.lib.util.Compiler to j.t.l.compiler package? we use this package for classes which have dependency on jdk.compiler and/or java.compiler module. it'd also be nice to put CreateMultiReleaseTestJars into a named package. -- Igor > On Oct 11, 2018, at 10:23 PM, Hamlin Li wrote: > > would you please review the following patch? > > bug: > > https://bugs.openjdk.java.net/browse/JDK-8211974 > > https://bugs.openjdk.java.net/browse/JDK-8211972 > > https://bugs.openjdk.java.net/browse/JDK-8211973 > > https://bugs.openjdk.java.net/browse/JDK-8211979 > > webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ > > Thank you > > -Hamlin > From huaming.li at oracle.com Fri Oct 12 06:00:21 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 12 Oct 2018 14:00:21 +0800 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary In-Reply-To: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> References: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> Message-ID: <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> Hi Igor, It's updated in place http://cr.openjdk.java.net/~mli/8211974/webrev.00/, please review it again. Thank you -Hamlin On 2018/10/12 1:34 PM, Igor Ignatyev wrote: > Hi Hamlin, > > could you please move jdk.test.lib.util.Compiler to j.t.l.compiler package? we use this package for classes which have dependency on jdk.compiler and/or java.compiler module. > > it'd also be nice to put CreateMultiReleaseTestJars into a named package. > > -- Igor > >> On Oct 11, 2018, at 10:23 PM, Hamlin Li wrote: >> >> would you please review the following patch? >> >> bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8211974 >> >> https://bugs.openjdk.java.net/browse/JDK-8211972 >> >> https://bugs.openjdk.java.net/browse/JDK-8211973 >> >> https://bugs.openjdk.java.net/browse/JDK-8211979 >> >> webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ >> >> Thank you >> >> -Hamlin >> From amy.lu at oracle.com Fri Oct 12 06:13:52 2018 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 12 Oct 2018 14:13:52 +0800 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary In-Reply-To: <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> References: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> Message-ID: Hi, Hamlin - test/lib/jdk/test/lib/compiler/Compiler.java (was test/jdk/lib/testlibrary/java/util/jar/Compiler.java) Any future plan to "merge" it with existing jdk.test.lib.compiler.CompilerUtils? - test/lib/jdk/test/lib/util/JarBuilder.java (was test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java) Any future plan to "merge" it with existing jdk.test.lib.util.JarUtils? Thanks, Amy On 2018/10/12 2:00 PM, Hamlin Li wrote: > Hi Igor, > > It's updated in place > http://cr.openjdk.java.net/~mli/8211974/webrev.00/, please review it > again. > > Thank you > > -Hamlin > > > On 2018/10/12 1:34 PM, Igor Ignatyev wrote: >> Hi Hamlin, >> >> could you please move jdk.test.lib.util.Compiler to j.t.l.compiler >> package? we use this package for classes which have dependency on >> jdk.compiler and/or java.compiler module. >> >> it'd also be nice to put CreateMultiReleaseTestJars into a named >> package. >> >> -- Igor >>> On Oct 11, 2018, at 10:23 PM, Hamlin Li wrote: >>> >>> would you please review the following patch? >>> >>> bug: >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211974 >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211972 >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211973 >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211979 >>> >>> webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ >>> >>> Thank you >>> >>> -Hamlin >>> > From huaming.li at oracle.com Fri Oct 12 06:16:21 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 12 Oct 2018 14:16:21 +0800 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary In-Reply-To: References: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> Message-ID: <8c42eba3-1254-b95c-4f80-720fa8d065ec@oracle.com> yes, e.g. https://bugs.openjdk.java.net/browse/JDK-8212033 Thank you -Hamlin On 2018/10/12 2:13 PM, Amy Lu wrote: > Hi, Hamlin > > - test/lib/jdk/test/lib/compiler/Compiler.java (was > test/jdk/lib/testlibrary/java/util/jar/Compiler.java) > Any future plan to "merge" it with existing > jdk.test.lib.compiler.CompilerUtils? > > - test/lib/jdk/test/lib/util/JarBuilder.java (was > test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java) > Any future plan to "merge" it with existing jdk.test.lib.util.JarUtils? > > Thanks, > Amy > > On 2018/10/12 2:00 PM, Hamlin Li wrote: >> Hi Igor, >> >> It's updated in place >> http://cr.openjdk.java.net/~mli/8211974/webrev.00/, please review it >> again. >> >> Thank you >> >> -Hamlin >> >> >> On 2018/10/12 1:34 PM, Igor Ignatyev wrote: >>> Hi Hamlin, >>> >>> could you please move jdk.test.lib.util.Compiler to j.t.l.compiler >>> package? we use this package for classes which have dependency on >>> jdk.compiler and/or java.compiler module. >>> >>> it'd also be nice to put CreateMultiReleaseTestJars into a named >>> package. >>> >>> -- Igor >>>> On Oct 11, 2018, at 10:23 PM, Hamlin Li wrote: >>>> >>>> would you please review the following patch? >>>> >>>> bug: >>>> >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211974 >>>> >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211972 >>>> >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211973 >>>> >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211979 >>>> >>>> webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ >>>> >>>> Thank you >>>> >>>> -Hamlin >>>> >> > From amy.lu at oracle.com Fri Oct 12 06:28:37 2018 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 12 Oct 2018 14:28:37 +0800 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary In-Reply-To: <8c42eba3-1254-b95c-4f80-720fa8d065ec@oracle.com> References: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> <8c42eba3-1254-b95c-4f80-720fa8d065ec@oracle.com> Message-ID: <40332e2b-770a-5059-f889-d52798e57ad5@oracle.com> On 2018/10/12 2:16 PM, Hamlin Li wrote: > yes, e.g. https://bugs.openjdk.java.net/browse/JDK-8212033 It seems mentioned bug is duplicate with JDK-8211972: remove testlibrary/java/util/jar/Compiler.java - "suggest removing and using jdk.test.lib.compiler.InMemoryJavaCompiler instead" which is included in this changeset. Thanks, Amy > > Thank you > > -Hamlin > > > On 2018/10/12 2:13 PM, Amy Lu wrote: >> Hi, Hamlin >> >> - test/lib/jdk/test/lib/compiler/Compiler.java (was >> test/jdk/lib/testlibrary/java/util/jar/Compiler.java) >> Any future plan to "merge" it with existing >> jdk.test.lib.compiler.CompilerUtils? >> >> - test/lib/jdk/test/lib/util/JarBuilder.java (was >> test/jdk/lib/testlibrary/java/util/jar/JarBuilder.java) >> Any future plan to "merge" it with existing jdk.test.lib.util.JarUtils? >> >> Thanks, >> Amy >> >> On 2018/10/12 2:00 PM, Hamlin Li wrote: >>> Hi Igor, >>> >>> It's updated in place >>> http://cr.openjdk.java.net/~mli/8211974/webrev.00/, please review it >>> again. >>> >>> Thank you >>> >>> -Hamlin >>> >>> >>> On 2018/10/12 1:34 PM, Igor Ignatyev wrote: >>>> Hi Hamlin, >>>> >>>> could you please move jdk.test.lib.util.Compiler to j.t.l.compiler >>>> package? we use this package for classes which have dependency on >>>> jdk.compiler and/or java.compiler module. >>>> >>>> it'd also be nice to put CreateMultiReleaseTestJars into a named >>>> package. >>>> >>>> -- Igor >>>>> On Oct 11, 2018, at 10:23 PM, Hamlin Li >>>>> wrote: >>>>> >>>>> would you please review the following patch? >>>>> >>>>> bug: >>>>> >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211974 >>>>> >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211972 >>>>> >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211973 >>>>> >>>>> ?? https://bugs.openjdk.java.net/browse/JDK-8211979 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ >>>>> >>>>> Thank you >>>>> >>>>> -Hamlin >>>>> >>> >> > From matthias.baesken at sap.com Fri Oct 12 06:57:22 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Oct 2018 06:57:22 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: I got the info that the GA of Windows Server 2019 has build number 17763 . Should I update the webrev to check this build number (would mean we do not detect the preview as Windows Server 2019) , or keep it the way it is ? Current webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ Best regards, Matthias > > Hello Bob, > > > Hi Bob, > > no problem , we can wait a few days until the final version of Win > server > > 2019 is out, and check the buildNumber again : > > > > seems Windows server 2019 is GA now : > > > https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows- > server-2019-now-generally-available/ > > > > We don?t usually add logic to the JDK related to unreleased operating > system > > > previews. > > > so I think we can process with the review . > Still have to find out the buildNumber of the GA version, probably it has been > incremented again . > > > > > > > > > Bug/webrev : > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8211106 > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ > > > > > > > > > > > > Thanks, Matthias From matthias.baesken at sap.com Fri Oct 12 08:12:36 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Oct 2018 08:12:36 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: Ping ... any reviews / comments ? Should I add a category , for example "ioExceptionsWithPath" to the java.security - file to control the enabling/disabling of the enhanced exception ? java.security # # Enhanced exception message information ... #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath Thanks, Matthias From: Baesken, Matthias Sent: Dienstag, 9. Oktober 2018 14:12 To: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Cc: Alan Bateman (Alan.Bateman at oracle.com) Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Hello, Alan commented on it : * This proposal will require a security review as it leaks sensitive information into exceptions. So I forward it to security-dev as well. If needed, we might use something similar to JDK-8207768 where a category has been added for enhanced exception messages to the java.security file . Best regards, Matthias From: Baesken, Matthias Sent: Dienstag, 9. Oktober 2018 13:40 To: core-libs-dev at openjdk.java.net Cc: Langer, Christoph >; Lindenmaier, Goetz > Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue Hello, please review the following change . It enhances a number of JNU_ThrowIOExceptionWithLastError calls with path and current working directory information. For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is added. bug and webrev : https://bugs.openjdk.java.net/browse/JDK-8211752 http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ Thanks, Matthias From Alan.Bateman at oracle.com Fri Oct 12 09:18:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 12 Oct 2018 10:18:17 +0100 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> On 12/10/2018 09:12, Baesken, Matthias wrote: > > Ping ? ?any reviews / comments ? > > Should I add? a category? , for example? ???ioExceptionsWithPath????? > to the java.security ? file? to control? the enabling/disabling of > the? enhanced exception ? > > ? java.security > > # > > # Enhanced exception message information > > ? > > #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath > > There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, it ignores other file I/O methods that throw exceptions. Finally there is the concerns with the patch itself that both Roger and I commented on. -Alan From goetz.lindenmaier at sap.com Fri Oct 12 10:11:01 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 12 Oct 2018 10:11:01 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: Message-ID: <2bd4f1843b0d450a8d077e9691516598@sap.com> Hi, If this is required, I would choose a more generic tag so it can be reused in other places. I would just use "path". Best regards, Goetz. > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Freitag, 12. Oktober 2018 10:13 > To: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: [CAUTION] RE: RFR: 8211752: > JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions > with path causing the issue > > Ping ... any reviews / comments ? > > Should I add a category , for example "ioExceptionsWithPath" to the > java.security - file to control the enabling/disabling of the enhanced > exception ? > > java.security > > # > # Enhanced exception message information > ... > #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath > > > Thanks, Matthias > > > From: Baesken, Matthias > Sent: Dienstag, 9. Oktober 2018 14:12 > To: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: Alan Bateman (Alan.Bateman at oracle.com) > Subject: FW: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > Hello, Alan commented on it : > > > * This proposal will require a security review as it leaks sensitive > information into exceptions. > > So I forward it to security-dev as well. > > If needed, we might use something similar to JDK-8207768 where a > category has been added for enhanced exception messages to the > java.security file . > > Best regards, Matthias > > From: Baesken, Matthias > Sent: Dienstag, 9. Oktober 2018 13:40 > To: core-libs-dev at openjdk.java.net dev at openjdk.java.net> > Cc: Langer, Christoph > >; > Lindenmaier, Goetz > > > Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > > Hello, please review the following change . > It enhances a number of JNU_ThrowIOExceptionWithLastError calls with > path and current working directory information. > For this, a new function JNU_ThrowIOExceptionWithLastErrorAndPath is > added. > > bug and webrev : > > https://bugs.openjdk.java.net/browse/JDK-8211752 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211752.0/ > > Thanks, Matthias From matthias.baesken at sap.com Fri Oct 12 13:18:44 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 12 Oct 2018 13:18:44 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> Message-ID: Hi Alan, Goetz, >There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. ..... >If this is required, I would choose a more generic tag >so it can be reused in other places. >I would just use "path". > >Best regards, > Goetz. Thanks for the comments . Sure, I can use path for the category naming as well, but would be good to hear the opinions of the security-dev guys on this . > The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, >it ignores other file I/O methods that throw exceptions. We have these extended exceptions for quite some time in our JVM; we decided to enhance exceptions where we have a path already "at hand" , so it was easy to extend the exceptions . In case you think this can be done with some others , that's fine with me - do you have some concrete examples ? A lot of IO exceptions currently thrown that use JNU_ThrowIOExceptionWithLastError do not have a path (at least not where the exception is thrown). Best regards , Matthias From: Alan Bateman Sent: Freitag, 12. Oktober 2018 11:18 To: Baesken, Matthias ; security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue On 12/10/2018 09:12, Baesken, Matthias wrote: Ping ... any reviews / comments ? Should I add a category , for example "ioExceptionsWithPath" to the java.security - file to control the enabling/disabling of the enhanced exception ? java.security # # Enhanced exception message information ... #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath There are several issues with this proposal. The security concern is the main one and I think we should wait for comment from security-dev. The second concern is that the patch is incomplete and inconsistent in that it changes the exception throw by two methods, it ignores other file I/O methods that throw exceptions. Finally there is the concerns with the patch itself that both Roger and I commented on. -Alan From christoph.langer at sap.com Fri Oct 12 14:33:15 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 Oct 2018 14:33:15 +0000 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> Message-ID: Hi Matthias, I generally support this enhancement of IOExceptions to include path information. I also think that we should protect this with the java.security property "jdk.includeInExceptions" and agree that "path" would be a good choice since it is generic enough to be used in other places where Exceptions are thrown that might include path names. As for some comment from security-folks: Sean, what is your take on this? As for the implementation: We should definitely get rid of the upcall into Java from JNU_ThrowIOExceptionWithLastErrorAndPath and build the exception message in that function only, just using the " jstring path" argument. The reason for having the current implementation of ExceptionUtils. createExceptionTextWithPath, as you suggested in your webrev was that we were chasing a very specific customer issue where cwd and user.dir diverged (e.g. because of some 3rd party native library which changed the cwd). And this code is somehow still around. So, user.dir should definitely not be part of the exception message. And whether the current cwd should be contained should be reviewed in detail again. Maybe at some places it is interesting but on other places it isn't at all. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Baesken, Matthias > Sent: Freitag, 12. Oktober 2018 15:19 > To: Alan Bateman ; security- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: [CAUTION] RE: RFR: 8211752: > JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions > with path causing the issue > > Hi Alan, Goetz, > > >There are several issues with this proposal. The security concern is the main > one and I think we should wait for comment from security-dev. > ..... > > >If this is required, I would choose a more generic tag > > >so it can be reused in other places. > > >I would just use "path". > > > > > >Best regards, > > > Goetz. > > Thanks for the comments . Sure, I can use path for the category naming as > well, but would be good to hear the opinions of the security-dev guys on > this . > > > The second concern is that the patch is incomplete and inconsistent in that > it changes the exception throw by two methods, > >it ignores other file I/O methods that throw exceptions. > > We have these extended exceptions for quite some time in our JVM; we > decided to enhance exceptions where we have a path already "at hand" , > so it was easy to extend the exceptions . > In case you think this can be done with some others , that's fine with me - do > you have some concrete examples ? > > A lot of IO exceptions currently thrown that use > JNU_ThrowIOExceptionWithLastError do not have a path (at least not where > the exception is thrown). > > > Best regards , > Matthias > > > > From: Alan Bateman > Sent: Freitag, 12. Oktober 2018 11:18 > To: Baesken, Matthias ; security- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - > enhance some IOExceptions with path causing the issue > > On 12/10/2018 09:12, Baesken, Matthias wrote: > > Ping ... any reviews / comments ? > > Should I add a category , for example "ioExceptionsWithPath" to the > java.security - file to control the enabling/disabling of the enhanced > exception ? > > java.security > > # > # Enhanced exception message information > ... > #jdk.includeInExceptions=hostInfo,jar,ioExceptionsWithPath > > There are several issues with this proposal. The security concern is the main > one and I think we should wait for comment from security-dev. The second > concern is that the patch is incomplete and inconsistent in that it changes the > exception throw by two methods, it ignores other file I/O methods that > throw exceptions. Finally there is the concerns with the patch itself that both > Roger and I commented on. > > -Alan From volker.simonis at gmail.com Fri Oct 12 15:15:21 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 12 Oct 2018 17:15:21 +0200 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* In-Reply-To: References: <1025735f-94ca-12a3-78f8-b895fb1b4b2e@oracle.com> Message-ID: On Thu, Oct 11, 2018 at 11:09 PM Igor Ignatyev wrote: > > Hi Volker, > > vm.opt.* options are set by jtreg (RegressionContext::processVMOptions), and their value is expected to be "null" if a flag hasn't been passed to JDK under tests via -javaoptions or -vmoptions. I don't think there is something to fix (at least not in jtreg). > Well, if "vm.opt.*" options are indeed only options which are taken from the command line (i.e. "-javaoption/-vmoption"), than there's definitely something we have to fix! Because, as I described before, after CODETOOLS-7902290, all test which check such an option in a @requires clause (negatively or positively) will now fail if that option is not given explicitly on the command line. If "vm.opt.*" options are really only the options given on the command line (please confirm this and please document it somewhere prominently!) I think many tests which use them are broken because they simply check such options like this: @requires vm.opt.TieredCompilation == true This would be wrong and would have to be replaced by: @requires vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true to also account for the case where -XX:TieredCompilation was not explicitly set on the command line. Notice that in in such a case, the value of "TieredCompilation" in the VM could be either "true" or "false" (depending on the platform and VM build configuration), but it wouldn't be possible to test that by using "vm.opt.TieredCompilation". That said, there are three "vm.opt.final.*" options which are set by VMProps: vmOptFinalFlag(map, "ClassUnloading"); vmOptFinalFlag(map, "UseCompressedOops"); vmOptFinalFlag(map, "EnableJVMCI"); Notice that these options are set to the values of the corresponding flags in the agent VM . For tests which run in "othervm" mode (or which start new VMs with ProcessBuilder or jdk.test.lib.process.ProcessTools), that doesn't necessarily corresponds to the values of these flags in the testee VM. Finally, options specified with "-javaoption/-vmoption" and reflected in the corresponding "vm.opt.*" flags, may be over-ridden by command line options specified for tests which run in "othervm" mode (so checking them with a @requires clause is of limited usefulness as well). All this is quite complex and I think we should *really* document it in a prominent place like the "jtreg: Command Line Options" page [1] AND the "The JDK Test Framework: Tag Language Specification" page [2]. Regards, Volker [1] http://openjdk.java.net/jtreg/command-help.html [2] http://openjdk.java.net/jtreg/tag-spec.html > -- Igor > > > > On Oct 11, 2018, at 1:59 PM, Volker Simonis wrote: > > > > Jonathan Gibbons schrieb am Do. 11. Okt. 2018 > > um 19:16: > > > >> Volker, > >> > >> It's a typo/oops on my part. I'll fix it. > >> > > > > Hi John, > > > > thanks for looking at this issue! > > > > What do you mean with ? typo?? Returning null instead of the string ?null?? > > > > That would ?fix? the corresponding tests in the sense that they would run > > again, however still with bogus results for all the @requires guards which > > check the ?vm.opt.*? options. Shouldn?t we fix that as well? > > > > Regards, > > Volker > > > > > > > >> -- Jon > >> > >> > >> On 10/11/18 10:13 AM, Jonathan Gibbons wrote: > >>> Volker, > >>> > >>> Thanks for the report. I'll take a look shortly. > >>> > >>> -- Jon > >>> > >>> > >>> On 10/11/18 10:01 AM, Volker Simonis wrote: > >>>> Hi, > >>>> > >>>> the change "CODETOOLS-7902290: introduce error state of @requires > >>>> properties" [1] which was recently pushed to the codetools repo, > >>>> breaks all JTreg tests which have a require clause that queries a non > >>>> final (i.e. no "vm.opt.final") VM option. > >>>> > >>>> For example the test > >>>> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" which > >>>> uses "@requires vm.opt.DeoptimizeALot != true" will now fail with: > >>>> > >>>> test result: Error. Error evaluating expression: name not defined: > >>>> vm.opt.DeoptimizeALot > >>>> > >>>> This is because > >>>> com.sun.javatest.regtest.config.RegressionContext.get() was changed to > >>>> return null instead of the string "null" for unknown properties. > >>>> Looking at requires.VMProps, I realized that "vm.opt.DeoptimizeALot" > >>>> is indeed not defined (as many other "vm.opt" properties, see below). > >>>> So it turns out that all the tests which @required a "vm.opt" option > >>>> did run in a faulty configuration until now. > >>>> > >>>> I could for example easily fix > >>>> "hotspot/jtreg/runtime/ReservedStack/ReservedStackTest.java" by adding > >>>> the corresponding option in VMProps.java: > >>>> > >>>> $ hg diff > >>>> diff -r 7a1e2d7ac55a test/jtreg-ext/requires/VMProps.java > >>>> --- a/test/jtreg-ext/requires/VMProps.java Thu Oct 11 10:11:18 > >>>> 2018 -0400 > >>>> +++ b/test/jtreg-ext/requires/VMProps.java Thu Oct 11 18:51:37 > >>>> 2018 +0200 > >>>> @@ -266,6 +266,8 @@ > >>>> vmOptFinalFlag(map, "ClassUnloading"); > >>>> vmOptFinalFlag(map, "UseCompressedOops"); > >>>> vmOptFinalFlag(map, "EnableJVMCI"); > >>>> + String value = > >>>> String.valueOf(WB.getBooleanVMFlag("DeoptimizeALot")); > >>>> + map.put("vm.opt.DeoptimizeALot", value); > >>>> } > >>>> > >>>> Following is a list of all "vm.opt" options used in @requires clauses > >>>> without being defined in VMProps.java: > >>>> > >>>> vm.opt.AggressiveOpts > >>>> vm.opt.ClassUnloading > >>>> vm.opt.ClassUnloadingWithConcurrentMark > >>>> vm.opt.DeoptimizeALot > >>>> vm.opt.DisableExplicitGC > >>>> vm.opt.ExplicitGCInvokesConcurrent > >>>> vm.opt.FlightRecorder > >>>> vm.opt.G1HeapRegionSize > >>>> vm.opt.Inline > >>>> vm.opt.MaxGCPauseMillis > >>>> vm.opt.StartFlightRecording > >>>> vm.opt.SurvivorAlignmentInBytes > >>>> vm.opt.TieredCompilation > >>>> vm.opt.TieredStopAtLevel > >>>> vm.opt.TieredStopAtLevel==4) > >>>> vm.opt.TieredStopAtLevel==null > >>>> vm.opt.UseJVMCICompiler > >>>> > >>>> What's the current plan? Do we want to add all these options in > >>>> VMProps.java? Or should we better add all the -XX VM options together > >>>> to VMProps such that they can all be freely used within @requires > >>>> clauses? > >>>> > >>>> Thank you and best regards, > >>>> Volker > >>>> > >>>> PS: I've noticed that there's "8209807: improve handling exception in > >>>> requires.VMProps" [2] to apparently adapt VMProps.java to > >>>> CODETOOLS-7902290 but I've tried the attached webrev and it doesn't > >>>> help with the described problem. > >>>> > >>>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7902290 > >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8209807 > >>> > >> > >> > From sean.mullan at oracle.com Fri Oct 12 15:18:56 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 12 Oct 2018 11:18:56 -0400 Subject: RFR: 8211752: JNU_ThrowIOExceptionWithLastErrorAndPath - enhance some IOExceptions with path causing the issue In-Reply-To: References: <5d27b425-367a-d256-d86c-bd98c7f00496@oracle.com> Message-ID: <41e958b7-839b-fd64-48df-5e17c2f168cf@oracle.com> On 10/12/18 10:33 AM, Langer, Christoph wrote: > Sean, what is your take on this? Sorry, I haven't had time to look at this in more detail yet. But, let's take a step back first. Can you or Matthias explain in more detail why this fix is necessary? What are the use cases and motivation? The bug report doesn't go into any detail about that and there isn't anything in the initial RFR email that explains why this change is useful or necessary. As a general guideline or advice, RFEs should include this type of information so that Reviewers understand more of the context and motivation behind the change. Thanks, Sean From jonathan.gibbons at oracle.com Fri Oct 12 15:42:13 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 12 Oct 2018 08:42:13 -0700 Subject: CODETOOLS-7902290 breaks all JTreg tests which use @requires vm.opt.* In-Reply-To: References: <1025735f-94ca-12a3-78f8-b895fb1b4b2e@oracle.com> Message-ID: <7ea8c652-bcbd-154a-a02c-0a55cc4c6478@oracle.com> On 10/12/18 8:15 AM, Volker Simonis wrote: > On Thu, Oct 11, 2018 at 11:09 PM Igor Ignatyev wrote: >> Hi Volker, >> >> vm.opt.* options are set by jtreg (RegressionContext::processVMOptions), and their value is expected to be "null" if a flag hasn't been passed to JDK under tests via -javaoptions or -vmoptions. I don't think there is something to fix (at least not in jtreg). >> > Well, if "vm.opt.*" options are indeed only options which are taken > from the command line (i.e. "-javaoption/-vmoption"), than there's > definitely something we have to fix! Because, as I described before, > after CODETOOLS-7902290, all test which check such an option in a > @requires clause (negatively or positively) will now fail if that > option is not given explicitly on the command line. > > If "vm.opt.*" options are really only the options given on the command > line (please confirm this and please document it somewhere > prominently!) I think many tests which use them are broken because > they simply check such options like this: > > @requires vm.opt.TieredCompilation == true > > This would be wrong and would have to be replaced by: > > @requires vm.opt.TieredCompilation == null | vm.opt.TieredCompilation == true > > to also account for the case where -XX:TieredCompilation was not > explicitly set on the command line. Notice that in in such a case, the > value of "TieredCompilation" in the VM could be either "true" or > "false" (depending on the platform and VM build configuration), but it > wouldn't be possible to test that by using "vm.opt.TieredCompilation". > > That said, there are three "vm.opt.final.*" options which are set by VMProps: > > vmOptFinalFlag(map, "ClassUnloading"); > vmOptFinalFlag(map, "UseCompressedOops"); > vmOptFinalFlag(map, "EnableJVMCI"); > > Notice that these options are set to the values of the corresponding > flags in the agent VM . For tests which run in "othervm" mode (or > which start new VMs with ProcessBuilder or > jdk.test.lib.process.ProcessTools), that doesn't necessarily > corresponds to the values of these flags in the testee VM. > > Finally, options specified with "-javaoption/-vmoption" and reflected > in the corresponding "vm.opt.*" flags, may be over-ridden by command > line options specified for tests which run in "othervm" mode (so > checking them with a @requires clause is of limited usefulness as > well). > > All this is quite complex and I think we should*really* document it > in a prominent place like the "jtreg: Command Line Options" page [1] > AND the > "The JDK Test Framework: Tag Language Specification" page [2]. > > Regards, > Volker > > [1]http://openjdk.java.net/jtreg/command-help.html > [2]http://openjdk.java.net/jtreg/tag-spec.html > Volker, I will look? at what can be done to improve the documentation, especially with regard to documenting the limitations of the @requires mechanism. That being said, most of the mechanism is provided outside of jtreg, by the extraPropDefns? extension mechanism specified in TEST.ROOT.? It was a deliberate design choice to decouple these classes from jtreg, so that they can evolve faster and separately from jtreg promotions, according to the needs of the test suite. So, without diminishing the need for additional documentation, I'll note that detailed documentation may not belong in the jtreg pages you specified. Finally, you are right to observe the inadequacies of the vm.opt.* mechanism. IMO, it is better to use custom properties defined by the extraPropDefns mechanism that provide the result of analyzing the options, as compared to checking the options themselves. My prime example of this, when I was writing the jtreg support, was the "-server" and "-client" options, which are so-called supported options on all system, but may be no-ops on some platforms. Therefore, it is more important to check the internal settings in the VM than to check the options given to the VM. -- Jon From wdietl at gmail.com Wed Oct 10 20:23:50 2018 From: wdietl at gmail.com (Werner Dietl) Date: Wed, 10 Oct 2018 16:23:50 -0400 Subject: JDK 12 RFR of JDK-8058202 : AnnotatedType implementations don't override toString(), equals(), hashCode() In-Reply-To: References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> Message-ID: Hi Joe, all, the logic looks good to me. In the tests I'm wondering whether to include an annotated wildcard bound. There is: 307 public @AnnotType(11) Set<@AnnotType(13) ? extends Number> fooNumberSet2() {return null;} but nothing like Set fooNumberSet2() {return null;} I wouldn't expect problems for this, but a test would exercise some of the code that gets added. Best, cu, WMD. On Wed, Oct 10, 2018 at 2:40 AM Joel Borggr?n-Franck wrote: > > Hej Joe, > > New version looks good! > > Thanks for the explanations, makes sense to me. > > Cheers > /Joel > > On Wed, 10 Oct 2018 at 08:27, joe darcy wrote: >> >> Hi Joel, >> >> Thanks for the review; slightly revised version at >> >> http://cr.openjdk.java.net/~darcy/8058202.3/ >> >> Comments below. >> >> >> On 10/9/2018 11:00 AM, Joel Borggr?n-Franck wrote: >> > Hi Joe, >> > >> > Good to see this happening. In general looks good to me, a few nits below. >> > >> > AnnotatedTypeBaseImpl contains comments indicating from which >> > superclass or interface the overridden methods comes. I'd either add >> > // Object at line 207 or delete line 145 and 177 for consistency. >> >> Okay; comments added to follow that local convention. >> >> > >> > Even though this isn't performance critical by far the allocation at >> > line 215 still bugs me a bit given that the common case will most >> > certainly be no annotations. >> >> Sure; refactored to avoid the allocation. >> >> > >> > Why the inverted logic line 250-253, IIRC you should be able to test >> > if it is an AnnotatedBaseTypeImpl, or? >> >> I was aiming to avoid testing for the impl class directly to not >> directly tie the classes to this particular implementation of the >> AnnotatedType hierarchy. However, inter-operability based on the specs >> would need the equals and hashCode behavior to be defined. >> >> > >> > For equalsTypeAndAnnotations and baseHashCode lines 232-244 equals >> > test for owner type equality while hashcode doesn't include owner >> > type. I must confess I no longer remember the equals-hashCode contract >> > but I assume this is intentional. >> >> Good catch; equals and hashCode checks made consistent. >> >> Some refactoring and hardening of the test included too. >> >> Delta-diffs below. >> >> Thanks, >> >> -Joe >> >> diff >> webrev.2/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java >> webrev/raw_files/new/src/java.base/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java >> >> 2c2 >> < * Copyright (c) 2013, 2015, Oracle and/or its affiliates. All rights >> reserved. >> --- >> > * Copyright (c) 2013, 2018, Oracle and/or its affiliates. All rights >> reserved. >> 207c207 >> < @Override >> --- >> > @Override // java.lang.Object >> 215d214 >> < StringJoiner sj = new StringJoiner(" "); >> 216a216 >> > StringJoiner sj = new StringJoiner(" "); >> 228,229c228,231 >> < } >> < return sj.toString(); >> --- >> > return sj.toString(); >> > } else { >> > return ""; >> > } >> 244c246,247 >> < Objects.hash((Object[])getAnnotations()); >> --- >> > Objects.hash((Object[])getAnnotations()) ^ >> > Objects.hash(getAnnotatedOwnerType()); >> >> diff >> webrev.2/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java >> webrev/raw_files/new/test/jdk/java/lang/annotation/typeAnnotations/TestObjectMethods.java >> >> 142d141 >> < >> 157,168c156,158 >> < AnnotatedType annotType1 = m.getAnnotatedReturnType(); >> < AnnotatedType annotType2 = m.getAnnotatedReturnType(); >> < >> < boolean valid = annotType1.equals(annotType2); >> < >> < if (!valid) { >> < errors++; >> < System.err.println(annotType1); >> < System.err.println(" is not equal to "); >> < System.err.println(annotType2); >> < System.err.println(); >> < } >> --- >> > checkTypesForEquality(m.getAnnotatedReturnType(), >> > m.getAnnotatedReturnType(), >> > true); >> 171a162,185 >> > private static void checkTypesForEquality(AnnotatedType annotType1, >> > AnnotatedType annotType2, >> > boolean expected) { >> > boolean comparison = annotType1.equals(annotType2); >> > >> > if (comparison) { >> > int hash1 = annotType1.hashCode(); >> > int hash2 = annotType1.hashCode(); >> > if (hash1 != hash2) { >> > errors++; >> > System.err.format("Equal AnnotatedTypes with unequal hash >> codes: %n%s%n%s%n", >> > annotType1.toString(), annotType2.toString()); >> > } >> > } >> > >> > if (comparison != expected) { >> > errors++; >> > System.err.println(annotType1); >> > System.err.println(expected ? " is not equal to " : " is >> equal to "); >> > System.err.println(annotType2); >> > System.err.println(); >> > } >> > } >> > >> 184,196c198,200 >> < AnnotatedType annotType1 = >> methods[i].getAnnotatedReturnType(); >> < AnnotatedType annotType2 = >> methods[j].getAnnotatedReturnType(); >> < >> < boolean valid = !annotType1.equals(annotType2); >> < >> < if (!valid) { >> < errors++; >> < System.err.println(annotType1); >> < System.err.println(" is equal to "); >> < System.err.println(annotType2); >> < System.err.println(); >> < } >> < >> --- >> > checkTypesForEquality(methods[i].getAnnotatedReturnType(), >> > methods[j].getAnnotatedReturnType(), >> > false); >> 209,210c213 >> < Method[] methods1 = clazz1.getDeclaredMethods(); >> < Method[] methods2 = clazz2.getDeclaredMethods(); >> --- >> > System.err.println("Testing that presence/absence of >> annotations matters for equals comparison."); >> 212,226c215,230 >> < // Skip 0th element since void cannoted be annotated >> < for (int i = 1; i < methods1.length; i++) { >> < AnnotatedType annotType1 = >> methods1[i].getAnnotatedReturnType(); >> < AnnotatedType annotType2 = >> methods2[i].getAnnotatedReturnType(); >> < >> < boolean valid = !annotType1.equals(annotType2); >> < >> < if (!valid) { >> < errors++; >> < System.err.println(annotType1); >> < System.err.println(" is equal to "); >> < System.err.println(annotType2); >> < System.err.println(); >> < } >> < } >> --- >> > String methodName = null; >> > for (Method method : clazz1.getDeclaredMethods()) { >> > if ("void".equals(method.getReturnType().toString())) { >> > continue; >> > } >> > >> > methodName = method.getName(); >> > try { >> > checkTypesForEquality(method.getAnnotatedReturnType(), >> > clazz2.getDeclaredMethod(methodName).getAnnotatedReturnType(), >> > false); >> > } catch (Exception e) { >> > errors++; >> > System.err.println("Method " + methodName + " not found."); >> > } >> > } >> 230a235 >> > System.err.println("Testing wildcards"); >> 242,248c247 >> < if (awt1.equals(awt2)) { >> < errors++; >> < System.err.println(awt1); >> < System.err.println(" is equal to "); >> < System.err.println(awt2); >> < System.err.println(); >> < } >> --- >> > checkTypesForEquality(awt1, awt2, false); >> 254d252 >> < -- http://www.google.com/profiles/wdietl From philipp.kunz at paratix.ch Fri Oct 12 17:23:37 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 12 Oct 2018 19:23:37 +0200 Subject: Review Request: 6443578: Continuation lines in JAR manifests do not follow RFC-822 Message-ID: <1539365017.2264.4.camel@paratix.ch> Hi, Attached is a patch with a proposal to fix bug 6443578 about Manifest inserting line breaks in between bytes of?characters encoded in?utf-8 with more than one byte and a test for it. The Issue The current Manifest implementation places line breaks for breaking and continuing values onto the next line always at 72 bytes from the start of the line without paying attention to characters encoded in utf-8 with more than one byte and to all bytes of one character together. It occurs that a character encoded in utf-8 with more than one byte is partially written at the end of one line and then after a line break for a continuation line ("\r\n ") continued on the next line resulting in an invalid utf-8 byte sequence where?"\r\n " is inserted in between the multiple bytes of the byte sequence a character is encoded in utf-8 with. That cannot happen with characters encoded with one byte in utf-8 which are used most often. It only affects characters with more than one byte encoded in utf-8. It also does not affect header names (the keys) because header names are limited to?{A-Z} | {a-z} | {0-9} | - | _ [1] which all happen to be characters encoded in utf-8 with one byte. The Manifest implementation removes these continuation line delimiters ("\r\n ") again in [2] and [3] (mind the --) and [4] (mind the 1 as second parameter to arraycopy skipping the space) and concatenates the parts from?individual continuation lines together in?[5] operating still on a sequence of bytes before decoding the remaining bytes of the value back into the string value applying the utf-8 decoding in [6]. The process is very similar also for names of named sections, see [7], [8], [9], and [10]. Manifests written with the current implementation are read again correctly. Not only the specification says that sequences of bytes of the same utf-8 encoded character cannot be broken apart [1] > value: SPACE *otherchar newline *continuation > continuation: SPACE *otherchar newline > otherchar: any UTF-8 character except NUL, CR and LF but line break and space can occur only between whole utf-8 encoded characters and also jar manifests cannot be viewed with utf-8 aware file viewers correctly. Manifests with values with characters illegally broken onto a new line look for example simplified and with a shortened line width limit similar like this one in any of my favorite file viewers: > Manifest-Version: 1.0 > Key: G?nsef??chen in ?bergr? > ??e where ? and ? should in fact be a German o umlaut ?. A file viewer may understand and decode utf-8 well but has no way to know that the two bytes, one before and one after the continuation line break actually constitute the utf-8 encoded byte sequence of one single character. Don't Put Continuation Line Breaks in Front of UTF-8 Continuation Bytes The approach chosen in my patch is to prevent putting continuation line breaks before a utf-8 continuation byte. UTF-* continuation bytes can be detected with a bit mask and comparison, see [11]. An alternative would have been to write one character (unicode codepoint and not?Java 16-bit char) after another computing the length in number of bytes in utf-8 encoded form for each and checking if it still fits on the same line before writing it with or without an addition continuation line break. When working with strings in Java, an additional challenge would have been to work with surrogate pairs. I figure the bitmask comparison fits the purpose here best, it is also used elsewhere in the jdk, see [12] and [13] among other places, and presumably involves the least resource usage and performance penalty, unfortunately none of which accessible (private). Tricky Strings of Actual Bytes The current Manifest implementation does some kind of strange processing when writing and encoding manifests with respect to using strings with bytes as already described and mentioned in [14] and [15] among probably more. The values are converted into strings with the invocation of the deprecated constructor [17] in [16]: > value = new String(vb, 0, 0, vb.length); which converts the utf-8 encoded bytes into a string of chars each of which is set to a byte value in its lower byte and zero in the higher byte [18]. Each char of that string actually holds a byte and its length corresponds to the number of bytes of the utf-8 encoded value. After inserting line breaks in make72Safe [19] the string is written to the output stream disregarding the higher bytes of the chars by applying a lossy conversion in [20] thereby restoring the original utf- 8 byte sequence with line breaks added which also don't use higher bytes. I'll be glad to also solve bug 8066619 by replacing these weird strings with byte arrays or anyhow else but prefer to do that in a separate effort and patch and for this patch here the strings are encoded as they always were. Above paragraph explains why my patch's isUTF8ContinuationByte takes a parameter of type char which looks weird at first glance but after studying the situation it implies the least possible number of type casts and each char actually represents a byte held in each chars lower byte accounting for that methods name. Compatibility In addition to the tests which usually test the current implementation it has to be made sure that manifests?written by newer jdk can be read by an older one and manifests written by an older jdk can be read by a newer one. Obviously also manifests written by older versions of the jdk should be read correctly by older versions of it which has been addressed in older jdk version already and the test in the patch is supposed to test writing and reading of manifests with all kinds of cases related to breaking values on continuation lines in conjunction with characters near that break with different number of bytes in their utf-8 encoded forms. Reading the manifests remains unchanged which is why only writing manifests like it was done before became a part of the new test in the patch, see writeManifestWithBrokenCharacters and make72Safe in the LineBreakCharacter test in the attached patch. Performance and Resource Usage Implications I figure that reading and writing manifests are frequent operations already optimized to a certain extent guessing for instance from the name of the class?Manifest.FastInputStream. Adding more complexity as in my patch will certainly make operations not faster. I have no facts here but state some assumptions. When writing a manifest, performance and resource usage is only affected if lines are actually broken onto continuation lines, which I would assume happens statistically to a minority of headers only. When breaking a value onto a continuation line when writing a manifest, at least one and at most four bytes will be checked if they are continuation bytes. In average I assume that characters encoded with fewer bytes occur much more often. It may also happen that the same manifest will need more continuation lines because lines will be filled with less than the complete 72 byte limit if at the end of the line a multi-byte character would exceed it. When the next line starts with the whole character instead of the remaining bytes the next continuation line break could have to placed earlier and so on. The utf-8 encoded values will not change but there might be more continuation line breaks ("\r\n ") than before using storage space in main memory as well as on disk. A line can be at most three bytes shorter than the limit and therefore at least 24 lines are necessary to require an additional continuation line break. When reading manifests, the only difference might make the increased manifest file sizes or input stream lengths in number of bytes. Altogether, I guess that these implications are negligible. The issue has been open for quite some time now and Java still has worked well without its resolution. Advantages of applying that patch would be that the manifest files would comply with respect to utf-8 encoding to its own specification and could be correctly viewed and also edited with any utf-8 capable viewer or editor with the complete unicode character set and another bug could be closed. I'm looking forward to any feedback and would be glad if someone would volunteer to sponsor the change. Regards, Philipp [1] https://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html #Section-Specification [2] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Attributes.java#l384 byte c = lbuf[--len]; [3] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Attributes.java#l392 --len; [4] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Attributes.java#l407 System.arraycopy(lbuf, 1, buf, lastline.length, len - 1); [5] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Attributes.java#l406 System.arraycopy(lastline, 0, buf, 0, lastline.length); [6] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Attributes.java#l412 value = new String(buf, 0, buf.length, "UTF8"); [7] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Manifest.java#l236 byte c = lbuf[--len]; [8] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Manifest.java#l244 --len; [9] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/share /classes/java/util/jar/Manifest.java#l267 System.arraycopy(lbuf, 1, buf, lastline.length, len - 1); [10] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/util/jar/Manifest.java#l273 name = new String(buf, 0, buf.length, "UTF8"); [11] https://tools.ietf.org/html/rfc3629#section-3 [12] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/lang/StringCoding.java#l632 return (b & 0xc0) != 0x80; [13] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/sun/nio/cs/UTF_8.java#l90 return (b & 0xc0) != 0x80; [14] https://bugs.openjdk.java.net/browse/JDK-8066619?focusedCommentId= 14085301&page=com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel#comment-14085301 [15] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/0529 46.html [16] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/util/jar/Manifest.java#l177 value = new String(vb, 0, 0, vb.length); [17] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/lang/String.java#l375 @Deprecated(since="1.1") public String(byte ascii[], int hibyte, int offset, int count) { [18] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/lang/String.java#l389 StringUTF16.putChar(val, i, hibyte | (ascii[offset++] & 0xff)); [19] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/util/jar/Manifest.java#l191 [20] http://hg.openjdk.org/jdk/jdk/file/331fbd2db6b5/src/java.base/shar e/classes/java/io/DataOutputStream.java#l276 out.write((byte)s.charAt(i)); [21] https://bugs.openjdk.java.net/browse/JDK-6695402 [22] https://tools.ietf.org/html/rfc822#section-3.1.1 -------------- next part -------------- A non-text attachment was scrubbed... Name: 6443578.patch Type: text/x-patch Size: 32640 bytes Desc: not available URL: From huizhe.wang at oracle.com Fri Oct 12 19:16:02 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 12 Oct 2018 12:16:02 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BA59F92.3010601@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> Message-ID: <5BC0F2F2.8040600@oracle.com> Hi all, Here's an update based on all of the great reviews and comments (thanks all!): JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 Current version: specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ Previous version: specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ It's been a while, so here's a summary of what's changed: Spec: Alan's patch to fix inconsistencies in wording/terminology Impl: s/mismatchByAttrs and etc/isSameFile; Stick with the simple implementation (InputStream/Buffer) for now. Further improvement may be done if there's a need; The impl is smaller than the previous version, merged the code into Files, removed FilesMismatch.java; Test: more readable variables instead of the array of test files more comments on the testcases improved the private methods used for generating the test files Thanks, Joe On 9/21/18, 6:49 PM, Joe Wang wrote: > > On 9/20/18, 2:46 PM, Stuart Marks wrote: >> >> >> On 9/19/18 11:48 AM, Joe Wang wrote: >>> After much discussion and 10 iterations of reviews, this proposal >>> has evolved from what was the original isSameContent method to a >>> mismatch method. API-wise, a compare method was also considered as >>> it looked like just a short step forward from mismatch, however, it >>> was eventually dropped since there is no convincing use case >>> comparing files lexicographically by contents. Impl-wise, extensive >>> performance benchmarking has been done to compare a buffered reading >>> vs memory mapping, the result was that a simple buffered reading >>> performed better among small files, and those with the mismatched >>> byte closer to the beginning of files. Since the proposed method's >>> targeted files are small ones, the impl currently does a buffered >>> reading only. >> >> Hi Joe, >> >> Thanks for being persistent with this one! > > Thanks for the help, and the "lot of stuff" with clear indicators > (e.g. line numbers and etc.)! From JDK 11 to 12, hopefully wont be > deferred to 13 :-) >> >> A very small spec nitpick: >> >>> specdiff: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html >> >> 1544 *

  • {@link #isSameFile(Path, Path) isSameFile(path, >> path2)} returns true,
    • >> >> I would add "or" after the trailing comma. This makes it similar to >> the two-item list that follows. > > Done. >> >>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/ >> >> A couple minor comments on FilesMismatch.java: >> >> If mismatchByAttrs() is replaced with a call to isSameFile(), as Alan >> suggested, this simplifies things considerably. It looks like the >> mismatch() implementation will be reduced to around ~40 lines of >> code. Does it deserve its own file, or can it be placed directly into >> Files.java? That file has over 4,000 lines already though. > > I merged the private methods after removing mismatchByAttrs(), that > reduced the code to 33 lines, and then with the change you suggested > below, it's further reduced to 29 lines. I'll put them in Files for now. > > Files is too big, ~180K, that compares with the next one ~45K among > files in the nio/file package. Unfortunately, the great majority of > them are specs, probably 90%. >> >> 106 if (nRead1 == 0 || nRead2 == 0) { >> 107 if (nRead1 == 0 && nRead2 == 0) { >> 108 // both files reach EOF >> 109 return -1; >> 110 } else { >> 111 // one of the files reaches EOF >> 112 return totalRead; >> 113 } >> 114 } else if (nRead1 != nRead2) { >> >> I think it reads slightly better if the nested 'if' at lines 107-113 >> were flattened into the else-if chain, like so: >> >> if (nRead1 == 0 && nRead2 == 0) { >> // both files reached EOF >> return -1; >> } else if (nRead1 == 0 || nRead2 == 0) { >> // one but not both files reached EOF >> return totalRead; >> } else if (nRead1 != nRead2) { >> >> There are a couple places where lines can be joined. The resulting >> lines are longer than 80 characters but are still less than 100 >> characters, which I think is OK. (I don't think we have a strict >> limit of 80 anymore.) >> >> 97 private static long mismatch(InputStream in1, InputStream in2) >> 98 throws IOException { >> >> 117 return totalRead + >> 118 Arrays.mismatch(buffer1, 0, len, buffer2, 0, >> len); > > Done. 95 characters :-) > >> >> Comments on tests in Comparison.java: >> >> * This file, and several names within this file, should probably >> should be renamed to focus on mismatch instead of comparison. > > Will rename to "mismatch". Previously, it covers both mismatch and > compare. >> >> * I'm finding it quite difficult to read the test cases. >> >> The test files are placed into a Path[] and referenced by index. This >> makes it quite difficult to determine, for example, if all six cases >> within the mismatch loop are covered. >> >> Instead of storing the files at specific array indexes, I'd suggest >> doing the following. >> >> 1) Establish good naming conventions for test files, including size >> information, covering duplicate files (e.g., 'a' and 'b'), and a >> modification at a particular offset. For example, you might do >> something like the following: >> >> test120a - a test file with size 120 >> test120b - a test file with size 120, identical to test120a >> test120m110 - a test file with size 120, with an altered byte at 110 >> etc. > > I can do that. I had hoped the Assertion msg, e.g. "Both files are > empty, no mismatch" would help. Along with renaming variables, I will > also add to the Assertion Msg with test case number, e.g. "Case#1: > both files are empty, return no mismatch". >> >> 2) Declare fields of the same name containing the file paths. >> >> 3) Add some logic in prepareTestFile() to append each file's path to >> a list after the file is created. Then have the @AfterClass method >> run through this list and delete the files. > > May also create the test files in a folder and delete it @AfterClass. >> >> 4) The test data generator method can then have lines of test data >> that reference the test files using a meaningful name, so it's easy >> to understand the names and the expected results. Also, the test data >> generator should have a comment that describes the test method >> parameters. > > Sure, will add comments and etc. >> >> * The generation of the test data files seems overly complicated. >> >> A StringBuilder is used to accumulate data, then it's turned into a >> String, then (optionally) a character is replaced by the insertChar() >> method, and then the string is written to the file. >> >> I think you can just accumulate the test data into a StringBuilder, >> (optionally) call sb.setCharAt() to modify the data, and then write >> the SB to the file. After all, Files.writeString() takes a CharSequence. >> >> The generateFixedString() method should be changed to create and >> return a fresh StringBuilder with the desired contents. (See above.) >> It can also be simplified quite a bit. > > Wouldn't it be nice if String has an utility method that generates > random ASCII strings? ;-) It can be faster with its internal byte array. >> >> I don't think you need to have methods with Charset parameters. It's >> reasonable to have the test files be text, which makes things easier >> to develop and debug. But the test depends on characters being >> written in a single-byte charset, because mismatch() reports *byte* >> positions and not *character* positions. >> >> Using the method overloads that are implicitly UTF-8 is incorrect. If >> a non-single-byte character were to slip into the test data (seems >> unlikely, but possible), it'll be expanded to multiple bytes by the >> UTF-8 encoder, which may throw off the result. Instead I'd suggest >> hardwiring the charset to be US_ASCII to enforce the >> one-byte-per-character invariant. >> >> This is a lot of stuff. If you can't follow it all, perhaps we can >> work together directly and go over the test file. > > I'll improve the test, and US_ASCII it is! I'll probably use a string > of fixed length to generate the longest string the test needs, and > then get substrings for other test cases, that may simplify the process. > > Thanks, > Joe > >> >> Thanks, >> >> s'marks From christoph.langer at sap.com Fri Oct 12 21:33:16 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 12 Oct 2018 21:33:16 +0000 Subject: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files In-Reply-To: <5BBDA762.3040001@oracle.com> References: <5BBDA762.3040001@oracle.com> Message-ID: Hi Sherman, thanks for your input. Next week I?ll work on updating my webrev to incorporate your points and I?ll also draft a CSR. Best regards Christoph From: Xueming Shen Sent: Mittwoch, 10. Oktober 2018 09:17 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net Subject: Re: RFR (Enhancement): 6194856: Zip Files lose ALL ownership and permissions of the files Hi Langer, Here are some of my comments. ZipEntry: Optional> getPosixPermissions() (1) Is "Optional" really necessary here. it's a little inconsistent compared to the rest of methods in the class. a "null" return might be just fine? (2) Needs a

    to separate the first line of the spec from the rest (3) The wording probably needs more consideration. For example, it might be more straightforward to use some similar wording from other methods, for example ... When read from a ZIP file, this is the posix permission stored in the {@code external file attributes} field of the zip file entry's central directory record, if there is one. Also, a @ImplNote might be the better place for "it's not available when read from ZIS"? void setPosixPermissions( Set permissions) I can see the possible use case of using "null" as a special value to reset the permission field (and my proposal of simply returning a null from getPosixPermissions() when there is no one, brings some symmetry here?) ZipUtil: (1) those POSIX_... constants don't need to be public? (2) I like the "stream" style implementation of permsTo/FromFlags pair, but have some concerns regarding their cost. "stream" is relative expensive (when you take a look at those supporting class underneath), as these two are supposed to be invoked for every entry inside a zip file, they can be hundreds and thousands ... just wonder, given most of the entries likely to have the "same" permission set inside a "normal" zip/jar file, is it worth to put in some cache mechanism here, especially for the "get" method, is it designed to return a read-only set of permission? (in which we can use some mechanism here). That said PosixFileAttributes.getPermissions() actually purposely returns a modifiable set of permissions. It might be worth some discussion here, as the ZipEntry.getPosixPermission() needs to specify it, if it's going to return a immutable set. Test: These days it is discouraged to check in a binary zip file as a test target. It is preferred to create the testing zip file on the fly. -Sherman On 9/25/18, 7:57 AM, Langer, Christoph wrote: Hi all, I had asked for opinions regarding adding posix permission support to JDK?s zip handling libraries and tools [1]. Since I didn?t get clear ?no, you can?t do this? answers, I?m now concretely proposing some enhancements in the area of java.util.zip, jdk.zipfs and jdk.jartool. I have reopened the long standing bug report (6194856) which had been set to ?Won?t fix? quite recently for this purpose. Here are the technical details: The ZIP format specifications by infozip and pkware ([2] and [3]) do not explicitly specify the handling of posix file permissions. But it seems to be common sense that if file attribute compatibility is set to ?Unix? in the upper byte of CEN field ?version made by?, the file permissions bits are stored in CEN field ?external file attributes?, byte 3 and 4. My changes try to honor this in the least obtrusive way. ?? The following changes are proposed: java.util.zip.ZipEntry: it will have an additional field ?posixPerms?. A value of -1 means ?no permission information?, positive values will contain the flag values. There will be 2 new public methods to read/set the permission information: public Optional> getPosixPermissions() public void setPosixPermissions(Set permissions) The usage of type ?Optional? reflects that posix permissions are not necessarily present in a zip file java.util.zip.ZipFile: it will have the capability to read the CEN fields and set posixPerms if available java.util.zip.ZipOutputStream: it will store entries with associated posix permissions as unix type in the CEN, together with the bit mask for the permissions jdk.jartool: I propose to add and option "--preserve-posix" or short "-o" to honor the posix bits that may be stored inside zip/jar files. By default the option is not set and hence posix permissions are ignored. If the flag is set and the file system that the jar tool is running on supports posix, posix file permissions that exist in the file system will be stored in newly created/update archives or restored to the file system if such information is present in the archive. jdk.zipfs: I added the capability for posix file permissions in the implementation. I decided to support PosixFileAttributes by subclassing ZipFileAttributes from this superclass as well as subclassing ZipFileAttributeView from PosixFileAttributeView. However, as PosixFileAttributes also include groups and owners, I would throw UnsupportedOperationExceptions in case of invoking methods to handle these attributes. But this approach seems to be most consistent with e.g. Files.setPosixFilePermissions and Files.getPosixFilePermissions. java.nio.file.attribute.PosixFilePermissions: As this class presents a collection of static helpers, I added definitions for the posix file bit masks together with methods to convert between Sets of PosixFilePermission to bit masks containing the according switches and vice versa. These definitions could theoretically also be moved inside the java.util.zip or jdk.zipfs implementations where they wouldn?t be exposed as public APIs. However, in that case the code would probably need to be duplicated. I?ve also created two jtreg testcases for both, java.util.zip and jdk.nio.zipfs. The changes also contain a few further code cleanups. Here are the links: Bug: https://bugs.openjdk.java.net/browse/JDK-6194856 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/6194856.0/ I?ll write a CSR once there?s some substantial feedback to my endeavor. Thanks in advance for reviewing/commenting. Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055375.html [2] http://www.info-zip.org/doc/appnote-19970311-iz.zip [3] https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT From naoto.sato at oracle.com Fri Oct 12 21:38:33 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 12 Oct 2018 14:38:33 -0700 Subject: [12] RFR: 8211961: Broken link in java.util.Locale Message-ID: <71a413c2-9efc-3d11-f72f-dc250944c805@oracle.com> Hi, Please review this simple doc fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8211961 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8211961/webrev.01/ Although @link is preferred in the javadoc, it is currently not working for @serialField (JDK-6344777). Instead, "java.base" module name is prepended in the href as a workaround. Naoto From mandy.chung at oracle.com Fri Oct 12 22:26:43 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Oct 2018 15:26:43 -0700 Subject: [12] RFR: 8211961: Broken link in java.util.Locale In-Reply-To: <71a413c2-9efc-3d11-f72f-dc250944c805@oracle.com> References: <71a413c2-9efc-3d11-f72f-dc250944c805@oracle.com> Message-ID: <7dcc3f70-b142-5bbe-4bbb-32bef7ed98a3@oracle.com> +1 Mandy On 10/12/18 2:38 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review this simple doc fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8211961 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8211961/webrev.01/ > > Although @link is preferred in the javadoc, it is currently not > working for @serialField (JDK-6344777). Instead, "java.base" module > name is prepended in the href as a workaround. > > Naoto From martinrb at google.com Sat Oct 13 18:10:56 2018 From: martinrb at google.com (Martin Buchholz) Date: Sat, 13 Oct 2018 11:10:56 -0700 Subject: Inconsistencies in TreeSet Interface In-Reply-To: References: Message-ID: core-libs-dev is the right mailing list. The documentation could be improved, but it's nuanced - consider using a TreeSet with a Comparator that accepts null. On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < kishor.gollapalliwar at gmail.com> wrote: > Hello Everyone, > > Introduction : I?m an enthusiast java developer. I?m a newbie in this > group, hence please ignore my nuisance and guide me towards right > direction. > > ## Problems Statement > > Treeset#add method documentations : ?adds the specified element e to this > set if the set contains no element e2 such that (e==null ? e2==null : > e.equals(e2))? > > Inconsistencies: > > > If we try to add ?null? value, it will throws NullPointerException, hence > > e and e2 can not be null. > > > > > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to > > collection. > > > Request you to help me understand if behavior of Treeset#add method is as > expected, and differ with set interface documentation. We may have to > consider to update method documentations, if behavior is expected. > > For more details I have attached the sample java application. > > I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK 8u181. > > Thanks & Regards, > *Kishor Golapelliwar,* > The ability to convert ideas to things is the secret to outward success. > From Alan.Bateman at oracle.com Sun Oct 14 18:08:36 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 14 Oct 2018 19:08:36 +0100 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC0F2F2.8040600@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> Message-ID: On 12/10/2018 20:16, Joe Wang wrote: > Hi all, > > Here's an update based on all of the great reviews and comments > (thanks all!): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 > > Current version: > specdiff: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ I think the javadoc looks good now. I agree that starting with a simple implementation is okay, it can be improved in time. One thing to fix is totalRead that needs to be a long to give the correct result on large files that mismatch at position > 2GB. -Alan From weijun.wang at oracle.com Mon Oct 15 01:48:52 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 15 Oct 2018 09:48:52 +0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC0F2F2.8040600@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> Message-ID: Hi Joe Two comments: 1. How about (path1, path2)? I take a look at other similar APIs, some use (c1,c2) and some (a,b). 2. Could the method be non-reflexive even if fs is non static? isSameFile(f,f) is always true. + *

    This method may not be atomic with respect to other file system + * operations. If the file system and files remain static then this method + * is reflexive (for {@code Path} {@code f}, {@code mismatch(f,f)} + * returns {@code -1L}) Thanks Max > On Oct 13, 2018, at 3:16 AM, Joe Wang wrote: > > Hi all, > > Here's an update based on all of the great reviews and comments (thanks all!): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 > > Current version: > specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ > > Previous version: > specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ > > It's been a while, so here's a summary of what's changed: > > Spec: Alan's patch to fix inconsistencies in wording/terminology > Impl: s/mismatchByAttrs and etc/isSameFile; > Stick with the simple implementation (InputStream/Buffer) for now. Further improvement may be done if there's a need; > The impl is smaller than the previous version, merged the code into Files, removed FilesMismatch.java; > > Test: more readable variables instead of the array of test files > more comments on the testcases > improved the private methods used for generating the test files > > Thanks, > Joe > > On 9/21/18, 6:49 PM, Joe Wang wrote: >> >> On 9/20/18, 2:46 PM, Stuart Marks wrote: >>> >>> >>> On 9/19/18 11:48 AM, Joe Wang wrote: >>>> After much discussion and 10 iterations of reviews, this proposal has evolved from what was the original isSameContent method to a mismatch method. API-wise, a compare method was also considered as it looked like just a short step forward from mismatch, however, it was eventually dropped since there is no convincing use case comparing files lexicographically by contents. Impl-wise, extensive performance benchmarking has been done to compare a buffered reading vs memory mapping, the result was that a simple buffered reading performed better among small files, and those with the mismatched byte closer to the beginning of files. Since the proposed method's targeted files are small ones, the impl currently does a buffered reading only. >>> >>> Hi Joe, >>> >>> Thanks for being persistent with this one! >> >> Thanks for the help, and the "lot of stuff" with clear indicators (e.g. line numbers and etc.)! From JDK 11 to 12, hopefully wont be deferred to 13 :-) >>> >>> A very small spec nitpick: >>> >>>> specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html >>> >>> 1544 *

  • {@link #isSameFile(Path, Path) isSameFile(path, path2)} returns true,
    • >>> >>> I would add "or" after the trailing comma. This makes it similar to the two-item list that follows. >> >> Done. >>> >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/ >>> >>> A couple minor comments on FilesMismatch.java: >>> >>> If mismatchByAttrs() is replaced with a call to isSameFile(), as Alan suggested, this simplifies things considerably. It looks like the mismatch() implementation will be reduced to around ~40 lines of code. Does it deserve its own file, or can it be placed directly into Files.java? That file has over 4,000 lines already though. >> >> I merged the private methods after removing mismatchByAttrs(), that reduced the code to 33 lines, and then with the change you suggested below, it's further reduced to 29 lines. I'll put them in Files for now. >> >> Files is too big, ~180K, that compares with the next one ~45K among files in the nio/file package. Unfortunately, the great majority of them are specs, probably 90%. >>> >>> 106 if (nRead1 == 0 || nRead2 == 0) { >>> 107 if (nRead1 == 0 && nRead2 == 0) { >>> 108 // both files reach EOF >>> 109 return -1; >>> 110 } else { >>> 111 // one of the files reaches EOF >>> 112 return totalRead; >>> 113 } >>> 114 } else if (nRead1 != nRead2) { >>> >>> I think it reads slightly better if the nested 'if' at lines 107-113 were flattened into the else-if chain, like so: >>> >>> if (nRead1 == 0 && nRead2 == 0) { >>> // both files reached EOF >>> return -1; >>> } else if (nRead1 == 0 || nRead2 == 0) { >>> // one but not both files reached EOF >>> return totalRead; >>> } else if (nRead1 != nRead2) { >>> >>> There are a couple places where lines can be joined. The resulting lines are longer than 80 characters but are still less than 100 characters, which I think is OK. (I don't think we have a strict limit of 80 anymore.) >>> >>> 97 private static long mismatch(InputStream in1, InputStream in2) >>> 98 throws IOException { >>> >>> 117 return totalRead + >>> 118 Arrays.mismatch(buffer1, 0, len, buffer2, 0, len); >> >> Done. 95 characters :-) >> >>> >>> Comments on tests in Comparison.java: >>> >>> * This file, and several names within this file, should probably should be renamed to focus on mismatch instead of comparison. >> >> Will rename to "mismatch". Previously, it covers both mismatch and compare. >>> >>> * I'm finding it quite difficult to read the test cases. >>> >>> The test files are placed into a Path[] and referenced by index. This makes it quite difficult to determine, for example, if all six cases within the mismatch loop are covered. >>> >>> Instead of storing the files at specific array indexes, I'd suggest doing the following. >>> >>> 1) Establish good naming conventions for test files, including size information, covering duplicate files (e.g., 'a' and 'b'), and a modification at a particular offset. For example, you might do something like the following: >>> >>> test120a - a test file with size 120 >>> test120b - a test file with size 120, identical to test120a >>> test120m110 - a test file with size 120, with an altered byte at 110 >>> etc. >> >> I can do that. I had hoped the Assertion msg, e.g. "Both files are empty, no mismatch" would help. Along with renaming variables, I will also add to the Assertion Msg with test case number, e.g. "Case#1: both files are empty, return no mismatch". >>> >>> 2) Declare fields of the same name containing the file paths. >>> >>> 3) Add some logic in prepareTestFile() to append each file's path to a list after the file is created. Then have the @AfterClass method run through this list and delete the files. >> >> May also create the test files in a folder and delete it @AfterClass. >>> >>> 4) The test data generator method can then have lines of test data that reference the test files using a meaningful name, so it's easy to understand the names and the expected results. Also, the test data generator should have a comment that describes the test method parameters. >> >> Sure, will add comments and etc. >>> >>> * The generation of the test data files seems overly complicated. >>> >>> A StringBuilder is used to accumulate data, then it's turned into a String, then (optionally) a character is replaced by the insertChar() method, and then the string is written to the file. >>> >>> I think you can just accumulate the test data into a StringBuilder, (optionally) call sb.setCharAt() to modify the data, and then write the SB to the file. After all, Files.writeString() takes a CharSequence. >>> >>> The generateFixedString() method should be changed to create and return a fresh StringBuilder with the desired contents. (See above.) It can also be simplified quite a bit. >> >> Wouldn't it be nice if String has an utility method that generates random ASCII strings? ;-) It can be faster with its internal byte array. >>> >>> I don't think you need to have methods with Charset parameters. It's reasonable to have the test files be text, which makes things easier to develop and debug. But the test depends on characters being written in a single-byte charset, because mismatch() reports *byte* positions and not *character* positions. >>> >>> Using the method overloads that are implicitly UTF-8 is incorrect. If a non-single-byte character were to slip into the test data (seems unlikely, but possible), it'll be expanded to multiple bytes by the UTF-8 encoder, which may throw off the result. Instead I'd suggest hardwiring the charset to be US_ASCII to enforce the one-byte-per-character invariant. >>> >>> This is a lot of stuff. If you can't follow it all, perhaps we can work together directly and go over the test file. >> >> I'll improve the test, and US_ASCII it is! I'll probably use a string of fixed length to generate the longest string the test needs, and then get substrings for other test cases, that may simplify the process. >> >> Thanks, >> Joe >> >>> >>> Thanks, >>> >>> s'marks From amaembo at gmail.com Mon Oct 15 02:50:42 2018 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 15 Oct 2018 09:50:42 +0700 Subject: Why Stream.concat is a static method - type variable contravariance In-Reply-To: <13146dc3-bf6a-f7c4-eba6-bf1220a49a6a@oracle.com> References: <13146dc3-bf6a-f7c4-eba6-bf1220a49a6a@oracle.com> Message-ID: Hello! Still from the practical point of view it would be really helpful to have instance methods like `Stream.append(T... elements)` and `Stream.prepend(T... elements)` (default implementation may utilize `concat`). Very often it's necessary to add one or two special elements to the stream, and using the `concat` makes code very ugly. C.f.: list.stream().filter(...).map(...).append(specialElement).collect(toList()); v.s.: Stream.concat(list.stream().filter(...).map(...), Stream.of(specialElement)).collect(toList()); Currently I prefer this (unless I can use third-party libraries which provide `append`): List result = list.stream().filter(...).map(...).collect(toList()); // toCollection(ArrayList::new) for purists result.add(specialElement); With best regards, Tagir Valeev. On Thu, Oct 11, 2018 at 11:11 PM Brian Goetz wrote: > > It would surely be convenient; I've wished for this a few times. But, > there's a reason for this choice, and its not just laziness; > contravariant type variables have some pretty scary challenges. See, for > example, this paper: > > http://www.cis.upenn.edu/~bcpierce/papers/variance.pdf > > in which it is shown that contravariance is one of the ingredients in a > witches brew that leads to undecideability of type checking. > > > > On 10/11/2018 12:06 AM, James Roper wrote: > > With the work I'm doing at the moment at creating a Reactive Streams > > equivalent to java.util.stream, I've often wondered why Stream.concat is a > > static method, rather than an instance method concating the given stream > > onto this. But I think the reason has just dawned on me, and I wanted to > > confirm that I'm correct. > > > > Java doesn't support contravariant type variables - it does for type > > declarations, but not type variables. > > > > To put more concretely, if I had a Stream, and I wanted to concat > > a Stream, this is a valid thing to do, the resulting stream would > > be Stream. But doing that with an instance method would require > > something like this: > > > > public Stream concat(Stream b); > > > > Which is not supported (specifically, type variable declaration > > is not supported). In contrast, what we have in the actual API: > > > > public static Stream concat(Stream a, Stream > T> b); > > > > does allow me to concat a Stream and Stream with a > > resulting type of Stream. > > > > Is this right, or are there other reasons? Also, is there any possibility > > that Java might support contravariance in type variables in future? My > > reason for wanting it is to provide the following method for reactive > > streams: > > > > public Publisher onErrorResumeWith(Function > Throwable, ? extends Publisher> f); > > > > The intent of this method is when a stream encounters an error, the passed > > function is invoked with the error, and that function returns a publisher > > that gets concated to the current stream instead of the error being > > emitted. This could possibly be implemented with a static method: > > > > public static Publisher onErrorResumeWith(Publisher a, > > Function f); > > > > But unlike concat, this method feels and reads much better as an instance > > method, as a static method it's a little confusing. > > > > Regards, > > > > James > > > From joe.darcy at oracle.com Mon Oct 15 06:11:32 2018 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 14 Oct 2018 23:11:32 -0700 Subject: JDK 12 RFR of JDK-8212081: AnnotatedType.toString implementation don't print annotations on embedded types In-Reply-To: <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> Message-ID: <5c9fab13-f06c-0cba-d3f4-8ee250f94de6@oracle.com> Follow-up fix developed; details below. On 10/11/2018 12:12 PM, joe darcy wrote: > Hi Werner, > > On 10/10/2018 1:23 PM, Werner Dietl wrote: >> Hi Joe, all, >> >> the logic looks good to me. >> >> In the tests I'm wondering whether to include an annotated wildcard >> bound. There is: >> >> 307???????? public @AnnotType(11) Set<@AnnotType(13) ? extends Number> >> fooNumberSet2() {return null;} >> >> but nothing like >> >> Set fooNumberSet2() {return null;} >> >> I wouldn't expect problems for this, but a test would exercise some of >> the code that gets added. > > You were correct to probe at the bounds on the wildcard components; > the code that was reviewed and pushed does not print annotations on > the bounds. > > I'll work on an update to handle this and similar cases where there > are embedded types that could have annotations. > Please review the fix for ??? JDK-8212081 : AnnotatedType.toString implementation don't print annotations on embedded types ??? http://cr.openjdk.java.net/~darcy/8212081.1/ A few notes on the test, the main structural change is that information about the expected properties of the toString form of the AnnotatedType of a method's return type is stored in a *declaration annotation* on the method. The presence of the expected number of type annotations on the full string of the AnnotatedType can thus be directly tested. Thanks, -Joe From priya.lakshmi.muthuswamy at oracle.com Mon Oct 15 10:32:19 2018 From: priya.lakshmi.muthuswamy at oracle.com (Priya Lakshmi Muthuswamy) Date: Mon, 15 Oct 2018 16:02:19 +0530 Subject: RFR:8211957 : Broken links to stylesheet in java.base/doc-files Message-ID: <01071336-cd36-7d1a-d1f8-f9e0bcbfe79c@oracle.com> Hi, Kindly review trivial fix for https://bugs.openjdk.java.net/browse/JDK-8211957 webrev : http://cr.openjdk.java.net/~pmuthuswamy/8211957/webrev.00/ Thanks, Priya From Alan.Bateman at oracle.com Mon Oct 15 10:37:46 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 15 Oct 2018 11:37:46 +0100 Subject: RFR:8211957 : Broken links to stylesheet in java.base/doc-files In-Reply-To: <01071336-cd36-7d1a-d1f8-f9e0bcbfe79c@oracle.com> References: <01071336-cd36-7d1a-d1f8-f9e0bcbfe79c@oracle.com> Message-ID: <5526aec1-d454-bf2c-1f18-4a3c21b8024d@oracle.com> On 15/10/2018 11:32, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review trivial fix for > https://bugs.openjdk.java.net/browse/JDK-8211957 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8211957/webrev.00/ > This looks okay to me. -Alan From aleksei.voitylov at bell-sw.com Mon Oct 15 11:51:24 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 15 Oct 2018 14:51:24 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: Kim, If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. -Aleksei On 11/10/2018 22:23, Kim Barrett wrote: >> On Oct 8, 2018, at 4:45 PM, Aleksei Voitylov wrote: >> >> Kim, >> >> Let's not underestimate the importance of continuous testing throughout the release cycle. Over the last year alternative platforms and configurations were broken accidentally not once (and I think the number is reaching 50 or something). Suggesting a platform to be "not supported for a release or two" may mean by the time the compiler is good the amount of issues to fix for a platform to regain quality may become a blocker for the next LTS. I really hope this is not the option Oracle is proposing. > My impression is that most of these were not toolchain issues per se. > Rather, they were broken or incomplete changes in platform-dependent > code that weren't tested on these "alternative" platforms before being > pushed. Oracle has provided dev-submit so that non-Oracle folks can > do some minimal testing on all the platforms that Oracle supports. I > know that I would sometimes like to have similarly "easy" testing for > various platforms not supported by Oracle. > > I didn't suggest "no testing" if there is a compiler version that > supports the new language standards but has not yet been fully > product-qualified by the people who are using it. I think gcc on arm > may be in that category. But I think it would be very disappointing > if the complete lack of a usable version of some compiler were to > completely block us in this area. (Unfortunately, such a lack appears > to be the situation for XLC compiler used for the AIX/ppc port.) The > proposal is not very aggressive. > >> We both know what and how long it takes to do a thorough OpenJDK compiler upgrade. If the community were made aware of this earlier, I would have definitely started planning for a compiler upgrade for ARM port in JDK 11. > I'm understand that it takes time and effort to do a toolchain > upgrade. And turning on support for new language version without > changing the toolchain version isn't really all that different. > > This proposal didn't suddenly appear out of nowhere. There has been > wistful discussion about using new language features for a long time, > with an understanding that going anywhere with that was difficult > because of some popular toolchain deficiencies (notably MSVC++) and > the need to upgrade others. There have been ongoing efforts in this > direction, e.g. various changes to support building with C++11/14 > support enabled. Oracle made toolchain upgrades in JDK 11, in part to > support the language standard change. (Unfortunately, the relevant > toolchain upgrade JEP was labelled "Confidential", even though a lot > of the work was in the open, and some of it was explicitly about > dealing with differences arising from turning on C++11/14.) > > I think JDK 12 for this JEP is reasonable goal at this stage. Of > course, that goal might not be achieved, for a variety of reasons. > That's why it is not yet in the Targeted state and why there is a > formal process for moving to that state; there's still work to be > done, and we'll have to see how that work proceeds. > >> With that, I conditionally agree with the proposal provided cooperating ports are given sufficient lead time to upgrade. We started testing ARM with 7.3 and will report on success. > From huaming.li at oracle.com Mon Oct 15 12:08:42 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 15 Oct 2018 20:08:42 +0800 Subject: RFR of JDK-8211974,move testlibrary/java/util/jar/CreateMultiReleaseTestJars.java to a separate testlibrary In-Reply-To: <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> References: <4550A710-2079-4880-87DC-7C0990983C0A@oracle.com> <61aa38ac-1946-2427-e21e-420f7768db07@oracle.com> Message-ID: <8178864b-50a3-57b8-1e23-322034ff2cce@oracle.com> Ping... On 2018/10/12 2:00 PM, Hamlin Li wrote: > Hi Igor, > > It's updated in place > http://cr.openjdk.java.net/~mli/8211974/webrev.00/, please review it > again. > > Thank you > > -Hamlin > > > On 2018/10/12 1:34 PM, Igor Ignatyev wrote: >> Hi Hamlin, >> >> could you please move jdk.test.lib.util.Compiler to j.t.l.compiler >> package? we use this package for classes which have dependency on >> jdk.compiler and/or java.compiler module. >> >> it'd also be nice to put CreateMultiReleaseTestJars into a named >> package. >> >> -- Igor >>> On Oct 11, 2018, at 10:23 PM, Hamlin Li wrote: >>> >>> would you please review the following patch? >>> >>> bug: >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211974 >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211972 >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211973 >>> >>> ?? https://bugs.openjdk.java.net/browse/JDK-8211979 >>> >>> webrev: http://cr.openjdk.java.net/~mli/8211974/webrev.00/ >>> >>> Thank you >>> >>> -Hamlin >>> > From shade at redhat.com Mon Oct 15 12:22:09 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Oct 2018 14:22:09 +0200 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator Message-ID: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8212178 See the details in the bug. We are hitting this race when Shenandoah is running in aggressive mode and evacuates lots of objects all the time, processing references very often. This makes weak reference reclamation races very visible. Fix: http://cr.openjdk.java.net/~shade/8212178/webrev.01/ I took the liberty of rewriting the entire method to make it more straightforward. New code guarantees we never return "null" from this method. Testing: failing tests, jdk:tier1, jdk-submit (running) Thanks, -Aleksey From rkennke at redhat.com Mon Oct 15 12:53:52 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 15 Oct 2018 14:53:52 +0200 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator In-Reply-To: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> References: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> Message-ID: <377ed5bf-be8a-ccd8-2525-8385a8808c09@redhat.com> I have verified that the program that failed before doesn't appear to fail anymore. The patch looks good to me. Thanks! Roman > Bug: > https://bugs.openjdk.java.net/browse/JDK-8212178 > > See the details in the bug. We are hitting this race when Shenandoah is running in aggressive mode > and evacuates lots of objects all the time, processing references very often. This makes weak > reference reclamation races very visible. > > Fix: > http://cr.openjdk.java.net/~shade/8212178/webrev.01/ > > I took the liberty of rewriting the entire method to make it more straightforward. New code > guarantees we never return "null" from this method. > > Testing: failing tests, jdk:tier1, jdk-submit (running) > > Thanks, > -Aleksey > From chris.w.dennis at gmail.com Mon Oct 15 13:53:44 2018 From: chris.w.dennis at gmail.com (Chris Dennis) Date: Mon, 15 Oct 2018 09:53:44 -0400 Subject: Collectors.Characteristics.IDENTITY_FINISH Spec Clarification In-Reply-To: <1D1F47D6-061F-495A-83DB-597DAB824928@gmail.com> References: <1D1F47D6-061F-495A-83DB-597DAB824928@gmail.com> Message-ID: Is there a more suitable mailing list for this kind of core-libs spec related enquiry to be directed at? Thanks, Chris > On Oct 9, 2018, at 10:48 AM, Chris Dennis wrote: > > I?m attempting to clarify the meaning/intent of the language in the specification of the identity-finish characteristic of collectors. > > The javadoc reads: > > Indicates that the finisher function is the identity function and > can be elided. If set, it must be the case that an unchecked cast > from A to R will succeed. > > In the following code the second sentence clearly indicates that the second cast from A to R must succeed. What I?m trying to confirm however is that the first sentence is intended to require that the finisher is a true identity function, so the result of the collector must be one of the instances created through the supplier, and that therefore the cast from R to A is also safe. > > public static void main(String[] args) { > Stream a = Stream.of("foo", "bar", "baz"); > Stream b = Stream.of("alice", "bob", "eve"); > > System.out.println(collect(Stream.of(a, b), partitioningBy(s -> s.startsWith("b"), toList()))); > } > > public static R collect(Stream> streams, Collector collector) { > if (collector.characteristics().contains(Collector.Characteristics.IDENTITY_FINISH)) { > return streams.map(s -> s.collect(collector)) > // Indicates that the finisher function is the identity function and can be elided. > .map(r -> (A) r) > .reduce(collector.combiner()) > > // If set, it must be the case that an unchecked cast from A to R will succeed. > .map(a -> (R) a) > .orElse(Stream.empty().collect(collector)); > } else { > return streams.flatMap(identity()).collect(collector); > } > } > > Thoughts, opinions? > > Thanks, > > Chris Dennis From brian.goetz at oracle.com Mon Oct 15 15:14:00 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 15 Oct 2018 11:14:00 -0400 Subject: Collectors.Characteristics.IDENTITY_FINISH Spec Clarification In-Reply-To: <1D1F47D6-061F-495A-83DB-597DAB824928@gmail.com> References: <1D1F47D6-061F-495A-83DB-597DAB824928@gmail.com> Message-ID: <813669bc-6a14-11d8-2316-f34117b33796@oracle.com> The intent is that the collector is free to either call the identity function, or replace it with an unchecked cast instead, and client code cannot tell the difference. On 10/9/2018 10:48 AM, Chris Dennis wrote: > I?m attempting to clarify the meaning/intent of the language in the specification of the identity-finish characteristic of collectors. > > The javadoc reads: > > Indicates that the finisher function is the identity function and > can be elided. If set, it must be the case that an unchecked cast > from A to R will succeed. > > In the following code the second sentence clearly indicates that the second cast from A to R must succeed. What I?m trying to confirm however is that the first sentence is intended to require that the finisher is a true identity function, so the result of the collector must be one of the instances created through the supplier, and that therefore the cast from R to A is also safe. > > public static void main(String[] args) { > Stream a = Stream.of("foo", "bar", "baz"); > Stream b = Stream.of("alice", "bob", "eve"); > > System.out.println(collect(Stream.of(a, b), partitioningBy(s -> s.startsWith("b"), toList()))); > } > > public static R collect(Stream> streams, Collector collector) { > if (collector.characteristics().contains(Collector.Characteristics.IDENTITY_FINISH)) { > return streams.map(s -> s.collect(collector)) > // Indicates that the finisher function is the identity function and can be elided. > .map(r -> (A) r) > .reduce(collector.combiner()) > > // If set, it must be the case that an unchecked cast from A to R will succeed. > .map(a -> (R) a) > .orElse(Stream.empty().collect(collector)); > } else { > return streams.flatMap(identity()).collect(collector); > } > } > > Thoughts, opinions? > > Thanks, > > Chris Dennis From kishor.gollapalliwar at gmail.com Mon Oct 15 06:10:49 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Mon, 15 Oct 2018 11:40:49 +0530 Subject: Inconsistencies in TreeSet Interface In-Reply-To: References: Message-ID: Hello Everyone, This is the first time I am writing mail to this group, hence please ignore my nuisance and guide me towards right direction. As suggested by Martin, I believe documentation need to be updated. I would happy to update the documentation, please provide your inputs. I have attache the .java file for more details. @Martin : I really appreciate your advice and help, thank you. Thank you, Kishor Gollapalliwar On Sat, Oct 13, 2018 at 11:40 PM Martin Buchholz wrote: > core-libs-dev is the right mailing list. > > The documentation could be improved, but it's nuanced - consider using a > TreeSet with a Comparator that accepts null. > > On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < > kishor.gollapalliwar at gmail.com> wrote: > >> Hello Everyone, >> >> Introduction : I?m an enthusiast java developer. I?m a newbie in this >> group, hence please ignore my nuisance and guide me towards right >> direction. >> >> ## Problems Statement >> >> Treeset#add method documentations : ?adds the specified element e to this >> set if the set contains no element e2 such that (e==null ? e2==null : >> e.equals(e2))? >> >> Inconsistencies: >> >> > If we try to add ?null? value, it will throws NullPointerException, >> hence >> > e and e2 can not be null. >> >> >> >> > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to >> > collection. >> >> >> Request you to help me understand if behavior of Treeset#add method is as >> expected, and differ with set interface documentation. We may have to >> consider to update method documentations, if behavior is expected. >> >> For more details I have attached the sample java application. >> >> I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK 8u181. >> >> Thanks & Regards, >> *Kishor Golapelliwar,* >> The ability to convert ideas to things is the secret to outward success. >> > > -- Thanks & Regards, *Kishor Golapelliwar,* The ability to convert ideas to things is the secret to outward success. From kim.barrett at oracle.com Mon Oct 15 17:50:21 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Oct 2018 13:50:21 -0400 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator In-Reply-To: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> References: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> Message-ID: > On Oct 15, 2018, at 8:22 AM, Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8212178 > > See the details in the bug. We are hitting this race when Shenandoah is running in aggressive mode > and evacuates lots of objects all the time, processing references very often. This makes weak > reference reclamation races very visible. > > Fix: > http://cr.openjdk.java.net/~shade/8212178/webrev.01/ > > I took the liberty of rewriting the entire method to make it more straightforward. New code > guarantees we never return "null" from this method. > > Testing: failing tests, jdk:tier1, jdk-submit (running) > > Thanks, > -Aleksey Change looks good. Update copyright? The class documentation here seems very confusing to me, like it?s not really about this class at all. But that?s an entirely different problem. From vicente.romero at oracle.com Mon Oct 15 17:51:51 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 15 Oct 2018 13:51:51 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> Message-ID: <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> adding core-libs in the loop On 10/10/2018 12:30 PM, Vicente Romero wrote: > Hi all, > > I have updated the webrev [1], this version removes the `implements > Constable` from the symbolic descriptor classes. Feedback is mostly > appreciated, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch > > On 10/06/2018 05:00 PM, Brian Goetz wrote: >> What we decided to do here is to hold back on ?implements Constable? >> for the symbolic descriptor classes in the initial push of JEP-334, >> and then when we have the symbolic expression mode for BSMs, >> re-implement those in XxxDesc using that.? Implementing Constable >> isn?t needed until we get to the full constant folding anyway.? That >> linearizes the dependencies ? first JEP-334, then symbolic mode BSM, >> then update JEP-334 classes to implement Constable using symbolic >> mode BSM. >> >>> On Sep 13, 2018, at 9:07 PM, John Rose wrote: >>> >>> I am running a review of VM-level work on bootstrap methods >>> which can optionally help simplify some of these APIs: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >>> >>> >>> Specifically, this work can be use to implement a "symbolic >>> expression mode" for BSMs which causes the JVM to unpack >>> constant pool nodes directly as ConstantDesc items to present >>> to BSMs.? This might simplify the condy forms of ConstantDesc >>> instances, if javac stores native constants to reflect, rather than >>> lists of strings to reassemble. >>> >>> ? John >>> >>> On Sep 11, 2018, at 12:50 PM, Vicente Romero >>> wrote: >>>> Please review the first iteration of the implementation for JEP-334 >>>> [1] JVM Constants API. The implementation can be found at [2]. >>>> JEP-334 introduces an API to model nominal descriptions of key >>>> class-file and run-time artifacts, in particular constants that are >>>> loadable from the constant pool and has already been the subject of >>>> several discussions. The implementation of this JEP has been >>>> publicly accessible throw the amber repo at [3] in the jep-334 >>>> branch. Thanks to all members of the Amber project and specially to >>>> Brian for all the hard work on the design and the implementation of >>>> this API. Thanks for all the feedback we have received so far, most >>>> of it has been integrated in the current implementation. >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://openjdk.java.net/jeps/334 >>>> [2] >>>> http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>>> [3] http://hg.openjdk.java.net/amber/amber > From vicente.romero at oracle.com Mon Oct 15 18:12:40 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 15 Oct 2018 14:12:40 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> Message-ID: <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Hi all, sorry for the repeated number of mails on this issue. I have added a direct link to the patch the right link to the webrev is [1] there is a previous version at [2] if you want to see the differences with the last version. Basically we have dropped the `implements Constable` for the symbolic descriptor classes and removed all of the code that was useful for constant folding but not strictly necessary for the API. For more information on the JEP see [3] [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00 [3] http://openjdk.java.net/jeps/334 On 10/15/2018 01:51 PM, Vicente Romero wrote: > adding core-libs in the loop > > On 10/10/2018 12:30 PM, Vicente Romero wrote: >> Hi all, >> >> I have updated the webrev [1], this version removes the `implements >> Constable` from the symbolic descriptor classes. Feedback is mostly >> appreciated, >> >> Thanks, >> Vicente >> >> [1] >> http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch >> >> On 10/06/2018 05:00 PM, Brian Goetz wrote: >>> What we decided to do here is to hold back on ?implements Constable? >>> for the symbolic descriptor classes in the initial push of JEP-334, >>> and then when we have the symbolic expression mode for BSMs, >>> re-implement those in XxxDesc using that.? Implementing Constable >>> isn?t needed until we get to the full constant folding anyway.? That >>> linearizes the dependencies ? first JEP-334, then symbolic mode BSM, >>> then update JEP-334 classes to implement Constable using symbolic >>> mode BSM. >>> >>>> On Sep 13, 2018, at 9:07 PM, John Rose wrote: >>>> >>>> I am running a review of VM-level work on bootstrap methods >>>> which can optionally help simplify some of these APIs: >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >>>> >>>> >>>> Specifically, this work can be use to implement a "symbolic >>>> expression mode" for BSMs which causes the JVM to unpack >>>> constant pool nodes directly as ConstantDesc items to present >>>> to BSMs.? This might simplify the condy forms of ConstantDesc >>>> instances, if javac stores native constants to reflect, rather than >>>> lists of strings to reassemble. >>>> >>>> ? John >>>> >>>> On Sep 11, 2018, at 12:50 PM, Vicente Romero >>>> wrote: >>>>> Please review the first iteration of the implementation for >>>>> JEP-334 [1] JVM Constants API. The implementation can be found at >>>>> [2]. JEP-334 introduces an API to model nominal descriptions of >>>>> key class-file and run-time artifacts, in particular constants >>>>> that are loadable from the constant pool and has already been the >>>>> subject of several discussions. The implementation of this JEP has >>>>> been publicly accessible throw the amber repo at [3] in the >>>>> jep-334 branch. Thanks to all members of the Amber project and >>>>> specially to Brian for all the hard work on the design and the >>>>> implementation of this API. Thanks for all the feedback we have >>>>> received so far, most of it has been integrated in the current >>>>> implementation. >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://openjdk.java.net/jeps/334 >>>>> [2] >>>>> http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>>>> [3] http://hg.openjdk.java.net/amber/amber >> > From shade at redhat.com Mon Oct 15 18:13:54 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Oct 2018 20:13:54 +0200 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator In-Reply-To: References: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> Message-ID: On 10/15/2018 07:50 PM, Kim Barrett wrote: >> Fix: >> http://cr.openjdk.java.net/~shade/8212178/webrev.01/ > > Change looks good. Update copyright? Thanks! Updated. jdk-submit is clean, I am going to push it soon. > The class documentation here seems very confusing to me, like it?s not really about > this class at all. But that?s an entirely different problem. Right. -Aleksey From joe.darcy at oracle.com Mon Oct 15 18:20:22 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 15 Oct 2018 11:20:22 -0700 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator In-Reply-To: References: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> Message-ID: <5BC4DA66.5010205@oracle.com> I think it would be reasonable to give engineers who work in the XML area some time to review the fix as well before it is pushed. Cheers, -Joe On 10/15/2018 11:13 AM, Aleksey Shipilev wrote: > On 10/15/2018 07:50 PM, Kim Barrett wrote: >>> Fix: >>> http://cr.openjdk.java.net/~shade/8212178/webrev.01/ >> Change looks good. Update copyright? > Thanks! Updated. jdk-submit is clean, I am going to push it soon. > >> The class documentation here seems very confusing to me, like it?s not really about >> this class at all. But that?s an entirely different problem. > Right. > > -Aleksey > > From huizhe.wang at oracle.com Mon Oct 15 19:24:26 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 15 Oct 2018 12:24:26 -0700 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator In-Reply-To: <5BC4DA66.5010205@oracle.com> References: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> <5BC4DA66.5010205@oracle.com> Message-ID: <5BC4E96A.1020402@oracle.com> Thanks Joe for the reminder, and thanks all for doing this! The change looks good to me as well. I assume you updated copyright locally, not reflected in the webrev. With regards to the class documentation, it's confusing probably due to a class refactoring during the development. That part of the history was gone. But we know what's going on, so we can leave it as is since it's in maintenance. Best, Joe On 10/15/18, 11:20 AM, Joseph D. Darcy wrote: > I think it would be reasonable to give engineers who work in the XML > area some time to review the fix as well before it is pushed. > > Cheers, > > -Joe > > > On 10/15/2018 11:13 AM, Aleksey Shipilev wrote: >> On 10/15/2018 07:50 PM, Kim Barrett wrote: >>>> Fix: >>>> http://cr.openjdk.java.net/~shade/8212178/webrev.01/ >>> Change looks good. Update copyright? >> Thanks! Updated. jdk-submit is clean, I am going to push it soon. >> >>> The class documentation here seems very confusing to me, like it?s >>> not really about >>> this class at all. But that?s an entirely different problem. >> Right. >> >> -Aleksey >> >> > From shade at redhat.com Mon Oct 15 20:34:18 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 15 Oct 2018 22:34:18 +0200 Subject: RFR (S) 8212178: Soft reference reclamation race in com.sun.xml.internal.stream.util.ThreadLocalBufferAllocator In-Reply-To: <5BC4E96A.1020402@oracle.com> References: <89f8f139-6e77-afad-26cf-f1f411355c5d@redhat.com> <5BC4DA66.5010205@oracle.com> <5BC4E96A.1020402@oracle.com> Message-ID: Thanks! Pushed. -Aleksey On 10/15/2018 09:24 PM, Joe Wang wrote: > Thanks Joe for the reminder, and thanks all for doing this! The change looks good to me as well. I > assume you updated copyright locally, not reflected in the webrev. With regards to the class > documentation, it's confusing probably due to a class refactoring during the development. That part > of the history was gone. But we know what's going on, so we can leave it as is since it's in > maintenance. > > Best, > Joe > > On 10/15/18, 11:20 AM, Joseph D. Darcy wrote: >> I think it would be reasonable to give engineers who work in the XML area some time to review the >> fix as well before it is pushed. >> >> Cheers, >> >> -Joe >> >> >> On 10/15/2018 11:13 AM, Aleksey Shipilev wrote: >>> On 10/15/2018 07:50 PM, Kim Barrett wrote: >>>>> Fix: >>>>> ? http://cr.openjdk.java.net/~shade/8212178/webrev.01/ >>>> Change looks good.? Update copyright? >>> Thanks! Updated. jdk-submit is clean, I am going to push it soon. >>> >>>> The class documentation here seems very confusing to me, like it?s not really about >>>> this class at all.? But that?s an entirely different problem. >>> Right. >>> >>> -Aleksey >>> >>> >> From huizhe.wang at oracle.com Mon Oct 15 22:00:36 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 15 Oct 2018 15:00:36 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> Message-ID: <5BC50E04.9010703@oracle.com> On 10/14/18, 11:08 AM, Alan Bateman wrote: > On 12/10/2018 20:16, Joe Wang wrote: >> Hi all, >> >> Here's an update based on all of the great reviews and comments >> (thanks all!): >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >> >> Current version: >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ > I think the javadoc looks good now. > > I agree that starting with a simple implementation is okay, it can be > improved in time. One thing to fix is totalRead that needs to be a > long to give the correct result on large files that mismatch at > position > 2GB. Fixed. -Joe > > -Alan From huizhe.wang at oracle.com Mon Oct 15 22:14:29 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 15 Oct 2018 15:14:29 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> Message-ID: <5BC51145.4000704@oracle.com> On 10/14/18, 6:48 PM, Weijun Wang wrote: > Hi Joe > > Two comments: > > 1. How about (path1, path2)? I take a look at other similar APIs, some use (c1,c2) and some (a,b). It's true we have some inconsistencies there. Arrays.mismatch for example, named the parameters (a,b). Arguably though, they should have been (a, a2) if they wanted to maintain consistency with then existing "equals" methods. In our case, since Files.isSameFile was (path, path2), Files.mismatch(path, path2) is desirable since it is extending the former's functionality. > > 2. Could the method be non-reflexive even if fs is non static? isSameFile(f,f) is always true. > > + *

    This method may not be atomic with respect to other file system > + * operations. If the file system and files remain static then this method > + * isreflexive (for {@code Path} {@code f}, {@code mismatch(f,f)} > + * returns {@code -1L}) You're right. The javadoc is updated now with the If statement moved to cover the symmetric case only. Current: specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v03/java/nio/file/Files.html webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v03/ previous: specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ Thanks, Joe > > Thanks > Max > >> On Oct 13, 2018, at 3:16 AM, Joe Wang wrote: >> >> Hi all, >> >> Here's an update based on all of the great reviews and comments (thanks all!): >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >> >> Current version: >> specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ >> >> Previous version: >> specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ >> >> It's been a while, so here's a summary of what's changed: >> >> Spec: Alan's patch to fix inconsistencies in wording/terminology >> Impl: s/mismatchByAttrs and etc/isSameFile; >> Stick with the simple implementation (InputStream/Buffer) for now. Further improvement may be done if there's a need; >> The impl is smaller than the previous version, merged the code into Files, removed FilesMismatch.java; >> >> Test: more readable variables instead of the array of test files >> more comments on the testcases >> improved the private methods used for generating the test files >> >> Thanks, >> Joe >> >> On 9/21/18, 6:49 PM, Joe Wang wrote: >>> On 9/20/18, 2:46 PM, Stuart Marks wrote: >>>> >>>> On 9/19/18 11:48 AM, Joe Wang wrote: >>>>> After much discussion and 10 iterations of reviews, this proposal has evolved from what was the original isSameContent method to a mismatch method. API-wise, a compare method was also considered as it looked like just a short step forward from mismatch, however, it was eventually dropped since there is no convincing use case comparing files lexicographically by contents. Impl-wise, extensive performance benchmarking has been done to compare a buffered reading vs memory mapping, the result was that a simple buffered reading performed better among small files, and those with the mismatched byte closer to the beginning of files. Since the proposed method's targeted files are small ones, the impl currently does a buffered reading only. >>>> Hi Joe, >>>> >>>> Thanks for being persistent with this one! >>> Thanks for the help, and the "lot of stuff" with clear indicators (e.g. line numbers and etc.)! From JDK 11 to 12, hopefully wont be deferred to 13 :-) >>>> A very small spec nitpick: >>>> >>>>> specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff/java/nio/file/Files.html >>>> 1544 *

  • {@link #isSameFile(Path, Path) isSameFile(path, path2)} returns true,
    • >>>> >>>> I would add "or" after the trailing comma. This makes it similar to the two-item list that follows. >>> Done. >>>>> webrev: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev/ >>>> A couple minor comments on FilesMismatch.java: >>>> >>>> If mismatchByAttrs() is replaced with a call to isSameFile(), as Alan suggested, this simplifies things considerably. It looks like the mismatch() implementation will be reduced to around ~40 lines of code. Does it deserve its own file, or can it be placed directly into Files.java? That file has over 4,000 lines already though. >>> I merged the private methods after removing mismatchByAttrs(), that reduced the code to 33 lines, and then with the change you suggested below, it's further reduced to 29 lines. I'll put them in Files for now. >>> >>> Files is too big, ~180K, that compares with the next one ~45K among files in the nio/file package. Unfortunately, the great majority of them are specs, probably 90%. >>>> 106 if (nRead1 == 0 || nRead2 == 0) { >>>> 107 if (nRead1 == 0&& nRead2 == 0) { >>>> 108 // both files reach EOF >>>> 109 return -1; >>>> 110 } else { >>>> 111 // one of the files reaches EOF >>>> 112 return totalRead; >>>> 113 } >>>> 114 } else if (nRead1 != nRead2) { >>>> >>>> I think it reads slightly better if the nested 'if' at lines 107-113 were flattened into the else-if chain, like so: >>>> >>>> if (nRead1 == 0&& nRead2 == 0) { >>>> // both files reached EOF >>>> return -1; >>>> } else if (nRead1 == 0 || nRead2 == 0) { >>>> // one but not both files reached EOF >>>> return totalRead; >>>> } else if (nRead1 != nRead2) { >>>> >>>> There are a couple places where lines can be joined. The resulting lines are longer than 80 characters but are still less than 100 characters, which I think is OK. (I don't think we have a strict limit of 80 anymore.) >>>> >>>> 97 private static long mismatch(InputStream in1, InputStream in2) >>>> 98 throws IOException { >>>> >>>> 117 return totalRead + >>>> 118 Arrays.mismatch(buffer1, 0, len, buffer2, 0, len); >>> Done. 95 characters :-) >>> >>>> Comments on tests in Comparison.java: >>>> >>>> * This file, and several names within this file, should probably should be renamed to focus on mismatch instead of comparison. >>> Will rename to "mismatch". Previously, it covers both mismatch and compare. >>>> * I'm finding it quite difficult to read the test cases. >>>> >>>> The test files are placed into a Path[] and referenced by index. This makes it quite difficult to determine, for example, if all six cases within the mismatch loop are covered. >>>> >>>> Instead of storing the files at specific array indexes, I'd suggest doing the following. >>>> >>>> 1) Establish good naming conventions for test files, including size information, covering duplicate files (e.g., 'a' and 'b'), and a modification at a particular offset. For example, you might do something like the following: >>>> >>>> test120a - a test file with size 120 >>>> test120b - a test file with size 120, identical to test120a >>>> test120m110 - a test file with size 120, with an altered byte at 110 >>>> etc. >>> I can do that. I had hoped the Assertion msg, e.g. "Both files are empty, no mismatch" would help. Along with renaming variables, I will also add to the Assertion Msg with test case number, e.g. "Case#1: both files are empty, return no mismatch". >>>> 2) Declare fields of the same name containing the file paths. >>>> >>>> 3) Add some logic in prepareTestFile() to append each file's path to a list after the file is created. Then have the @AfterClass method run through this list and delete the files. >>> May also create the test files in a folder and delete it @AfterClass. >>>> 4) The test data generator method can then have lines of test data that reference the test files using a meaningful name, so it's easy to understand the names and the expected results. Also, the test data generator should have a comment that describes the test method parameters. >>> Sure, will add comments and etc. >>>> * The generation of the test data files seems overly complicated. >>>> >>>> A StringBuilder is used to accumulate data, then it's turned into a String, then (optionally) a character is replaced by the insertChar() method, and then the string is written to the file. >>>> >>>> I think you can just accumulate the test data into a StringBuilder, (optionally) call sb.setCharAt() to modify the data, and then write the SB to the file. After all, Files.writeString() takes a CharSequence. >>>> >>>> The generateFixedString() method should be changed to create and return a fresh StringBuilder with the desired contents. (See above.) It can also be simplified quite a bit. >>> Wouldn't it be nice if String has an utility method that generates random ASCII strings? ;-) It can be faster with its internal byte array. >>>> I don't think you need to have methods with Charset parameters. It's reasonable to have the test files be text, which makes things easier to develop and debug. But the test depends on characters being written in a single-byte charset, because mismatch() reports *byte* positions and not *character* positions. >>>> >>>> Using the method overloads that are implicitly UTF-8 is incorrect. If a non-single-byte character were to slip into the test data (seems unlikely, but possible), it'll be expanded to multiple bytes by the UTF-8 encoder, which may throw off the result. Instead I'd suggest hardwiring the charset to be US_ASCII to enforce the one-byte-per-character invariant. >>>> >>>> This is a lot of stuff. If you can't follow it all, perhaps we can work together directly and go over the test file. >>> I'll improve the test, and US_ASCII it is! I'll probably use a string of fixed length to generate the longest string the test needs, and then get substrings for other test cases, that may simplify the process. >>> >>> Thanks, >>> Joe >>> >>>> Thanks, >>>> >>>> s'marks From kim.barrett at oracle.com Mon Oct 15 23:25:47 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 15 Oct 2018 19:25:47 -0400 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: > On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov wrote: > > Kim, > > If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. What is "sufficient lead time"? I'm not proposing an answer, just suggesting that 3 months (approx time between JEP publication and JDK 12 fork) might be sufficient, and a worthy goal. That's a decision that ought to be made as part of the Targeting discussion for this JEP. Right now, it's not even a Candidate, since there's still work to be done. > Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. That's good news, though pretty much what I expected. I'm more worried about Solaris. Having a goal of JDK 12 may help move things along. From weijun.wang at oracle.com Tue Oct 16 00:39:19 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Oct 2018 08:39:19 +0800 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC51145.4000704@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <5BC51145.4000704@oracle.com> Message-ID: <0D03B0EC-DA10-4208-88A3-EE3A986ACD0A@oracle.com> > On Oct 16, 2018, at 6:14 AM, Joe Wang wrote: > > > > On 10/14/18, 6:48 PM, Weijun Wang wrote: >> Hi Joe >> >> Two comments: >> >> 1. How about (path1, path2)? I take a look at other similar APIs, some use (c1,c2) and some (a,b). > > It's true we have some inconsistencies there. Arrays.mismatch for example, named the parameters (a,b). Arguably though, they should have been (a, a2) if they wanted to maintain consistency with then existing "equals" methods. In our case, since Files.isSameFile was (path, path2), Files.mismatch(path, path2) is desirable since it is extending the former's functionality. Oops, I didn't notice this one. You're right. Thanks Max From jonathan.gibbons at oracle.com Tue Oct 16 03:45:45 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 15 Oct 2018 20:45:45 -0700 Subject: RFR:8211957 : Broken links to stylesheet in java.base/doc-files In-Reply-To: <01071336-cd36-7d1a-d1f8-f9e0bcbfe79c@oracle.com> References: <01071336-cd36-7d1a-d1f8-f9e0bcbfe79c@oracle.com> Message-ID: OK On 10/15/18 3:32 AM, Priya Lakshmi Muthuswamy wrote: > Hi, > > Kindly review trivial fix for > https://bugs.openjdk.java.net/browse/JDK-8211957 > webrev : http://cr.openjdk.java.net/~pmuthuswamy/8211957/webrev.00/ > > Thanks, > Priya > > From t.linkowski at gmail.com Tue Oct 16 06:35:46 2018 From: t.linkowski at gmail.com (Tomasz Linkowski) Date: Tue, 16 Oct 2018 08:35:46 +0200 Subject: Why Stream.concat is a static method - type variable contravariance In-Reply-To: References: <13146dc3-bf6a-f7c4-eba6-bf1220a49a6a@oracle.com> Message-ID: I second that `Stream.append` would be a very useful addition, although I would definitely propose it as Stream append(Stream other) -> Stream.concat(this, other); Of course, we could also have a convenience overload like Stream append(T... values) -> append(Arrays.stream(values)); but I do not find it nearly as important. As for `Stream.prepend`, I find it quite non-intuitive because of the flow inversion. For example, I *much* prefer var remainingStream = list.stream() .filter(...) .map(...); Stream.of(specialElement).append(remainingStream).collect(toList()); to list.stream() .filter(...) .map(...) .prepend(specialElement) .collect(toList()); even though the latter is shorter and it's a single expression. Also, note how Stream.of(specialElement).append(remainingStream).collect(toList()); has better "flow" than Stream.concat(Stream.of(specialElement), remainingStream).collect(toList()); Regards, Tomasz Linkowski On Mon, Oct 15, 2018 at 4:51 AM Tagir Valeev wrote: > Hello! > > Still from the practical point of view it would be really helpful to > have instance methods like `Stream.append(T... elements)` and > `Stream.prepend(T... elements)` (default implementation may utilize > `concat`). Very often it's necessary to add one or two special > elements to the stream, and using the `concat` makes code very ugly. > > C.f.: > > > list.stream().filter(...).map(...).append(specialElement).collect(toList()); > v.s.: > Stream.concat(list.stream().filter(...).map(...), > Stream.of(specialElement)).collect(toList()); > > Currently I prefer this (unless I can use third-party libraries which > provide `append`): > List result = list.stream().filter(...).map(...).collect(toList()); > // toCollection(ArrayList::new) for purists > result.add(specialElement); > > With best regards, > Tagir Valeev. > On Thu, Oct 11, 2018 at 11:11 PM Brian Goetz > wrote: > > > > It would surely be convenient; I've wished for this a few times. But, > > there's a reason for this choice, and its not just laziness; > > contravariant type variables have some pretty scary challenges. See, for > > example, this paper: > > > > http://www.cis.upenn.edu/~bcpierce/papers/variance.pdf > > > > in which it is shown that contravariance is one of the ingredients in a > > witches brew that leads to undecideability of type checking. > > > > > > > > On 10/11/2018 12:06 AM, James Roper wrote: > > > With the work I'm doing at the moment at creating a Reactive Streams > > > equivalent to java.util.stream, I've often wondered why Stream.concat > is a > > > static method, rather than an instance method concating the given > stream > > > onto this. But I think the reason has just dawned on me, and I wanted > to > > > confirm that I'm correct. > > > > > > Java doesn't support contravariant type variables - it does for type > > > declarations, but not type variables. > > > > > > To put more concretely, if I had a Stream, and I wanted to > concat > > > a Stream, this is a valid thing to do, the resulting stream > would > > > be Stream. But doing that with an instance method would require > > > something like this: > > > > > > public Stream concat(Stream b); > > > > > > Which is not supported (specifically, type variable > declaration > > > is not supported). In contrast, what we have in the actual API: > > > > > > public static Stream concat(Stream a, Stream extends > > > T> b); > > > > > > does allow me to concat a Stream and Stream with a > > > resulting type of Stream. > > > > > > Is this right, or are there other reasons? Also, is there any > possibility > > > that Java might support contravariance in type variables in future? My > > > reason for wanting it is to provide the following method for reactive > > > streams: > > > > > > public Publisher onErrorResumeWith(Function > > Throwable, ? extends Publisher> f); > > > > > > The intent of this method is when a stream encounters an error, the > passed > > > function is invoked with the error, and that function returns a > publisher > > > that gets concated to the current stream instead of the error being > > > emitted. This could possibly be implemented with a static method: > > > > > > public static Publisher onErrorResumeWith(Publisher T> a, > > > Function f); > > > > > > But unlike concat, this method feels and reads much better as an > instance > > > method, as a static method it's a little confusing. > > > > > > Regards, > > > > > > James > > > > > > -- Pozdrawiam, Tomasz Linkowski From daniel.fuchs at oracle.com Tue Oct 16 09:11:18 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Oct 2018 10:11:18 +0100 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC0F2F2.8040600@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> Message-ID: <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> Hi Joe, There are a few places where {@linkplain } should be used instead of {@link }. For instance: 1545 *
  • The two paths locate the {@link #isSameFile(Path, Path) same file}, This should be {@linkplain } - for the record {@link } will format the text as code, {@linkplain } will format it as regular text. Since the text of the link is "same file" then it should be formatted as regular text - not as code. The link on the next line should probably be {@linkplain } as well. Otherwise looks good to me (except for the declaration of int totalRead that should be long but Alan already mentioned it). best regards, -- daniel On 12/10/2018 20:16, Joe Wang wrote: > Here's an update based on all of the great reviews and comments (thanks > all!): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 > CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 > > Current version: > specdiff: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html > > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ > > Previous version: > specdiff: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html > > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ > > It's been a while, so here's a summary of what's changed: > > Spec: Alan's patch to fix inconsistencies in wording/terminology > Impl: s/mismatchByAttrs and etc/isSameFile; > ???????? Stick with the simple implementation (InputStream/Buffer) for > now. Further improvement may be done if there's a need; > ???????? The impl is smaller than the previous version, merged the code > into Files, removed FilesMismatch.java; > > Test: more readable variables instead of the array of test files > ???????? more comments on the testcases > ???????? improved the private methods used for generating the test files > > Thanks, > Joe From mandy.chung at oracle.com Tue Oct 16 16:08:27 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Oct 2018 09:08:27 -0700 Subject: Review Request: JDK-8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference Message-ID: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8207146/webrev.00/ Unsafe::getObject returns a reference to an object. Similarly Unsafe::putObject sets a reference in the given base+offset. This patch proposes to rename Unsafe xxxObject to xxxReference that will make the xxxReference API very clear that these are getters/setters for a reference (instance of object class) and ready for adding xxxValue in the futurefor values. Note that this renaming only applies to jdk.internal.misc.Unsafe but not sun.misc.Unsafe.? So no impact to existing libraries that depends on sun.misc.Unsafe in jdk.unsupported module. I ran jdk_core, core_tools, langtools and nashorn tier1-3, hotspot_runtime, hotspot_compiler test groups. thanks Mandy From huizhe.wang at oracle.com Tue Oct 16 18:10:32 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 16 Oct 2018 11:10:32 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> Message-ID: <5BC62998.6040507@oracle.com> Hi Daniel, @linkplain it is! Thanks! And yes, int totalRead was fixed in the previous webrevs. Current version: specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v04/java/nio/file/Files.html webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v04/ Previous version: specdiff: http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v03/java/nio/file/Files.html webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v03/ Best regards, Joe On 10/16/18, 2:11 AM, Daniel Fuchs wrote: > Hi Joe, > > There are a few places where {@linkplain } should be used instead > of {@link }. For instance: > > 1545 *
  • The two paths locate the {@link #isSameFile(Path, > Path) same file}, > > This should be {@linkplain } - for the record {@link } will format the > text as code, {@linkplain } will format it as regular text. Since the > text of the link is "same file" then it should be formatted as regular > text - not as code. > > The link on the next line should probably be {@linkplain } as well. > > Otherwise looks good to me (except for the declaration of > int totalRead that should be long but Alan already mentioned it). > > best regards, > > -- daniel > > > On 12/10/2018 20:16, Joe Wang wrote: >> Here's an update based on all of the great reviews and comments >> (thanks all!): >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >> >> Current version: >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >> >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ >> >> Previous version: >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html >> >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ >> >> It's been a while, so here's a summary of what's changed: >> >> Spec: Alan's patch to fix inconsistencies in wording/terminology >> Impl: s/mismatchByAttrs and etc/isSameFile; >> Stick with the simple implementation (InputStream/Buffer) >> for now. Further improvement may be done if there's a need; >> The impl is smaller than the previous version, merged the >> code into Files, removed FilesMismatch.java; >> >> Test: more readable variables instead of the array of test files >> more comments on the testcases >> improved the private methods used for generating the test >> files >> >> Thanks, >> Joe > From Alan.Bateman at oracle.com Tue Oct 16 18:31:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2018 19:31:17 +0100 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC62998.6040507@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> Message-ID: <56d4f9fd-cf01-bdf5-8afb-836eb97bb4d4@oracle.com> On 16/10/2018 19:10, Joe Wang wrote: > Hi Daniel, > > @linkplain it is!? Thanks!? And yes, int totalRead was fixed in the > previous webrevs. > > Current version: > specdiff: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v04/java/nio/file/Files.html > > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v04/ The javadoc and starting implementation looks okay now. I haven't had time to go over the test so hopefully someone else has time to look at that. -Alan From Roger.Riggs at oracle.com Tue Oct 16 19:53:11 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 16 Oct 2018 15:53:11 -0400 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: Message-ID: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> Hi Brian, Sorry for the delay in looking at this. InputStream.java: 584:? Is there really a case where line 585 would throw the exception? skip(n, true) != n With the 2nd argument = true, it will either skip the bytes or throw. I think you can just call:? "skip(n, true); Given subclasses of InputStream that might override skip(n) with a more efficient mechanism would it make sense to implement skipNBytes in terms of skip(n)? As is, it always uses read() to skip the bytes, which might not be as efficient as possible on some streams (for example a very large file) where a seek could be used. test/jdk/java/io/InputStream/Skip.java: There is a lot of whitespace in this test, spaces before "," and extra blank lines. 97: "possible result" - does that occur in the tests?? The "possible" is a bit ambiguous especially given the very narrow test case. It would be useful to include the message from the exception. Regards, Roger On 10/01/2018 05:44 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-6516099 > http://cr.openjdk.java.net/~bpb/6516099/webrev.00/ > > This patch implements a method InputStream.skipNBytes() instead of skipFully() based on the supposition that this name is less likely to conflict with existing subclasses, e.g., [1]. There is some inconsistency however with respect to the description of the method readNBytes() [2], which may return fewer than N bytes if end of stream is reached first. > > If we converge on a solution in this thread I?ll file a CSR. > > Thanks, > > Brian > > [1] https://developer.ibm.com/static/site-id/155/maximodev/7609/maximocore/businessobjects/psdi/iface/webservices/action/bytecode/ClassReader.html > [2] https://download.java.net/java/early_access/jdk12/docs/api/java.base/java/io/InputStream.html#readNBytes(byte[],int,int) From brian.burkhalter at oracle.com Tue Oct 16 20:06:35 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Oct 2018 13:06:35 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> Message-ID: <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> Hi Roger, > On Oct 16, 2018, at 12:53 PM, Roger Riggs wrote: > > InputStream.java: > > 584: Is there really a case where line 585 would throw the exception? > > skip(n, true) != n > > With the 2nd argument = true, it will either skip the bytes or throw. > I think you can just call: "skip(n, true); I think you are correct. > Given subclasses of InputStream that might override skip(n) with a more efficient mechanism > would it make sense to implement skipNBytes in terms of skip(n)? > As is, it always uses read() to skip the bytes, which might not be as efficient as possible > on some streams (for example a very large file) where a seek could be used. That?s a good point. I had some trepidation about the vague wording of skip(n) in terms of how many bytes it actually reads. > test/jdk/java/io/InputStream/Skip.java: > > There is a lot of whitespace in this test, spaces before "," and extra blank lines. Yes it is rather ugly. I chose to leave it as is for initial clarity intending to clean it up later. > 97: "possible result" - does that occur in the tests? The "possible" is a bit ambiguous especially given the very narrow test case. It would be useful to include the message from the exception. Copy-paste garbage. I?ll update it to include the message. Thanks, Brian From brian.burkhalter at oracle.com Tue Oct 16 20:52:02 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 16 Oct 2018 13:52:02 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> Message-ID: Hi Roger, Updated patch: http://cr.openjdk.java.net/~bpb/6516099/webrev.01/ Thanks, Brian > On Oct 16, 2018, at 1:06 PM, Brian Burkhalter wrote: > >> On Oct 16, 2018, at 12:53 PM, Roger Riggs > wrote: >> >> InputStream.java: >> >> 584: Is there really a case where line 585 would throw the exception? >> >> skip(n, true) != n >> >> With the 2nd argument = true, it will either skip the bytes or throw. >> I think you can just call: "skip(n, true); > > I think you are correct. > >> Given subclasses of InputStream that might override skip(n) with a more efficient mechanism >> would it make sense to implement skipNBytes in terms of skip(n)? >> As is, it always uses read() to skip the bytes, which might not be as efficient as possible >> on some streams (for example a very large file) where a seek could be used. > > That?s a good point. I had some trepidation about the vague wording of skip(n) in terms of how many bytes it actually reads. > >> test/jdk/java/io/InputStream/Skip.java: >> >> There is a lot of whitespace in this test, spaces before "," and extra blank lines. > > Yes it is rather ugly. I chose to leave it as is for initial clarity intending to clean it up later. > >> 97: "possible result" - does that occur in the tests? The "possible" is a bit ambiguous especially given the very narrow test case. It would be useful to include the message from the exception. > > Copy-paste garbage. I?ll update it to include the message. From dan.z.zhou at oracle.com Wed Oct 17 03:01:24 2018 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Wed, 17 Oct 2018 11:01:24 +0800 Subject: [12]RFR 8210406: Refactor java.util.PluggableLocale:i18n shell tests to plain java tests Message-ID: <7e8a5036-8d76-1dbf-2bee-b564229fc68b@oracle.com> Hello, Please help review the fix for refactor java.util.PluggableLocale:i18n shell tests to plain java tests. Thank you. Bug: https://bugs.openjdk.java.net/browse/JDK-8210406 webrev: http://cr.openjdk.java.net/~dzhou/8210406/webrev.02/ Regards, Dora From david.holmes at oracle.com Wed Oct 17 03:33:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Oct 2018 13:33:19 +1000 Subject: Review Request: JDK-8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference In-Reply-To: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> References: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> Message-ID: <237430e1-5aea-6c0b-3317-14f12aec72c8@oracle.com> Hi Mandy, I took a look through all of this and it seems okay - though it was a little surprising how far the name change needed to spread. Thanks, David On 17/10/2018 2:08 AM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8207146/webrev.00/ > > Unsafe::getObject returns a reference to an object. Similarly > Unsafe::putObject sets a reference in the given base+offset. > This patch proposes to rename Unsafe xxxObject to xxxReference > that will make the xxxReference API very clear that these > are getters/setters for a reference (instance of object class) > and ready for adding xxxValue in the futurefor values. > Note that this renaming only applies to jdk.internal.misc.Unsafe > but not sun.misc.Unsafe.? So no impact to existing libraries > that depends on sun.misc.Unsafe in jdk.unsupported module. > > I ran jdk_core, core_tools, langtools and nashorn tier1-3, > hotspot_runtime, hotspot_compiler test groups. > > thanks > Mandy From sean.coffey at oracle.com Wed Oct 17 10:25:57 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 17 Oct 2018 11:25:57 +0100 Subject: RFR: 8148188: Enhance the security libraries to record events of interest In-Reply-To: References: <822f8eb2-95b6-410d-6504-ce52d9154ed0@oracle.com> <5B2F9ADD.1040809@oracle.com> <03d38c51-cd81-3c91-b4e0-d380fad92725@oracle.com> <02b1a436-a496-f3e2-8e04-a82e841eda81@oracle.com> <1d287e4c-194c-5684-cd65-8d6b5a2f2047@oracle.com> <5B33EC28.6090604@oracle.com> <5B350AE5.3080401@oracle.com> <4F777EA1-6402-4725-B4E8-6DCB61DD4E19@oracle.com> <5B438B82.6070601@oracle.com> <00051b46-46a7-5c96-f36b-fb2e2fed8a58@oracle.com> Message-ID: <99c29269-1332-1a2d-c2a2-4b7479177488@oracle.com> I'd like to re-boot this review. I've been working with Erik off thread who's been helping with code and test design. Some of the main changes worthy of highlighting : * Separate out the tests for JFR and Logger events * Rename some events * Normalize the data view for X509ValidationEvent (old event name : CertChainEvent) * Introduce CertificateSerialNumber type to make use of the @Relational JFR annotation. * Keep calls for JFR event operations local to call site to optimize jvm compilation webrev : http://cr.openjdk.java.net/~coffeys/webrev.8148188.v6/webrev/ This code is dependent on the JDK-8203629 enhancement being integrated. Regards, Sean. On 10/07/18 13:50, Se?n Coffey wrote: > Erik, > > After some trial edits, I'm not so sure if moving the event & logger > commit code into the class where it's used works too well after all. > > In the code you suggested, there's an assumption that calls such as > EventHelper.certificateChain(..) are low cost. While that might be the > case here, it's something we can't always assume. It's called once for > the JFR operation and once for the Logger operation. That pattern > multiplies itself further in other Events. i.e. set up and assign the > variables for a JFR event without knowing whether they'll be needed > again for the Logger call. We could work around it by setting up some > local variables and re-using them in the Logger code but then, we're > back to where we were. The current EventHelper design eliminates this > problem and also helps to abstract the recording/logging functionality > away from the functionality of the class itself. > > It also becomes a problem where we record events in multiple different > classes (e.g. SecurityPropertyEvent). While we could leave the code in > EventHelper for this case, we then have a mixed design pattern. > > Are you ok with leaving as is for now? A future wish might be one > where JFR would handle Logger via its own framework/API in a future > JDK release. > > I've removed the variable names using underscore. Also optimized some > variable assignments in X509Impl.commitEvent(..) > > http://cr.openjdk.java.net/~coffeys/webrev.8148188.v5/webrev/ > > regards, > Sean. > > On 09/07/2018 18:01, Se?n Coffey wrote: >> Erik, >> >> Thanks for reviewing. Comments inline.. >> >> On 09/07/18 17:21, Erik Gahlin wrote: >>> Thanks Sean. >>> >>> Some feedback on the code in the security libraries. >>> >>> - We should use camel case naming convention for variables (not >>> underscore). >> Sure. I see two offending variable names which I'll fix up. >>> >>> - Looking at sun/security/ssl/Finished.java, >>> >>> I wonder if it wouldn't be less code and more easy to read, if we >>> would commit the event in a local private function and then use the >>> EventHelper class for common functionality. >> I'm fine with your suggested approach. I figured that tucking the >> recording/logging logic away in a helper class also had benefits but >> I'll re-factor to your suggested style unless I hear objections. >> >> regards, >> Sean. >> > From Roger.Riggs at oracle.com Wed Oct 17 14:16:47 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 17 Oct 2018 10:16:47 -0400 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC62998.6040507@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> Message-ID: <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> Hi Joe, Looks good, straightforward and easy to understand. The spec text in the CSR need to be updated to match. (At least the paragraph about reflexive and atomic). Thanks, Roger On 10/16/2018 02:10 PM, Joe Wang wrote: > Hi Daniel, > > @linkplain it is!? Thanks!? And yes, int totalRead was fixed in the > previous webrevs. > > Current version: > specdiff: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v04/java/nio/file/Files.html > > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v04/ > > Previous version: > specdiff: > http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v03/java/nio/file/Files.html > > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v03/ > > Best regards, > Joe > > On 10/16/18, 2:11 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> There are a few places where {@linkplain } should be used instead >> of {@link }. For instance: >> >> 1545????? *
  • The two paths locate the {@link #isSameFile(Path, >> Path) same file}, >> >> This should be {@linkplain } - for the record {@link } will format the >> text as code, {@linkplain } will format it as regular text. Since the >> text of the link is "same file" then it should be formatted as regular >> text - not as code. >> >> The link on the next line should probably be {@linkplain } as well. >> >> Otherwise looks good to me (except for the declaration of >> int totalRead that should be long but Alan already mentioned it). >> >> best regards, >> >> -- daniel >> >> >> On 12/10/2018 20:16, Joe Wang wrote: >>> Here's an update based on all of the great reviews and comments >>> (thanks all!): >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >>> >>> Current version: >>> specdiff: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >>> >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ >>> >>> Previous version: >>> specdiff: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html >>> >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ >>> >>> It's been a while, so here's a summary of what's changed: >>> >>> Spec: Alan's patch to fix inconsistencies in wording/terminology >>> Impl: s/mismatchByAttrs and etc/isSameFile; >>> ????????? Stick with the simple implementation (InputStream/Buffer) >>> for now. Further improvement may be done if there's a need; >>> ????????? The impl is smaller than the previous version, merged the >>> code into Files, removed FilesMismatch.java; >>> >>> Test: more readable variables instead of the array of test files >>> ????????? more comments on the testcases >>> ????????? improved the private methods used for generating the test >>> files >>> >>> Thanks, >>> Joe >> -- Thanks, Roger From claes.redestad at oracle.com Wed Oct 17 14:55:38 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 17 Oct 2018 16:55:38 +0200 Subject: RFR: 8212597: Optimize String concatenation setup when using primitive operands Message-ID: <655d56a8-8685-cf71-2ed2-2f7a38b522ac@oracle.com> Hi, this patch optimizes setup of the default strategy for indified String concat to setup and use fewer intermediary MHs when some arguments are non-char primitives. Webrev: http://cr.openjdk.java.net/~redestad/8212597/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212597 I've cleaned up of the associated StringConcatHelper to remove the mixCoder methods no longer in use, along with a small adjustment to the HelloClasslist tool to exercise more concatenation shapes. With the fix to https://bugs.openjdk.java.net/browse/JDK-8212201 in place this build tool always emit the latest bytecode, which ensures ISC is exercised and part of the feedback loop. This makes sure that input to jlink is kept relevant and up-to-date, and by adding a number of common concatenation shapes we reduce the startup overhead in a few common cases. Testing: ran all String tests locally, sanity JDK tier 1+2 testing on primary platforms Thanks! /Claes From shade at redhat.com Wed Oct 17 15:03:20 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 17 Oct 2018 17:03:20 +0200 Subject: RFR: 8212597: Optimize String concatenation setup when using primitive operands In-Reply-To: <655d56a8-8685-cf71-2ed2-2f7a38b522ac@oracle.com> References: <655d56a8-8685-cf71-2ed2-2f7a38b522ac@oracle.com> Message-ID: <55e56a9e-3ea9-bd2a-6a80-62e435036b4d@redhat.com> On 10/17/2018 04:55 PM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8212597/jdk.00/ Nice. This optimization is obvious in hindsight! -Aleksey From alexandr.miloslavskiy at gmail.com Wed Oct 17 15:08:56 2018 From: alexandr.miloslavskiy at gmail.com (Alexander Miloslavskiy) Date: Wed, 17 Oct 2018 17:08:56 +0200 Subject: Is it possible to find PDB (windows debugging info) for published jvm.dll? Message-ID: Hello, I'm trying to debug a native crash that regularly happens for one of our customers. It crashes somewhere amidst java interpreter code, with corrupted value in CPU's RIP register. So it's quite complicated. It would certainly help me a lot if I had access to jvm.pdb files for published JRE's... I'm mostly after 10.0.1+10 and 8.0_144-b01 at the moment. According to the published binaries, the PDB's are generated here on the build server: t:\workspace\build\windows-x64\support\modules_libs\java.base\server\jvm.pdb I believe they are saved somewhere after building, at least internally? Is there some way to obtain those pdb's myself? If not, can someone send me the PDB's, at least for 10.0.1+10? I understand that I can build OpenJDK myself to obtain the PDB's, but unfortunately they will not match dumps provided by the client. From claes.redestad at oracle.com Wed Oct 17 15:15:41 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 17 Oct 2018 17:15:41 +0200 Subject: RFR: 8212597: Optimize String concatenation setup when using primitive operands In-Reply-To: <55e56a9e-3ea9-bd2a-6a80-62e435036b4d@redhat.com> References: <655d56a8-8685-cf71-2ed2-2f7a38b522ac@oracle.com> <55e56a9e-3ea9-bd2a-6a80-62e435036b4d@redhat.com> Message-ID: <408ff069-2214-8018-36be-ac73d6ab2dc7@oracle.com> On 2018-10-17 17:03, Aleksey Shipilev wrote: > On 10/17/2018 04:55 PM, Claes Redestad wrote: >> Webrev: http://cr.openjdk.java.net/~redestad/8212597/jdk.00/ > Nice. Thanks! > This optimization is obvious in hindsight! Aren't they all? :-) /Claes From naoto.sato at oracle.com Wed Oct 17 17:58:51 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 17 Oct 2018 10:58:51 -0700 Subject: [12]RFR 8210406: Refactor java.util.PluggableLocale:i18n shell tests to plain java tests In-Reply-To: <7e8a5036-8d76-1dbf-2bee-b564229fc68b@oracle.com> References: <7e8a5036-8d76-1dbf-2bee-b564229fc68b@oracle.com> Message-ID: <79e489b4-39ad-0325-2814-7f35c054fab8@oracle.com> Looks good. Naoto On 10/16/18 8:01 PM, Dora Zhou wrote: > Hello, > > Please help review the fix for refactor java.util.PluggableLocale:i18n > shell tests to plain java tests. Thank you. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210406 > > webrev: http://cr.openjdk.java.net/~dzhou/8210406/webrev.02/ > > Regards, > Dora From andrewluotechnologies at outlook.com Wed Oct 17 18:10:41 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 17 Oct 2018 18:10:41 +0000 Subject: [PATCH] Fix typo in javadoc for java.lang.ref.Cleaner Message-ID: Noticed a typo in the Javadoc for Cleaner... Patch attached below: diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java +++ b/src/java.base/share/classes/java/lang/ref/Cleaner.java @@ -100,7 +100,7 @@ * } * } * - * private final State; + * private final State state; * private final Cleaner.Cleanable cleanable * * public CleaningExample() { Thanks, Andrew From lance.andersen at oracle.com Wed Oct 17 18:33:10 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Oct 2018 14:33:10 -0400 Subject: [PATCH] Fix typo in javadoc for java.lang.ref.Cleaner In-Reply-To: References: Message-ID: Change seems to make sense looks like a semi-colon could be added after as well as part of the update: private final Cleaner.Cleanable cleanable > On Oct 17, 2018, at 2:10 PM, Andrew Luo wrote: > > Noticed a typo in the Javadoc for Cleaner... Patch attached below: > > diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java > --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java > +++ b/src/java.base/share/classes/java/lang/ref/Cleaner.java > @@ -100,7 +100,7 @@ > * } > * } > * > - * private final State; > + * private final State state; > * private final Cleaner.Cleanable cleanable > * > * public CleaningExample() { > > Thanks, > > Andrew Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Wed Oct 17 19:16:37 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 17 Oct 2018 12:16:37 -0700 Subject: JDK 12 RFR of JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods In-Reply-To: References: Message-ID: <644c9465-3ea9-cc1b-689a-cbeca90463dc@oracle.com> PS In response to some off-list feedback, an updated webrev uses a stream-ier implementation: ??? http://cr.openjdk.java.net/~darcy/6304578.1/ Thanks, -Joe On 10/11/2018 6:11 PM, joe darcy wrote: > Hello, > > Prompted by recent work on the toString implementations of > AnnotatedType objects > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055937.html), > I rediscovered a long-standing limitation of toGenericString on Type > objects that can be addressed: > > ??? JDK-6304578: (reflect) toGenericString fails to print bounds of > type variables on generic methods > > Please review the small CSR > > ??? https://bugs.openjdk.java.net/browse/JDK-8212094 > > and webrev: > > ??? http://cr.openjdk.java.net/~darcy/6304578.0/ > > Thanks, > > -Joe > From huizhe.wang at oracle.com Wed Oct 17 19:33:57 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 17 Oct 2018 12:33:57 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> Message-ID: <5BC78EA5.1080208@oracle.com> On 10/17/18, 7:16 AM, Roger Riggs wrote: > Hi Joe, > > Looks good, straightforward and easy to understand. Glad to hear that, while it's been back and forth a couple of times, it seems "straightforward and easy" won :-) > > The spec text in the CSR need to be updated to match. (At least the > paragraph about reflexive and atomic). CSR: update the text and attachment https://bugs.openjdk.java.net/browse/JDK-8202302 Also added coverage to spec case 5 - reflexive (no new test cases), spec case 6 - symmetric with tests selected from case 3. webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ Thanks, Joe > > Thanks, Roger > > On 10/16/2018 02:10 PM, Joe Wang wrote: >> Hi Daniel, >> >> @linkplain it is! Thanks! And yes, int totalRead was fixed in the >> previous webrevs. >> >> Current version: >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v04/java/nio/file/Files.html >> >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v04/ >> >> Previous version: >> specdiff: >> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v03/java/nio/file/Files.html >> >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v03/ >> >> Best regards, >> Joe >> >> On 10/16/18, 2:11 AM, Daniel Fuchs wrote: >>> Hi Joe, >>> >>> There are a few places where {@linkplain } should be used instead >>> of {@link }. For instance: >>> >>> 1545 *
  • The two paths locate the {@link #isSameFile(Path, >>> Path) same file}, >>> >>> This should be {@linkplain } - for the record {@link } will format the >>> text as code, {@linkplain } will format it as regular text. Since the >>> text of the link is "same file" then it should be formatted as regular >>> text - not as code. >>> >>> The link on the next line should probably be {@linkplain } as well. >>> >>> Otherwise looks good to me (except for the declaration of >>> int totalRead that should be long but Alan already mentioned it). >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 12/10/2018 20:16, Joe Wang wrote: >>>> Here's an update based on all of the great reviews and comments >>>> (thanks all!): >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >>>> >>>> Current version: >>>> specdiff: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >>>> >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ >>>> >>>> Previous version: >>>> specdiff: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html >>>> >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ >>>> >>>> It's been a while, so here's a summary of what's changed: >>>> >>>> Spec: Alan's patch to fix inconsistencies in wording/terminology >>>> Impl: s/mismatchByAttrs and etc/isSameFile; >>>> Stick with the simple implementation (InputStream/Buffer) >>>> for now. Further improvement may be done if there's a need; >>>> The impl is smaller than the previous version, merged the >>>> code into Files, removed FilesMismatch.java; >>>> >>>> Test: more readable variables instead of the array of test files >>>> more comments on the testcases >>>> improved the private methods used for generating the test >>>> files >>>> >>>> Thanks, >>>> Joe >>> > From Roger.Riggs at oracle.com Wed Oct 17 20:08:14 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 17 Oct 2018 16:08:14 -0400 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC78EA5.1080208@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> Message-ID: Hi Joe, A few comments about the test. 45: the summary should mention it is testing the Files.mismatch method I think the @bug line should be empty, this is not a test for a bug. I don't think you need or use the testng group= functionality; if you don't have a need for it omit it. On the test files, I think I would have used testMismatch DataProvider to create the files.? It would avoid having to maintain parallel lists of matching parameters. The @beforeSetup might support the dataProvider directly, but might have to iterate over the array itself, creating the files if they do not exist. And keeping the mapping from name to path in a Map instead of statics. The code should use Assert.assertEquals(actual, expected, msg) so that if there is a difference it is printed.? (instead of assertTrue ( n==m)...) The file sizes all seem to be multiples of 1024 or the buffer size. There might be a? good case for using a more varied sizes. 340: testMismatchNotExists:? can the expected exception be more specific:? FileNotFoundException instead of IOException. 370: This condition for zero made me wonder if there was a test case for files that differ at 0. 397: fillArray could probably make good use of System.arraycopy(). Regards, Roger On 10/17/2018 03:33 PM, Joe Wang wrote: > > On 10/17/18, 7:16 AM, Roger Riggs wrote: >> Hi Joe, >> >> Looks good, straightforward and easy to understand. > > Glad to hear that,? while it's been back and forth a couple of times, > it seems "straightforward and easy" won :-) >> >> The spec text in the CSR need to be updated to match. (At least the >> paragraph about reflexive and atomic). > > CSR: update the text and attachment > https://bugs.openjdk.java.net/browse/JDK-8202302 > > Also added coverage to spec case 5 -? reflexive (no new test cases), > spec case 6 - symmetric with tests selected from case 3. > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ > > Thanks, > Joe > >> >> Thanks, Roger >> >> On 10/16/2018 02:10 PM, Joe Wang wrote: >>> Hi Daniel, >>> >>> @linkplain it is!? Thanks!? And yes, int totalRead was fixed in the >>> previous webrevs. >>> >>> Current version: >>> specdiff: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v04/java/nio/file/Files.html >>> >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v04/ >>> >>> Previous version: >>> specdiff: >>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v03/java/nio/file/Files.html >>> >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v03/ >>> >>> Best regards, >>> Joe >>> >>> On 10/16/18, 2:11 AM, Daniel Fuchs wrote: >>>> Hi Joe, >>>> >>>> There are a few places where {@linkplain } should be used instead >>>> of {@link }. For instance: >>>> >>>> 1545????? *
  • The two paths locate the {@link #isSameFile(Path, >>>> Path) same file}, >>>> >>>> This should be {@linkplain } - for the record {@link } will format the >>>> text as code, {@linkplain } will format it as regular text. Since the >>>> text of the link is "same file" then it should be formatted as regular >>>> text - not as code. >>>> >>>> The link on the next line should probably be {@linkplain } as well. >>>> >>>> Otherwise looks good to me (except for the declaration of >>>> int totalRead that should be long but Alan already mentioned it). >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> On 12/10/2018 20:16, Joe Wang wrote: >>>>> Here's an update based on all of the great reviews and comments >>>>> (thanks all!): >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >>>>> >>>>> Current version: >>>>> specdiff: >>>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >>>>> >>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ >>>>> >>>>> Previous version: >>>>> specdiff: >>>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html >>>>> >>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ >>>>> >>>>> It's been a while, so here's a summary of what's changed: >>>>> >>>>> Spec: Alan's patch to fix inconsistencies in wording/terminology >>>>> Impl: s/mismatchByAttrs and etc/isSameFile; >>>>> ????????? Stick with the simple implementation >>>>> (InputStream/Buffer) for now. Further improvement may be done if >>>>> there's a need; >>>>> ????????? The impl is smaller than the previous version, merged >>>>> the code into Files, removed FilesMismatch.java; >>>>> >>>>> Test: more readable variables instead of the array of test files >>>>> ????????? more comments on the testcases >>>>> ????????? improved the private methods used for generating the >>>>> test files >>>>> >>>>> Thanks, >>>>> Joe >>>> >> -- Thanks, Roger From aleksei.voitylov at bell-sw.com Wed Oct 17 20:50:30 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 17 Oct 2018 23:50:30 +0300 Subject: RFC: JEP JDK-8208089: Implement C++14 Language Features In-Reply-To: References: <7D0FB905-E515-4FD5-941D-5973BB04D0AA@oracle.com> <3690d846-5f4d-cf7d-5e43-51a1915fd36e@bell-sw.com> <99659828-1665-4B62-9E24-D6BD4EE96C98@oracle.com> <10d8f2ea-883e-ec21-4fea-06a52a52fdc6@bell-sw.com> <407CE450-6EED-4955-9B1F-EA564E134D11@oracle.com> Message-ID: <32419fac-84fe-c247-b91d-e8a5ead67cf2@bell-sw.com> On 16/10/2018 02:25, Kim Barrett wrote: >> On Oct 15, 2018, at 7:51 AM, Aleksei Voitylov wrote: >> >> Kim, >> >> If you were suggesting to just proceed with the change without giving a sufficient lead time for the ports that were willing to upgrade to do so, that sounds very alarming. > What is "sufficient lead time"? I'm not proposing an answer, just > suggesting that 3 months (approx time between JEP publication and JDK > 12 fork) might be sufficient, and a worthy goal. That's a decision > that ought to be made as part of the Targeting discussion for this > JEP. Right now, it's not even a Candidate, since there's still work > to be done. I'm fine with that, and you probably can assume to document this goal in the JEP if noone speaks up. > >> Meanwhile, our testing has finished and I'm now confident we will be able to switch ARM port over to 7.x in 12 time frame. There are several issues that we still need to diagnose, but this does not look like a blocker. > That's good news, though pretty much what I expected. > > I'm more worried about Solaris. Having a goal of JDK 12 may help move > things along. > From stuart.marks at oracle.com Wed Oct 17 21:01:27 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 17 Oct 2018 14:01:27 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> Message-ID: <5e925818-27c7-ffb2-f2ce-1beee59abd91@oracle.com> On 10/17/18 1:08 PM, Roger Riggs wrote: > I think the @bug line should be empty, this is not a test for a bug. > I don't think you need or use the testng group= functionality; if you don't have > a need for it omit it. I think it would be helpful to have the bug ID in the test's @bug line. If in the future this test fails or needs to be modified or something, this points to the bug under which the changeset was pushed. This bug ID can also be used to help find the email review thread. It also links to the CSR should any questions about the specification arise. s'marks From lance.andersen at oracle.com Wed Oct 17 21:18:36 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 17 Oct 2018 17:18:36 -0400 Subject: [PATCH] Fix typo in javadoc for java.lang.ref.Cleaner In-Reply-To: References: Message-ID: +1 > On Oct 17, 2018, at 4:50 PM, Andrew Luo wrote: > > Done as well, thanks for spotting that also. > > diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java > --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java > +++ b/src/java.base/share/classes/java/lang/ref/Cleaner.java > @@ -100,8 +100,8 @@ > * } > * } > * > - * private final State; > - * private final Cleaner.Cleanable cleanable > + * private final State state; > + * private final Cleaner.Cleanable cleanable; > * > * public CleaningExample() { > * this.state = new State(...); > > Thanks, > > -Andrew > > From: Lance Andersen > > Sent: Wednesday, October 17, 2018 11:33 AM > To: Andrew Luo > > Cc: core-libs-dev at openjdk.java.net > Subject: Re: [PATCH] Fix typo in javadoc for java.lang.ref.Cleaner > > Change seems to make sense > > looks like a semi-colon could be added after as well as part of the update: > > private final Cleaner.Cleanable cleanable > > > > On Oct 17, 2018, at 2:10 PM, Andrew Luo > wrote: > > Noticed a typo in the Javadoc for Cleaner... Patch attached below: > > diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java > --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java > +++ b/src/java.base/share/classes/java/lang/ref/Cleaner.java > @@ -100,7 +100,7 @@ > * } > * } > * > - * private final State; > + * private final State state; > * private final Cleaner.Cleanable cleanable > * > * public CleaningExample() { > > Thanks, > > Andrew > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From mandy.chung at oracle.com Wed Oct 17 21:41:56 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Oct 2018 14:41:56 -0700 Subject: Review Request: JDK-8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference In-Reply-To: <237430e1-5aea-6c0b-3317-14f12aec72c8@oracle.com> References: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> <237430e1-5aea-6c0b-3317-14f12aec72c8@oracle.com> Message-ID: David, thanks for the review. Mandy On 10/16/18 8:33 PM, David Holmes wrote: > Hi Mandy, > > I took a look through all of this and it seems okay - though it was a > little surprising how far the name change needed to spread. > > Thanks, > David > > On 17/10/2018 2:08 AM, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8207146/webrev.00/ >> >> Unsafe::getObject returns a reference to an object. Similarly >> Unsafe::putObject sets a reference in the given base+offset. >> This patch proposes to rename Unsafe xxxObject to xxxReference >> that will make the xxxReference API very clear that these >> are getters/setters for a reference (instance of object class) >> and ready for adding xxxValue in the futurefor values. >> Note that this renaming only applies to jdk.internal.misc.Unsafe >> but not sun.misc.Unsafe.? So no impact to existing libraries >> that depends on sun.misc.Unsafe in jdk.unsupported module. >> >> I ran jdk_core, core_tools, langtools and nashorn tier1-3, >> hotspot_runtime, hotspot_compiler test groups. >> >> thanks >> Mandy From stuart.marks at oracle.com Wed Oct 17 22:03:21 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 17 Oct 2018 15:03:21 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <5BC78EA5.1080208@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> Message-ID: <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> Hi Joe, > webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ I concur with Roger's comments on the test file generation. It would be good to find some way to reduce the redundancy. He had some suggestions that might work. You might also want to play around with variations to see how they look. 375 byte[] bytes = "ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789 \n".getBytes(); A small thing, but this uses the default charset, which is platform-specific. I think it would be good to use StandardCharsets.US_ASCII here. Once you have this in bytes, it looks like all the other parts of the test deal with bytes (not characters) so I don't think there are any other concerns about charsets and such. 345 /** 346 * Creates a file with alphanumeric content with one character altered 347 * at the specified position. 348 * 349 * @param dir the directory in which the file is to be created 350 * @param purpose the purpose of the file 351 * @param size the size of the file 352 * @param pos the position where the alternative char is to be added. If it 353 * is smaller than zero, no alternation shall be made. 354 * @param c the character 355 * @return path of the created file 356 * @throws IOException 357 */ 358 private static Path createANFile(Path dir, String purpose, int size, int pos, 359 byte c) throws IOException { 360 Path path = Files.createFile(Paths.get(dir.toString(), purpose + ".txt")); 361 if (size > 0) { 362 writeAlphanumericFile(path, size, pos, c); 363 } 364 return path; 365 } The problem with documenting things well is that the doc gets out of date. :-) (Well, actually somewhat serious.) This method creates test data files in terms of bytes (although the bytes happen to be derived from ASCII characters). The altered data is a byte at a particular byte offset, not a character. Several places in the doc need to be updated to reflect this, since they still talk about characters. Even though the altered data is a byte, for the convenience of the caller, the parameter should be a char or an int. All the places where this is called use a char literal casted to a byte: 125 test1024m1014a = createANFile(testDir, "test1024m1014a", size, size - 10, (byte)'@'); If the parameter were a char or a int, the caller could just do: 125 test1024m1014a = createANFile(testDir, "test1024m1014a", size, size - 10, '@'); The byte used to alter the test data could be the low order 7 bits (since we're using ASCII) of the parameter value. Either document it this way and simply mask off the high order bits of the parameter value, or assert that those high order bits are all zeroes. In writeAlphanumericFile(), 370 if (pos > 0) a[pos] = c; This should check should be for pos >= 0, since altering a byte at position 0 is a valid test case. You might want to add this as another test case. s'marks From peter.levart at gmail.com Wed Oct 17 22:07:05 2018 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 18 Oct 2018 00:07:05 +0200 Subject: JDK 12 RFR of JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods In-Reply-To: <644c9465-3ea9-cc1b-689a-cbeca90463dc@oracle.com> References: <644c9465-3ea9-cc1b-689a-cbeca90463dc@oracle.com> Message-ID: Hi Joe, On 10/17/2018 09:16 PM, joe darcy wrote: > PS In response to some off-list feedback, an updated webrev uses a > stream-ier implementation: > > ??? http://cr.openjdk.java.net/~darcy/6304578.1/ I suggest further niceing: - if you make typeVarBounds() static, you could use it in Stream.map() as a method reference. - in Class.java line 285, you could also use Type::getTypeName method reference - in Class.java line 269, wouldn't the output be nicer if the delimiter in joining collector was ", " instead of "," (with a space after comma)? The same for Executable. Regards, Peter > > Thanks, > > -Joe > > > On 10/11/2018 6:11 PM, joe darcy wrote: >> Hello, >> >> Prompted by recent work on the toString implementations of >> AnnotatedType objects >> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055937.html), >> I rediscovered a long-standing limitation of toGenericString on Type >> objects that can be addressed: >> >> ??? JDK-6304578: (reflect) toGenericString fails to print bounds of >> type variables on generic methods >> >> Please review the small CSR >> >> ??? https://bugs.openjdk.java.net/browse/JDK-8212094 >> >> and webrev: >> >> ??? http://cr.openjdk.java.net/~darcy/6304578.0/ >> >> Thanks, >> >> -Joe >> > From david.holmes at oracle.com Wed Oct 17 23:47:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 09:47:23 +1000 Subject: Is it possible to find PDB (windows debugging info) for published jvm.dll? In-Reply-To: References: Message-ID: <46cd580f-4a2c-93b0-86d2-45a6f75716a3@oracle.com> Hi Alexander, Not really a core-libs question, but in any case the simple answer for the Oracle JDK is No. We can not provide the PDB files to you. David On 18/10/2018 1:08 AM, Alexander Miloslavskiy wrote: > Hello, > > I'm trying to debug a native crash that regularly happens for one of our > customers. > > It crashes somewhere amidst java interpreter code, with corrupted value > in CPU's RIP register. So it's quite complicated. > > It would certainly help me a lot if I had access to jvm.pdb files for > published JRE's... I'm mostly after 10.0.1+10 and 8.0_144-b01 at the > moment. > > According to the published binaries, the PDB's are generated here on the > build server: > t:\workspace\build\windows-x64\support\modules_libs\java.base\server\jvm.pdb > > > I believe they are saved somewhere after building, at least internally? > > Is there some way to obtain those pdb's myself? > If not, can someone send me the PDB's, at least for 10.0.1+10? > > I understand that I can build OpenJDK myself to obtain the PDB's, but > unfortunately they will not match dumps provided by the client. From ecki at zusammenkunft.net Thu Oct 18 00:55:06 2018 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 18 Oct 2018 02:55:06 +0200 Subject: Is it possible to find PDB (windows debugging info) for publishedjvm.dll? In-Reply-To: References: Message-ID: <5bc7d9ea.1c69fb81.b7b0e.3eb2@mx.google.com> Sorry for offtopic ? figured might still be a good Addition to the question, If you can switch the JDK (and do not yet need Java 11) then you can use the binaries from the ojdkbuild Project (Fedora/RH upstream), they provide the PDB files in the *debuginfo* packages (havent tested them myself). Its a pitty, seems not to be a standard Service of openjdk Vendors (not even the paied ones). https://github.com/ojdkbuild/ojdkbuild/releases Gruss Bernd -- http://bernd.eckenfels.net Von: Alexander Miloslavskiy Gesendet: Mittwoch, 17. Oktober 2018 19:39 An: core-libs-dev Betreff: Is it possible to find PDB (windows debugging info) for publishedjvm.dll? Hello, I'm trying to debug a native crash that regularly happens for one of our customers. It crashes somewhere amidst java interpreter code, with corrupted value in CPU's RIP register. So it's quite complicated. It would certainly help me a lot if I had access to jvm.pdb files for published JRE's... I'm mostly after 10.0.1+10 and 8.0_144-b01 at the moment. According to the published binaries, the PDB's are generated here on the build server: t:\workspace\build\windows-x64\support\modules_libs\java.base\server\jvm.pdb I believe they are saved somewhere after building, at least internally? Is there some way to obtain those pdb's myself? If not, can someone send me the PDB's, at least for 10.0.1+10? I understand that I can build OpenJDK myself to obtain the PDB's, but unfortunately they will not match dumps provided by the client. From thomas.stuefe at gmail.com Thu Oct 18 07:15:25 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 18 Oct 2018 09:15:25 +0200 Subject: Is it possible to find PDB (windows debugging info) for publishedjvm.dll? In-Reply-To: <5bc7d9ea.1c69fb81.b7b0e.3eb2@mx.google.com> References: <5bc7d9ea.1c69fb81.b7b0e.3eb2@mx.google.com> Message-ID: Hm. In my experience, if you attempt to debug the VM at the level Alexander intended, you usually do not get very far without rebuilding, if only to get a fastdebug or slowdebug build. And if you have the knowledge to debug the VM, building it should be not a big hurdle. Just my 5c.. (Should you attempt to rebuild on Windows, there are a number of how-tos floating around. Here is mine: https://github.com/tstuefe/docs/blob/master/build-ojdk-on-windows.md) ..Thomas On Thu, Oct 18, 2018 at 6:56 AM Bernd Eckenfels wrote: > > Sorry for offtopic ? figured might still be a good Addition to the question, > > If you can switch the JDK (and do not yet need Java 11) then you can use the binaries from the ojdkbuild Project (Fedora/RH upstream), they provide the PDB files in the *debuginfo* packages (havent tested them myself). > > Its a pitty, seems not to be a standard Service of openjdk Vendors (not even the paied ones). > > https://github.com/ojdkbuild/ojdkbuild/releases > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > Von: Alexander Miloslavskiy > Gesendet: Mittwoch, 17. Oktober 2018 19:39 > An: core-libs-dev > Betreff: Is it possible to find PDB (windows debugging info) for publishedjvm.dll? > > Hello, > > I'm trying to debug a native crash that regularly happens for one of our > customers. > > It crashes somewhere amidst java interpreter code, with corrupted value > in CPU's RIP register. So it's quite complicated. > > It would certainly help me a lot if I had access to jvm.pdb files for > published JRE's... I'm mostly after 10.0.1+10 and 8.0_144-b01 at the moment. > > According to the published binaries, the PDB's are generated here on the > build server: > t:\workspace\build\windows-x64\support\modules_libs\java.base\server\jvm.pdb > > I believe they are saved somewhere after building, at least internally? > > Is there some way to obtain those pdb's myself? > If not, can someone send me the PDB's, at least for 10.0.1+10? > > I understand that I can build OpenJDK myself to obtain the PDB's, but > unfortunately they will not match dumps provided by the client. > From kishor.gollapalliwar at gmail.com Thu Oct 18 09:21:57 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Thu, 18 Oct 2018 14:51:57 +0530 Subject: Approval Request to update TreeSet#add method documentation In-Reply-To: References: Message-ID: Hi Team, Please provide your approval to update TreeSet#add method as it's documentation and behavior are not consistent. For more information, please refer my mail below and attachment. Thanks & Regards, *Kishor Golapelliwar,* The ability to convert ideas to things is the secret to outward success. ---------- Forwarded message --------- From: Kishor Gollapalliwar Date: Mon, Oct 15, 2018 at 11:40 AM Subject: Re: Inconsistencies in TreeSet Interface To: Cc: Hello Everyone, This is the first time I am writing mail to this group, hence please ignore my nuisance and guide me towards right direction. As suggested by Martin, I believe documentation need to be updated. I would happy to update the documentation, please provide your inputs. I have attache the .java file for more details. @Martin : I really appreciate your advice and help, thank you. Thank you, Kishor Gollapalliwar On Sat, Oct 13, 2018 at 11:40 PM Martin Buchholz wrote: > core-libs-dev is the right mailing list. > > The documentation could be improved, but it's nuanced - consider using a > TreeSet with a Comparator that accepts null. > > On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < > kishor.gollapalliwar at gmail.com> wrote: > >> Hello Everyone, >> >> Introduction : I?m an enthusiast java developer. I?m a newbie in this >> group, hence please ignore my nuisance and guide me towards right >> direction. >> >> ## Problems Statement >> >> Treeset#add method documentations : ?adds the specified element e to this >> set if the set contains no element e2 such that (e==null ? e2==null : >> e.equals(e2))? >> >> Inconsistencies: >> >> > If we try to add ?null? value, it will throws NullPointerException, >> hence >> > e and e2 can not be null. >> >> >> >> > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to >> > collection. >> >> >> Request you to help me understand if behavior of Treeset#add method is as >> expected, and differ with set interface documentation. We may have to >> consider to update method documentations, if behavior is expected. >> >> For more details I have attached the sample java application. >> >> I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK 8u181. >> >> Thanks & Regards, >> *Kishor Golapelliwar,* >> The ability to convert ideas to things is the secret to outward success. >> > > From lance.andersen at oracle.com Thu Oct 18 13:42:27 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 18 Oct 2018 09:42:27 -0400 Subject: [PATCH] Fix typo in javadoc for java.lang.ref.Cleaner In-Reply-To: References: Message-ID: <19885D4C-A5E5-4D79-AE76-9BBB83FF7DEB@oracle.com> Andrew, I can sponsor your change > On Oct 17, 2018, at 5:18 PM, Lance Andersen wrote: > > +1 >> On Oct 17, 2018, at 4:50 PM, Andrew Luo > wrote: >> >> Done as well, thanks for spotting that also. >> >> diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java >> --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java >> +++ b/src/java.base/share/classes/java/lang/ref/Cleaner.java >> @@ -100,8 +100,8 @@ >> * } >> * } >> * >> - * private final State; >> - * private final Cleaner.Cleanable cleanable >> + * private final State state; >> + * private final Cleaner.Cleanable cleanable; >> * >> * public CleaningExample() { >> * this.state = new State(...); >> >> Thanks, >> >> -Andrew >> >> From: Lance Andersen > >> Sent: Wednesday, October 17, 2018 11:33 AM >> To: Andrew Luo > >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: [PATCH] Fix typo in javadoc for java.lang.ref.Cleaner >> >> Change seems to make sense >> >> looks like a semi-colon could be added after as well as part of the update: >> >> private final Cleaner.Cleanable cleanable >> >> >> >> On Oct 17, 2018, at 2:10 PM, Andrew Luo > wrote: >> >> Noticed a typo in the Javadoc for Cleaner... Patch attached below: >> >> diff --git a/src/java.base/share/classes/java/lang/ref/Cleaner.java b/src/java.base/share/classes/java/lang/ref/Cleaner.java >> --- a/src/java.base/share/classes/java/lang/ref/Cleaner.java >> +++ b/src/java.base/share/classes/java/lang/ref/Cleaner.java >> @@ -100,7 +100,7 @@ >> * } >> * } >> * >> - * private final State; >> + * private final State state; >> * private final Cleaner.Cleanable cleanable >> * >> * public CleaningExample() { >> >> Thanks, >> >> Andrew >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> >> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From matthias.baesken at sap.com Thu Oct 18 14:30:20 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 18 Oct 2018 14:30:20 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: Hello, please review my updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.1/ - check changed to build number of recently released Windows Server 2019 GA version (17763) - adjusted comments a bit ( see also https://en.wikipedia.org/wiki/Windows_Server_2019 for the list of build numbers ) Thanks, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Freitag, 12. Oktober 2018 08:57 > To: 'Bob Vandette' > Cc: 'hotspot-dev at openjdk.java.net' ; > 'core-libs-dev at openjdk.java.net' ; > Langer, Christoph > Subject: RE: RFR : 8211106: [windows] Update OS detection code to > recognize Windows Server 2019 > > I got the info that the GA of Windows Server 2019 has build number 17763 > . > Should I update the webrev to check this build number (would mean we do > not detect the preview as Windows Server 2019) , or keep it the way it is ? > > Current webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ > > > Best regards, Matthias > > > > > > > Hello Bob, > > > > > Hi Bob, > > > no problem , we can wait a few days until the final version of Win > > server > > > 2019 is out, and check the buildNumber again : > > > > > > > seems Windows server 2019 is GA now : > > > > > > https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows- > > server-2019-now-generally-available/ > > > > > > We don?t usually add logic to the JDK related to unreleased operating > > system > > > > previews. > > > > > > so I think we can process with the review . > > Still have to find out the buildNumber of the GA version, probably it has > been > > incremented again . > > > > > > > > > > > > Bug/webrev : > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8211106 > > > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ > > > > > > > > > > > > > > > Thanks, Matthias From bob.vandette at oracle.com Thu Oct 18 14:35:49 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 18 Oct 2018 10:35:49 -0400 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: It sounds like this is still not the last one but I?m ok with your check since the real GA will be higher and we?re real close. "On October 6, 2018, distribution of Windows version 1809 (build 17763[18] ) was paused while Microsoft is investigating an issue with user data being deleted during an in-place upgrade.[19] It affected systems where a user profile folder (e.g. Documents, Music or Pictures) had been moved to another location, but data was left in the original location.[20] As Windows Server 2019 is based on the Windows version 1809 codebase, it too was removed from distribution.[21] ?? Bob. > On Oct 18, 2018, at 10:30 AM, Baesken, Matthias wrote: > > Hello, please review my updated webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.1/ > > - check changed to build number of recently released Windows Server 2019 GA version (17763) > - adjusted comments a bit > > > ( see also > > https://en.wikipedia.org/wiki/Windows_Server_2019 > > for the list of build numbers ) > > Thanks, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Freitag, 12. Oktober 2018 08:57 >> To: 'Bob Vandette' >> Cc: 'hotspot-dev at openjdk.java.net' ; >> 'core-libs-dev at openjdk.java.net' ; >> Langer, Christoph >> Subject: RE: RFR : 8211106: [windows] Update OS detection code to >> recognize Windows Server 2019 >> >> I got the info that the GA of Windows Server 2019 has build number 17763 >> . >> Should I update the webrev to check this build number (would mean we do >> not detect the preview as Windows Server 2019) , or keep it the way it is ? >> >> Current webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ >> >> >> Best regards, Matthias >> >> >> >>> >>> Hello Bob, >>> >>>> Hi Bob, >>>> no problem , we can wait a few days until the final version of Win >>> server >>>> 2019 is out, and check the buildNumber again : >>>> >>> >>> seems Windows server 2019 is GA now : >>> >>> >>> https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows- >>> server-2019-now-generally-available/ >>> >>>>> We don?t usually add logic to the JDK related to unreleased operating >>> system >>>>> previews. >>> >>> >>> so I think we can process with the review . >>> Still have to find out the buildNumber of the GA version, probably it has >> been >>> incremented again . >>> >>>>>> >>>>>> Bug/webrev : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8211106 >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ >>>>>> >>>>>> >>>>>> Thanks, Matthias > From Roger.Riggs at oracle.com Thu Oct 18 14:37:26 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 18 Oct 2018 10:37:26 -0400 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: Hi Matthias, java_props_md.c: 564. Please move the buildNumber check inside the "case 0:" above. Then it won't need the extra check for minorVersion == 0. Thanks, Roger On 10/18/2018 10:30 AM, Baesken, Matthias wrote: > Hello, please review my updated webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.1/ > > - check changed to build number of recently released Windows Server 2019 GA version (17763) > - adjusted comments a bit > > > ( see also > > https://en.wikipedia.org/wiki/Windows_Server_2019 > > for the list of build numbers ) > > Thanks, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Freitag, 12. Oktober 2018 08:57 >> To: 'Bob Vandette' >> Cc: 'hotspot-dev at openjdk.java.net' ; >> 'core-libs-dev at openjdk.java.net' ; >> Langer, Christoph >> Subject: RE: RFR : 8211106: [windows] Update OS detection code to >> recognize Windows Server 2019 >> >> I got the info that the GA of Windows Server 2019 has build number 17763 >> . >> Should I update the webrev to check this build number (would mean we do >> not detect the preview as Windows Server 2019) , or keep it the way it is ? >> >> Current webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ >> >> >> Best regards, Matthias >> >> >> >>> Hello Bob, >>> >>>> Hi Bob, >>>> no problem , we can wait a few days until the final version of Win >>> server >>>> 2019 is out, and check the buildNumber again : >>>> >>> seems Windows server 2019 is GA now : >>> >>> >>> https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows- >>> server-2019-now-generally-available/ >>> >>>>> We don?t usually add logic to the JDK related to unreleased operating >>> system >>>>> previews. >>> >>> so I think we can process with the review . >>> Still have to find out the buildNumber of the GA version, probably it has >> been >>> incremented again . >>> >>>>>> Bug/webrev : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8211106 >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ >>>>>> >>>>>> >>>>>> Thanks, Matthias -- Thanks, Roger From nlisker at gmail.com Thu Oct 18 18:44:32 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 18 Oct 2018 21:44:32 +0300 Subject: JDK-8198620: New Convenient-Methods for java.util.stream.Stream Message-ID: Hi, A while back I commented on the suggestion to deal with an annoyance of casting in a stream [1]. I brought an argument that was used in project Amber for a similar case. Like Tagir Valeev, I also see the filter-then-map pattern in various projects I work on. I would like to know if this issue can be re-evaluated. Thanks, Nir [1] https://bugs.openjdk.java.net/browse/JDK-8198620 From Roger.Riggs at oracle.com Thu Oct 18 18:51:22 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 18 Oct 2018 14:51:22 -0400 Subject: [12] RFR 8200151: Add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ In-Reply-To: References: <9FD6703A-49E8-41D8-B527-8D0D09726EB0@oracle.com> <8961A4DD-5119-46BD-B2B4-A3162302CAF7@oracle.com> <7fc8c142-1047-84b3-a009-d06e39dc0e92@oracle.com> <3412A5FF-06B3-416B-B614-CBE10E3F3328@oracle.com> <3afd41a3-ef1c-7092-6d37-66bfc23081a7@oracle.com> Message-ID: Hi Chris, Sorry, for the delay. I'd lost track of this review. Looks fine. Roger On 08/20/2018 05:28 AM, Chris Yin wrote: > Hi, Roger > > Sorry for the late response since I was on vacation and thank you for the comments, inline and update webrev as below > > http://cr.openjdk.java.net/~xyin/8200151/webrev.03/ > >> On 11 Aug 2018, at 1:47 AM, Roger Riggs wrote: >> >> Hi Chris, >> >> There seems to be a lot of repetition in tests that could be combined. >> For example, the RecursiveDefault, RecursiveTrue, and RecursiveFalse tests should be a >> single test that is invoked 3 times, (multiple @run lines) with an argument to say which case to test. >> There would be fewer files and less code to maintain. >> >> The same goes for AuthDefault, AuthTrue and AuthFalse. > Thanks, fixed as you suggested, minor change in DNSTestUtils to support it > >> Why is PortUnreachable added to the ProblemList and also included in the Change set. >> It would cleaner to treat it separately if it can't be fixed as part of adding these new tests. > Thank you for checking this, there is a platform specified known issue on macOS which caused PortUnreachable failure, but it?s unrelated to JNDI feature, and test working well on other platforms, so I add it to problemlist to exclude the test for macOS only, feel free to let me know if it?s not suitable, I could just remove the test here for now > >> Consider using java.time.Instant and Duration for the Timeout test; >> it will print nicer and has some handy methods. > Sure, changed as you suggested, thanks > > Regards, > Chris > >> Regards, Roger >> >> >> On 8/10/18 5:15 AM, Chris Yin wrote: >>> Minor revision to address testbase javadoc, initContext() expansion, @Override line and imports place, new webrev as below, thanks >>> >>> http://cr.openjdk.java.net/~xyin/8200151/webrev.02/ >>> >>> Regards, >>> Chris >>> >>>> On 30 Jul 2018, at 5:08 PM, Chris Yin wrote: >>>> >>>> Thank you, Vyom >>>> >>>> Regards, >>>> Chris >>>> >>>>> On 30 Jul 2018, at 5:06 PM, vyom tewari wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> Latest code looks good to me. >>>>> >>>>> Thanks, >>>>> >>>>> Vyom >>>>> >>>>> On Friday 27 July 2018 01:12 PM, Chris Yin wrote: >>>>>> Hi, Vyom >>>>>> >>>>>> Thank a lot for your review and comments, inline and update new webrev as below, thanks >>>>>> >>>>>> http://cr.openjdk.java.net/~xyin/8200151/webrev.01/ >>>>>> >>>>>> >>>>>>> On 26 Jul 2018, at 5:27 PM, vyom tewari > wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> Thanks for writing the tests overall code looks good to me, below are few minor comments. >>>>>>> >>>>>>> 1`-> Fix tag order, my Netbeans always complains :) . >>>>>> Fixed, thanks >>>>>> >>>>>>> 2-> you make AuthRecursiveBase class as public but i can not see it is being used outside, i will suggest you to give the default access if possible. >>>>>> Sure, changed it to default access now >>>>>> >>>>>>> 3-> AuthTrue.java, change the message as follows >>>>>>> >>>>>>> "Got exception as expected : " -> "Got expected exception: ?; >>>>>> Fixed >>>>>> >>>>>>> 4-> PortUnreachable.java , any specific reason for 1000ms or you just choose random value ? Please don't hard-code this specific value create a constant and use it . If possible put some comment why we choose 1 second, this will help in debugging if this test fails intermittently in future. >>>>>> Sure, I created a constant ?THRESHOLD' for it, 1000ms will be used as a threshold value for this test, normally the request should fail very quick (in a few ms), but consider to different platform and test machine performance, we used an acceptable threshold here, some comments added to it in the code too, thanks >>>>>> >>>>>>> 5-> Timeout.java, do you really need to set the env using "DNSTestUtils.initEnv" ? >>>>>>> >>>>>>> I see, this test is not using the DNSServer and other environments variables which were set by "DNSTestUtils.initEnv()" or i am missing something. >>>>>> Actually, it?s indeed not necessary, just set very few default value such as ?Context.INITIAL_CONTEXT_FACTORY? in the test code should be fine, but I may still want to keep the test consistency, then we could have better maintainability for those tests. Sorry, I forgot to refactor this test with testbase (actually, its not necessary too, but guess the consistent style and shared base/methods will make the test easy to read and maintain, refactored this test and PortUnreachable.java now) >>>>>> >>>>>> Regards, >>>>>> Chris >>>>>> >>>>>>> Thanks, >>>>>>> Vyom >>>>>>> >>>>>>> On Wednesday 25 July 2018 02:41 PM, Chris Yin wrote: >>>>>>>> Please review the changes to add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ in OpenJDK, due to known issue 7164518, PortUnreachable.java will be problem list for 'macosx-all', thanks >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8200151 > >>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ > >>>>>>>> >>>>>>>> Regards, >>>>>>>> Chris -- Thanks, Roger From Roger.Riggs at oracle.com Thu Oct 18 18:54:43 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 18 Oct 2018 14:54:43 -0400 Subject: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/ In-Reply-To: References: Message-ID: +1, On 09/20/2018 04:55 AM, vyom tewari wrote: > Hi Chris, > > tests? looks good to me. > > Thanks, > > > > On Tuesday 04 September 2018 12:00 PM, Chris Yin wrote: >> Please review the changes to add 10 JNDI tests to >> com/sun/jndi/dns/FedTests/ in OpenJDK, thanks >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210339 >> webrev: http://cr.openjdk.java.net/~xyin/8210339/webrev.00/ >> >> Regards, >> Chris > From Roger.Riggs at oracle.com Thu Oct 18 18:56:47 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 18 Oct 2018 14:56:47 -0400 Subject: [12] RFR 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/ In-Reply-To: <491bf04e-d1ca-f2ef-567a-c02eab75e426@oracle.com> References: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com> <8F9269B0-A4C8-4C1B-80CE-9CE3EEC72547@oracle.com> <491bf04e-d1ca-f2ef-567a-c02eab75e426@oracle.com> Message-ID: <3e1439d0-8d22-241e-eaef-baf3245a6b73@oracle.com> Hi Chris, Looks ok. Roger On 08/20/2018 03:24 AM, vyom tewari wrote: > Hi Chris, > > Latest webrev(.02) looks good to me. One minor comment i will suggest > you to? expand "setContext" as you did for other JNDI tests. > > Thanks, > > Vyom > > > On Friday 10 August 2018 02:34 PM, Chris Yin wrote: >> Sorry... another minor revision to handle @Override line and imports >> place, new webrev as below, thanks >> >> http://cr.openjdk.java.net/~xyin/8208542/webrev.02/ >> >> Regards, >> Chris >> >>> On 8 Aug 2018, at 2:51 PM, Chris Yin wrote: >>> >>> Minor revision to address javadoc, initContext() expansion, vararg >>> etc. webrev as below, thanks >>> >>> http://cr.openjdk.java.net/~xyin/8208542/webrev.01/ >>> >>> Regards, >>> Chris >>> >>>> On 31 Jul 2018, at 2:39 PM, Chris Yin wrote: >>>> >>>> Please review the changes to add 4 JNDI tests to >>>> com/sun/jndi/dns/ListTests/ in OpenJDK, thanks >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208542 >>>> webrev: http://cr.openjdk.java.net/~xyin/8208542/webrev.00/ >>>> >>>> Regards, >>>> Chris > -- Thanks, Roger From brian.goetz at oracle.com Thu Oct 18 20:10:17 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 18 Oct 2018 16:10:17 -0400 Subject: JDK-8198620: New Convenient-Methods for java.util.stream.Stream In-Reply-To: References: Message-ID: I still don't think this one clears the bar. On 10/18/2018 2:44 PM, Nir Lisker wrote: > Hi, > > A while back I commented on the suggestion to deal with an annoyance of > casting in a stream [1]. I brought an argument that was used in project > Amber for a similar case. > Like Tagir Valeev, I also see the filter-then-map pattern in various > projects I work on. > > I would like to know if this issue can be re-evaluated. > > Thanks, > Nir > > [1] https://bugs.openjdk.java.net/browse/JDK-8198620 From vicente.romero at oracle.com Thu Oct 18 21:09:37 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 18 Oct 2018 17:09:37 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: Hi all, Please review also the CSR at [1]. Thanks, Vicente [1] https://bugs.openjdk.java.net/browse/JDK-8202031 On 10/15/18 2:12 PM, Vicente Romero wrote: > Hi all, > > sorry for the repeated number of mails on this issue. I have added a > direct link to the patch the right link to the webrev is [1] there is > a previous version at [2] if you want to see the differences with the > last version. Basically we have dropped the `implements Constable` for > the symbolic descriptor classes and removed all of the code that was > useful for constant folding but not strictly necessary for the API. > For more information on the JEP see [3] > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 > [2] http://cr.openjdk.java.net/~vromero/8210031/webrev.00 > [3] http://openjdk.java.net/jeps/334 > > On 10/15/2018 01:51 PM, Vicente Romero wrote: >> adding core-libs in the loop >> >> On 10/10/2018 12:30 PM, Vicente Romero wrote: >>> Hi all, >>> >>> I have updated the webrev [1], this version removes the `implements >>> Constable` from the symbolic descriptor classes. Feedback is mostly >>> appreciated, >>> >>> Thanks, >>> Vicente >>> >>> [1] >>> http://cr.openjdk.java.net/~vromero/8210031/webrev.01/jdk12.dev.patch >>> >>> On 10/06/2018 05:00 PM, Brian Goetz wrote: >>>> What we decided to do here is to hold back on ?implements >>>> Constable? for the symbolic descriptor classes in the initial push >>>> of JEP-334, and then when we have the symbolic expression mode for >>>> BSMs, re-implement those in XxxDesc using that.? Implementing >>>> Constable isn?t needed until we get to the full constant folding >>>> anyway. That linearizes the dependencies ? first JEP-334, then >>>> symbolic mode BSM, then update JEP-334 classes to implement >>>> Constable using symbolic mode BSM. >>>> >>>>> On Sep 13, 2018, at 9:07 PM, John Rose >>>>> wrote: >>>>> >>>>> I am running a review of VM-level work on bootstrap methods >>>>> which can optionally help simplify some of these APIs: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-September/030084.html >>>>> >>>>> >>>>> Specifically, this work can be use to implement a "symbolic >>>>> expression mode" for BSMs which causes the JVM to unpack >>>>> constant pool nodes directly as ConstantDesc items to present >>>>> to BSMs.? This might simplify the condy forms of ConstantDesc >>>>> instances, if javac stores native constants to reflect, rather than >>>>> lists of strings to reassemble. >>>>> >>>>> ? John >>>>> >>>>> On Sep 11, 2018, at 12:50 PM, Vicente Romero >>>>> wrote: >>>>>> Please review the first iteration of the implementation for >>>>>> JEP-334 [1] JVM Constants API. The implementation can be found at >>>>>> [2]. JEP-334 introduces an API to model nominal descriptions of >>>>>> key class-file and run-time artifacts, in particular constants >>>>>> that are loadable from the constant pool and has already been the >>>>>> subject of several discussions. The implementation of this JEP >>>>>> has been publicly accessible throw the amber repo at [3] in the >>>>>> jep-334 branch. Thanks to all members of the Amber project and >>>>>> specially to Brian for all the hard work on the design and the >>>>>> implementation of this API. Thanks for all the feedback we have >>>>>> received so far, most of it has been integrated in the current >>>>>> implementation. >>>>>> >>>>>> Thanks, >>>>>> Vicente >>>>>> >>>>>> [1] http://openjdk.java.net/jeps/334 >>>>>> [2] >>>>>> http://cr.openjdk.java.net/~vromero/8210031/webrev.00/jdk.dev.patch >>>>>> [3] http://hg.openjdk.java.net/amber/amber >>> >> > From david.lloyd at redhat.com Thu Oct 18 21:42:50 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 18 Oct 2018 16:42:50 -0500 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process launching on Linux, but it's the closest I could find out of what are really a surprisingly large number of issues that refer to posix_spawn in one way or another relating to ProcessImpl. There's a different issue to move from vfork to posix_spawn on Solaris, but I wasn't sure if that one was quite right to hang this off of. Maybe it should be yet another issue of its own. Anyway: this is a follow-up to the email thread entitled "Runtime.exec : vfork() concerns and a fix proposal", where it was casually mentioned that maybe posix_spawn could become an option on Linux, whereafter it could be thoroughly tested by brave individuals and eventually maybe become the default on that platform, obsoleting the vfork support for good. The following patch does just that. I've tested it launching a multi-process WildFly instance a bunch of times, in conjunction with the conveniently existent "jdk.lang.Process.launchMechanism" property, and nothing exploded so here it is. The usual deal with git patches: apply directly through "patch -p1". commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 Author: David M. Lloyd Date: Thu Oct 18 15:56:37 2018 -0500 [JDK-6850720] Enable POSIX_SPAWN as an option for child process creation on Linux diff --git a/make/launcher/Launcher-java.base.gmk b/make/launcher/Launcher-java.base.gmk index 0ce0287d2be..c28fe42d102 100644 --- a/make/launcher/Launcher-java.base.gmk +++ b/make/launcher/Launcher-java.base.gmk @@ -84,7 +84,7 @@ endif ################################################################################ -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ NAME := jspawnhelper, \ SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java b/src/java.base/unix/classes/java/lang/ProcessImpl.java index 368a4f7380b..959e50dfecd 100644 --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { private static enum Platform { - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c b/src/java.base/unix/native/libjava/ProcessImpl_md.c index 533584fdb7a..6869a64f2cc 100644 --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c @@ -44,7 +44,7 @@ #include #include -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) || defined(__linux__) #include #endif @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { return resultPid; } -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) || defined(__linux__) static pid_t spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) { pid_t resultPid; @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, ChildStuff *c, const char *helperpath) #endif case MODE_FORK: return forkChild(c); -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) || defined(__linux__) case MODE_POSIX_SPAWN: return spawnChild(env, process, c, helperpath); #endif From xu.y.yin at oracle.com Fri Oct 19 01:21:29 2018 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 19 Oct 2018 09:21:29 +0800 Subject: [12] RFR 8200151: Add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ In-Reply-To: References: <9FD6703A-49E8-41D8-B527-8D0D09726EB0@oracle.com> <8961A4DD-5119-46BD-B2B4-A3162302CAF7@oracle.com> <7fc8c142-1047-84b3-a009-d06e39dc0e92@oracle.com> <3412A5FF-06B3-416B-B614-CBE10E3F3328@oracle.com> <3afd41a3-ef1c-7092-6d37-66bfc23081a7@oracle.com> Message-ID: <61240644-DB9F-4281-AACC-BD4C20528004@oracle.com> Thank you, Roger Chris > On 19 Oct 2018, at 2:51 AM, Roger Riggs wrote: > > Hi Chris, > > Sorry, for the delay. I'd lost track of this review. > > Looks fine. > > Roger > > > On 08/20/2018 05:28 AM, Chris Yin wrote: >> Hi, Roger >> >> Sorry for the late response since I was on vacation and thank you for the comments, inline and update webrev as below >> >> http://cr.openjdk.java.net/~xyin/8200151/webrev.03/ >> >>> On 11 Aug 2018, at 1:47 AM, Roger Riggs wrote: >>> >>> Hi Chris, >>> >>> There seems to be a lot of repetition in tests that could be combined. >>> For example, the RecursiveDefault, RecursiveTrue, and RecursiveFalse tests should be a >>> single test that is invoked 3 times, (multiple @run lines) with an argument to say which case to test. >>> There would be fewer files and less code to maintain. >>> >>> The same goes for AuthDefault, AuthTrue and AuthFalse. >> Thanks, fixed as you suggested, minor change in DNSTestUtils to support it >> >>> Why is PortUnreachable added to the ProblemList and also included in the Change set. >>> It would cleaner to treat it separately if it can't be fixed as part of adding these new tests. >> Thank you for checking this, there is a platform specified known issue on macOS which caused PortUnreachable failure, but it?s unrelated to JNDI feature, and test working well on other platforms, so I add it to problemlist to exclude the test for macOS only, feel free to let me know if it?s not suitable, I could just remove the test here for now >> >>> Consider using java.time.Instant and Duration for the Timeout test; >>> it will print nicer and has some handy methods. >> Sure, changed as you suggested, thanks >> >> Regards, >> Chris >> >>> Regards, Roger >>> >>> >>> On 8/10/18 5:15 AM, Chris Yin wrote: >>>> Minor revision to address testbase javadoc, initContext() expansion, @Override line and imports place, new webrev as below, thanks >>>> >>>> http://cr.openjdk.java.net/~xyin/8200151/webrev.02/ >>>> >>>> Regards, >>>> Chris >>>> >>>>> On 30 Jul 2018, at 5:08 PM, Chris Yin wrote: >>>>> >>>>> Thank you, Vyom >>>>> >>>>> Regards, >>>>> Chris >>>>> >>>>>> On 30 Jul 2018, at 5:06 PM, vyom tewari wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> Latest code looks good to me. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Vyom >>>>>> >>>>>> On Friday 27 July 2018 01:12 PM, Chris Yin wrote: >>>>>>> Hi, Vyom >>>>>>> >>>>>>> Thank a lot for your review and comments, inline and update new webrev as below, thanks >>>>>>> >>>>>>> http://cr.openjdk.java.net/~xyin/8200151/webrev.01/ >>>>>>> >>>>>>> >>>>>>>> On 26 Jul 2018, at 5:27 PM, vyom tewari > wrote: >>>>>>>> >>>>>>>> Hi Chris, >>>>>>>> >>>>>>>> Thanks for writing the tests overall code looks good to me, below are few minor comments. >>>>>>>> >>>>>>>> 1`-> Fix tag order, my Netbeans always complains :) . >>>>>>> Fixed, thanks >>>>>>> >>>>>>>> 2-> you make AuthRecursiveBase class as public but i can not see it is being used outside, i will suggest you to give the default access if possible. >>>>>>> Sure, changed it to default access now >>>>>>> >>>>>>>> 3-> AuthTrue.java, change the message as follows >>>>>>>> >>>>>>>> "Got exception as expected : " -> "Got expected exception: ?; >>>>>>> Fixed >>>>>>> >>>>>>>> 4-> PortUnreachable.java , any specific reason for 1000ms or you just choose random value ? Please don't hard-code this specific value create a constant and use it . If possible put some comment why we choose 1 second, this will help in debugging if this test fails intermittently in future. >>>>>>> Sure, I created a constant ?THRESHOLD' for it, 1000ms will be used as a threshold value for this test, normally the request should fail very quick (in a few ms), but consider to different platform and test machine performance, we used an acceptable threshold here, some comments added to it in the code too, thanks >>>>>>> >>>>>>>> 5-> Timeout.java, do you really need to set the env using "DNSTestUtils.initEnv" ? >>>>>>>> >>>>>>>> I see, this test is not using the DNSServer and other environments variables which were set by "DNSTestUtils.initEnv()" or i am missing something. >>>>>>> Actually, it?s indeed not necessary, just set very few default value such as ?Context.INITIAL_CONTEXT_FACTORY? in the test code should be fine, but I may still want to keep the test consistency, then we could have better maintainability for those tests. Sorry, I forgot to refactor this test with testbase (actually, its not necessary too, but guess the consistent style and shared base/methods will make the test easy to read and maintain, refactored this test and PortUnreachable.java now) >>>>>>> >>>>>>> Regards, >>>>>>> Chris >>>>>>> >>>>>>>> Thanks, >>>>>>>> Vyom >>>>>>>> >>>>>>>> On Wednesday 25 July 2018 02:41 PM, Chris Yin wrote: >>>>>>>>> Please review the changes to add 8 JNDI tests to com/sun/jndi/dns/ConfigTests/ in OpenJDK, due to known issue 7164518, PortUnreachable.java will be problem list for 'macosx-all', thanks >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8200151 > >>>>>>>>> webrev: http://cr.openjdk.java.net/~xyin/8200151/webrev.00/ > >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Chris > > -- > Thanks, Roger From xu.y.yin at oracle.com Fri Oct 19 01:22:22 2018 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 19 Oct 2018 09:22:22 +0800 Subject: [12] RFR 8210339: Add 10 JNDI tests to com/sun/jndi/dns/FedTests/ In-Reply-To: References: Message-ID: <2AEFC046-8CCE-4C1C-8139-B685BD577AD1@oracle.com> Thank you, Roger Chris > On 19 Oct 2018, at 2:54 AM, Roger Riggs wrote: > > +1, > > On 09/20/2018 04:55 AM, vyom tewari wrote: >> Hi Chris, >> >> tests looks good to me. >> >> Thanks, >> >> >> >> On Tuesday 04 September 2018 12:00 PM, Chris Yin wrote: >>> Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/FedTests/ in OpenJDK, thanks >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210339 >>> webrev: http://cr.openjdk.java.net/~xyin/8210339/webrev.00/ >>> >>> Regards, >>> Chris >> > From xu.y.yin at oracle.com Fri Oct 19 01:22:44 2018 From: xu.y.yin at oracle.com (Chris Yin) Date: Fri, 19 Oct 2018 09:22:44 +0800 Subject: [12] RFR 8208542: Add 4 JNDI tests to com/sun/jndi/dns/ListTests/ In-Reply-To: <3e1439d0-8d22-241e-eaef-baf3245a6b73@oracle.com> References: <86430F5C-B7FD-4C6C-87C2-477FD8EC8704@oracle.com> <8F9269B0-A4C8-4C1B-80CE-9CE3EEC72547@oracle.com> <491bf04e-d1ca-f2ef-567a-c02eab75e426@oracle.com> <3e1439d0-8d22-241e-eaef-baf3245a6b73@oracle.com> Message-ID: Thank you, Roger Chris > On 19 Oct 2018, at 2:56 AM, Roger Riggs wrote: > > Hi Chris, > > Looks ok. > > Roger > > > On 08/20/2018 03:24 AM, vyom tewari wrote: >> Hi Chris, >> >> Latest webrev(.02) looks good to me. One minor comment i will suggest you to expand "setContext" as you did for other JNDI tests. >> >> Thanks, >> >> Vyom >> >> >> On Friday 10 August 2018 02:34 PM, Chris Yin wrote: >>> Sorry... another minor revision to handle @Override line and imports place, new webrev as below, thanks >>> >>> http://cr.openjdk.java.net/~xyin/8208542/webrev.02/ >>> >>> Regards, >>> Chris >>> >>>> On 8 Aug 2018, at 2:51 PM, Chris Yin wrote: >>>> >>>> Minor revision to address javadoc, initContext() expansion, vararg etc. webrev as below, thanks >>>> >>>> http://cr.openjdk.java.net/~xyin/8208542/webrev.01/ >>>> >>>> Regards, >>>> Chris >>>> >>>>> On 31 Jul 2018, at 2:39 PM, Chris Yin wrote: >>>>> >>>>> Please review the changes to add 4 JNDI tests to com/sun/jndi/dns/ListTests/ in OpenJDK, thanks >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8208542 >>>>> webrev: http://cr.openjdk.java.net/~xyin/8208542/webrev.00/ >>>>> >>>>> Regards, >>>>> Chris >> > > -- > Thanks, Roger From mandy.chung at oracle.com Fri Oct 19 01:55:41 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Oct 2018 18:55:41 -0700 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: On 10/15/18 11:12 AM, Vicente Romero wrote: > > [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 I reviewed java.lang.invoke change in details.? I have skimmed through the new classes. I will look at the new tests next. @since 12 is missing in the new APIs VarHandle.java 1887 public final String toString() { 1888 // @@@ defer to concrete type for additional description 1889 // see https://bugs.openjdk.java.net/browse/JDK-8199149 You may want to take out this comment or L1889 as we can refer back to JDK-8199149. VarHandles.java ?169???????? // @@@ This is a little fragile assuming the base is the class Maybe FieldStaticReadOnly and FieldStaticReadWrite constructor and getStaticFieldFromBaseAndOffset method should take Class refc rather than Object base. FieldStaticReadXXX will do the cast when calling getStaticFieldFromBaseAndOffset. java.base module-info.java ?? It'd be good to keep the exported APIs in alphabetical order. java/lang/invoke/TypeDescriptor.java ?? copyright header is missing Mandy From thomas.stuefe at gmail.com Fri Oct 19 06:55:50 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 19 Oct 2018 08:55:50 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Hi David, (for convenience, here the old thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html) I would rather not expose a third way to spawn to the end user. As a test switch for developers, this seems fine. AFAIK (and someone please correct me if I am wrong) posix_spawn is not the magical third way beside fork and vfork, it is just a wrapper around fork/vfork and exec. Especially posix_spawn(), if using fork(), will still have the same pitfalls raw fork() has - quasi-random ENOMEM if we hit the overcommit heuristic, and inferior performance compared to vfork. So you have nothing gained, you have just relegated the fork/vfork decision down to a different layer, one which you have little control over. And since that fork/vfork decision is kind of important, you need that contol. Note that glibc has a flag to force always vfork behavior: POSIX_SPAWN_USEVFORK. The question is, how tight do we bind us to GNU-only features, since we may run on linux with a different libc, e.g. on Alpine we use muslc. My proposal, vfork() + the exec-twice-trick, is IMHO the best way to go. That exec-twice trick takes the sting away from vfork. After Martin made supportive noises in the other mail thread, I have planned in some time later this year to produce a patch for this. -- However: I just realized that my proposal (vfork() + exec-twice-trick) is very close, implementation wise, to the (posix_spawn() + POSIX_SPAWN_USEVFORK + jspawnhelper). The jspawnhelper already implements the exec-twice trick, if only for different reasons than to get away from vfork dangers. Advantage of this implementation would be that very little code would have to change. Disadvantage, in my eyes, is that we bind us to glibc, and an aesthetic side: calling an OS API but needing it to work in one specific way feels like programming with mechanical gloves... Thanks & Best Regards, Thomas (Copying Martin, I'm curious what he thinks) -- On Thu, Oct 18, 2018 at 11:43 PM David Lloyd wrote: > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > launching on Linux, but it's the closest I could find out of what are > really a surprisingly large number of issues that refer to posix_spawn > in one way or another relating to ProcessImpl. There's a different > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > if that one was quite right to hang this off of. Maybe it should be > yet another issue of its own. > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > : vfork() concerns and a fix proposal", where it was casually > mentioned that maybe posix_spawn could become an option on Linux, > whereafter it could be thoroughly tested by brave individuals and > eventually maybe become the default on that platform, obsoleting the > vfork support for good. > > The following patch does just that. I've tested it launching a > multi-process WildFly instance a bunch of times, in conjunction with > the conveniently existent "jdk.lang.Process.launchMechanism" property, > and nothing exploded so here it is. The usual deal with git patches: > apply directly through "patch -p1". > > commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 > Author: David M. Lloyd > Date: Thu Oct 18 15:56:37 2018 -0500 > > [JDK-6850720] Enable POSIX_SPAWN as an option for child process > creation on Linux > > diff --git a/make/launcher/Launcher-java.base.gmk > b/make/launcher/Launcher-java.base.gmk > index 0ce0287d2be..c28fe42d102 100644 > --- a/make/launcher/Launcher-java.base.gmk > +++ b/make/launcher/Launcher-java.base.gmk > @@ -84,7 +84,7 @@ endif > > ################################################################################ > > -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) > +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) > $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ > NAME := jspawnhelper, \ > SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > index 368a4f7380b..959e50dfecd 100644 > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { > > private static enum Platform { > > - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, > LaunchMechanism.FORK), > > BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), > > diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c > b/src/java.base/unix/native/libjava/ProcessImpl_md.c > index 533584fdb7a..6869a64f2cc 100644 > --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c > +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c > @@ -44,7 +44,7 @@ > #include > #include > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > || defined(__linux__) > #include > #endif > > @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { > return resultPid; > } > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > || defined(__linux__) > static pid_t > spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char > *helperpath) { > pid_t resultPid; > @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, > ChildStuff *c, const char *helperpath) > #endif > case MODE_FORK: > return forkChild(c); > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > || defined(__linux__) > case MODE_POSIX_SPAWN: > return spawnChild(env, process, c, helperpath); > #endif From philipp.kunz at paratix.ch Fri Oct 19 08:27:43 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Fri, 19 Oct 2018 10:27:43 +0200 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> <5BB51D1A.2000600@oracle.com> <1538683131.2782.10.camel@paratix.ch> Message-ID: <1539937663.2291.3.camel@paratix.ch> Hi Martin and everyone, You were absolutely right to object "utf". Please find a revised and updated patch attached. Regards, Philipp On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote: > "utf8" is a thing.??"utf" is not. > > On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz h> wrote: > > Thanks to Sherman's hint, I revised the test to use the terms > > unicode > > character and utf encoding consistently and not utf character. > > Affects > > only the test, mostly in comments and a few identifiers. > > > > Philipp > > > > > > On Wed, 2018-10-03 at 12:48 -0700, Xueming Shen wrote: > > > +1 > > > > > > only nit is it might be preferred to use "utf8" directly in the > > > test > > > instead of current "utf" > > > > > > -sherman > > > > > > On 10/03/2018 11:55 AM, Philipp Kunz wrote: > > > > In short, bug 6202130 is about removal of comments in > > > > Attributes > > > > like > > > > > > > > > XXX Need to handle UTF8 values and break up lines longer than > > > > > 72 > > > > > > > > The patch here contains a test that shows that utf characters > > > > are > > > > handled correctly, which has been the case before. Breaking > > > > lines > > > > has > > > > also been working before. > > > > > > > > In the main code, the patch only removes a few comments and > > > > does > > > > not > > > > change actual code. It all has been working before and now we > > > > know. > > > > > > > > Philipp > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > > > > > > > > > > > > > > > > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > > > > > Hi, > > > > > > > > > > There are some comments in the source code like this: > > > > > > > > > > ? >??XXX Need to handle UTF8 values and break up lines longer > > > > > than 72 bytes > > > > > > > > > > in Attributes.java on lines 299, 327, and 370. Bug 6202130 > > > > > also > > > > > suggests > > > > > to add a test to show that the character set is fully > > > > > supported > > > > > before > > > > > actually removing those comments. > > > > > > > > > > Hence, I added such a test, see ValueUtfEncoding in attached > > > > > patch, and > > > > > it finds the complete utf character set supported correctly > > > > > and > > > > > that it > > > > > has been so already before. > > > > > > > > > > The comments in Attributes also say that lines longer than 72 > > > > > bytes need > > > > > to be broken. That is a different issue and has been already > > > > > addressed > > > > > and solved in bug 6372077 and is now tested in > > > > > LineBreakLineWidth > > > > > and > > > > > therefore, that line break part of the comment is obsolete > > > > > now as > > > > > well > > > > > with the exception of version headers ("Manifest-Version" or > > > > > "Signature-Version") at least when taking strictly. > > > > > > > > > > Version headers are not subject of bug 6202130 for which my > > > > > patch > > > > > intends to provide a fix and if only because multi-byte > > > > > characters are > > > > > not allowed in version headers and wasn't subject of 6372077 > > > > > either > > > > > which was about too short lines rather than too long ones. If > > > > > I > > > > > would > > > > > change only the minimum I could argue was safe, there would > > > > > have > > > > > to > > > > > remain a comment in Attributes.java on line 327 like > > > > > > > > > > ? >??XXX Need to handle version headers longer than 72 bytes > > > > > > > > > > but I guess that should probably better be represented as > > > > > another > > > > > bug > > > > > rather than this style of comment if at all desired. There > > > > > are > > > > > some bugs > > > > > concerning version headers and particularly the behavior of > > > > > the > > > > > manifests in their absence, among possibly others, 6910466, > > > > > 4935610, > > > > > 4271239, 8196371 and 4256580 which have some relation but I > > > > > haven't > > > > > found one that really fits the 72 byte line length limit of > > > > > version > > > > > headers. Whether such a bug is created or found or not, it > > > > > does > > > > > not > > > > > directly relate to the one I'm trying to fix here, 6202130. > > > > > > > > > > If also the test is good I would assume that the comments can > > > > > be > > > > > removed now without actually changing the Manifest and > > > > > Attributes > > > > > implementation. > > > > > > > > > > Regards, > > > > > Philipp -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130.patch Type: text/x-patch Size: 9813 bytes Desc: not available URL: From matthias.baesken at sap.com Fri Oct 19 09:22:20 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 19 Oct 2018 09:22:20 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: > >java_props_md.c: 564. > >Please move the buildNumber check inside the "case 0:" above. >Then it won't need the extra check for minorVersion == 0. > Thanks for the remarks , I updated my changes , new webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.2/ Best regards, Matthias From: Bob Vandette Sent: Donnerstag, 18. Oktober 2018 16:36 To: Baesken, Matthias Cc: hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Langer, Christoph Subject: Re: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 It sounds like this is still not the last one but I?m ok with your check since the real GA will be higher and we?re real close. "On October 6, 2018, distribution of Windows version 1809 (build 17763[18]) was paused while Microsoft is investigating an issue with user data being deleted during an in-place upgrade.[19] It affected systems where a user profile folder (e.g. Documents, Music or Pictures) had been moved to another location, but data was left in the original location.[20]As Windows Server 2019 is based on the Windows version 1809 codebase, it too was removed from distribution.[21]?? Bob. On Oct 18, 2018, at 10:30 AM, Baesken, Matthias > wrote: Hello, please review my updated webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.1/ - check changed to build number of recently released Windows Server 2019 GA version (17763) - adjusted comments a bit ( see also https://en.wikipedia.org/wiki/Windows_Server_2019 for the list of build numbers ) Thanks, Matthias -----Original Message----- From: Baesken, Matthias Sent: Freitag, 12. Oktober 2018 08:57 To: 'Bob Vandette' > Cc: 'hotspot-dev at openjdk.java.net' >; 'core-libs-dev at openjdk.java.net' >; Langer, Christoph > Subject: RE: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 I got the info that the GA of Windows Server 2019 has build number 17763 . Should I update the webrev to check this build number (would mean we do not detect the preview as Windows Server 2019) , or keep it the way it is ? Current webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ Best regards, Matthias Hello Bob, Hi Bob, no problem , we can wait a few days until the final version of Win server 2019 is out, and check the buildNumber again : seems Windows server 2019 is GA now : https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows- server-2019-now-generally-available/ We don?t usually add logic to the JDK related to unreleased operating system previews. so I think we can process with the review . Still have to find out the buildNumber of the GA version, probably it has been incremented again . Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8211106 http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.0/webrev/ Thanks, Matthias From Alan.Bateman at oracle.com Fri Oct 19 10:05:29 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Oct 2018 11:05:29 +0100 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: On 19/10/2018 10:22, Baesken, Matthias wrote: > Thanks for the remarks , I updated my changes , new webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.2/ > Do you know if there is anything on the Microsoft site to explain why the minor version wasn't bumped? It looks unusual to have both Windows Server 2016 and 2019 report the same major and minor versions. -Alan From weijun.wang at oracle.com Fri Oct 19 10:18:32 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 19 Oct 2018 18:18:32 +0800 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: According to https://en.wikipedia.org/wiki/Windows_Server: Microsoft releases Windows Server in a LTS channel every few years named Windows Server 2016, Windows Server 2019, ... It also releases in a semi-annual channel named Windows Server, version 1803, 1809, ... I'm not sure if we can find out from which channel a system is from simply by looking at the version number. --Max > On Oct 19, 2018, at 6:05 PM, Alan Bateman wrote: > > On 19/10/2018 10:22, Baesken, Matthias wrote: >> Thanks for the remarks , I updated my changes , new webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.2/ >> > Do you know if there is anything on the Microsoft site to explain why the minor version wasn't bumped? It looks unusual to have both Windows Server 2016 and 2019 report the same major and minor versions. > > -Alan From matthias.baesken at sap.com Fri Oct 19 12:11:14 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 19 Oct 2018 12:11:14 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: Hi Alan, I agree it is a pity that the minor version (dwMinorVersion) was not increased . Looking at the build number was not my preferred way to handle this . My understanding (checked with our internal SAP-MS porting guys) is that the buildNumber of Windows server 2016 will not get larger than the minimum introduced buildNumber of Windows server 2019 . Best regards, Matthias > -----Original Message----- > From: Weijun Wang > Sent: Freitag, 19. Oktober 2018 12:19 > To: Alan Bateman > Cc: Baesken, Matthias ; Bob Vandette > ; roger.riggs at oracle.com; hotspot-dev Source > Developers ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR : 8211106: [windows] Update OS detection code to > recognize Windows Server 2019 > > According to https://en.wikipedia.org/wiki/Windows_Server: > > Microsoft releases Windows Server in a LTS channel every few years named > Windows Server 2016, Windows Server 2019, ... > > It also releases in a semi-annual channel named Windows Server, version > 1803, 1809, ... > > I'm not sure if we can find out from which channel a system is from simply by > looking at the version number. > > --Max > > > On Oct 19, 2018, at 6:05 PM, Alan Bateman > wrote: > > > > On 19/10/2018 10:22, Baesken, Matthias wrote: > >> Thanks for the remarks , I updated my changes , new webrev : > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8211106.2/ > >> > > Do you know if there is anything on the Microsoft site to explain why the > minor version wasn't bumped? It looks unusual to have both Windows > Server 2016 and 2019 report the same major and minor versions. > > > > -Alan From david.lloyd at redhat.com Fri Oct 19 12:20:07 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 19 Oct 2018 07:20:07 -0500 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: On Fri, Oct 19, 2018 at 1:56 AM Thomas St?fe wrote: > > Hi David, > > (for convenience, here the old thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html) > > I would rather not expose a third way to spawn to the end user. As a > test switch for developers, this seems fine. > > AFAIK (and someone please correct me if I am wrong) posix_spawn is not > the magical third way beside fork and vfork, it is just a wrapper > around fork/vfork and exec. Especially posix_spawn(), if using fork(), > will still have the same pitfalls raw fork() has - quasi-random ENOMEM > if we hit the overcommit heuristic, and inferior performance compared > to vfork. So you have nothing gained, you have just relegated the > fork/vfork decision down to a different layer, one which you have > little control over. And since that fork/vfork decision is kind of > important, you need that contol. We've gained the same thing that was gained in [1] and for the same reason: vfork is deprecated and it is an error to continue to rely directly on it. The only non-deprecated means of using vfork is via posix_spawn. And, posix_spawn is not the game of roulette that you make it out to be. To quote the manual page: "The child process is created using vfork(2) instead of fork(2) when either of the following is true: * the spawn-flags element of the attributes object pointed to by attrp contains the GNU-specific flag POSIX_SPAWN_USEVFORK; or * file_actions is NULL and the spawn-flags element of the attributes object pointed to by attrp does not contain POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF, POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER, POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS. In other words, vfork(2) is used if the caller requests it, or if there is no cleanup expected in the child before it exec(3)s the requested file." It is true that we aren't explicitly requesting it, however, in our case file_actions is NULL and attrp is also NULL, so posix_spawn will use vfork* on Linux. * Actually neither fork nor vfork use anything but the clone() syscall. To quote the sources, "The Linux implementation of posix_spawn{p} uses the clone syscall directly with CLONE_VM and CLONE_VFORK flags and an allocated stack." > Note that glibc has a flag to force always vfork behavior: > POSIX_SPAWN_USEVFORK. Sure, but I don't really see this as necessary if glibc is already following the vfork-like path. Another thing to know is that at least in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag is completely ignored. See also [2]. [1] https://bugs.openjdk.java.net/browse/JDK-8161360 [2] https://github.com/bminor/glibc/commit/ccfb2964726512f6669fea99a43afa714e2e6a80 -- - DML From james.laskey at oracle.com Fri Oct 19 17:50:19 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 19 Oct 2018 14:50:19 -0300 Subject: RFR: JDK-8212694 - Using Raw String Literals with align() and Integer.MIN_VALUE causes out of memory error Message-ID: <7D8502E9-B0F3-4F3A-9163-64C01BB54842@oracle.com> This fix proper clips large negative values for n. webrev: http://cr.openjdk.java.net/~jlaskey/8212694/webrev-00/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8212694 From vicente.romero at oracle.com Fri Oct 19 17:59:30 2018 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 19 Oct 2018 13:59:30 -0400 Subject: RFR: JDK-8210031: implementation for JVM Constants API In-Reply-To: References: <12D7246E-42DD-4BD4-B3E0-AB2FE015F8C2@oracle.com> <5a25000d-7bfb-56b3-0816-a96c3e49d956@oracle.com> <61e6cb70-9356-0b36-2a13-e90a3102f2c1@oracle.com> Message-ID: <8e1aa029-c9f1-a686-710a-82bbfb1ee5d6@oracle.com> Hi all, Thanks Mandy for the review. I have uploaded a new iteration [1]. Vicente [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.02/ On 10/18/18 9:55 PM, Mandy Chung wrote: > > > On 10/15/18 11:12 AM, Vicente Romero wrote: >> >> [1] http://cr.openjdk.java.net/~vromero/8210031/webrev.01 > > I reviewed java.lang.invoke change in details.? I have skimmed through > the new classes. > I will look at the new tests next. > > @since 12 is missing in the new APIs > > VarHandle.java > 1887 public final String toString() { > 1888 // @@@ defer to concrete type for additional description > 1889 // see https://bugs.openjdk.java.net/browse/JDK-8199149 You may > want to take out this comment or L1889 as we can refer back to > JDK-8199149. VarHandles.java > ?169???????? // @@@ This is a little fragile assuming the base is the > class > > Maybe FieldStaticReadOnly and FieldStaticReadWrite constructor and > getStaticFieldFromBaseAndOffset method should take Class refc > rather than Object base. FieldStaticReadXXX will do the cast when > calling getStaticFieldFromBaseAndOffset. > > java.base module-info.java > ?? It'd be good to keep the exported APIs in alphabetical order. > > java/lang/invoke/TypeDescriptor.java > ?? copyright header is missing > > Mandy From huizhe.wang at oracle.com Fri Oct 19 18:10:21 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 19 Oct 2018 11:10:21 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> Message-ID: <5BCA1E0D.9060406@oracle.com> On 10/17/18, 1:08 PM, Roger Riggs wrote: > Hi Joe, > > A few comments about the test. > > 45: the summary should mention it is testing the Files.mismatch method Files.mismatch it is. > > I think the @bug line should be empty, this is not a test for a bug. Consider along with Stuart's comment, that it points to the bug under which the changeset was pushed, would it be ok to keep it? > I don't think you need or use the testng group= functionality; if you > don't have a need for it omit it. Removed. > > > On the test files, I think I would have used testMismatch DataProvider to > create the files. It would avoid having to maintain parallel lists of > matching parameters. > The @beforeSetup might support the dataProvider directly, > but might have to iterate over the array itself, creating the files if > they do not exist. > And keeping the mapping from name to path in a Map instead of statics. Removed the class fields. They were converted from an array that was used for @AfterClass cleanup, now that I've added a temporary test directory, cleanup won't need them anymore. Not much sharing among the DataProviders either. So now they are created inside each DataProvider as needed. > > The code should use Assert.assertEquals(actual, expected, msg) so that > if there is a difference > it is printed. (instead of assertTrue ( n==m)...) Done. > > > The file sizes all seem to be multiples of 1024 or the buffer size. > There might be a good case for using a more varied sizes. Yeah, added a couple of more test groups with arbitrary sizes. > > 340: testMismatchNotExists: can the expected exception be more > specific: FileNotFoundException > instead of IOException. It appears isSameFile actually throws java.nio.file.NoSuchFileException rather than FileNotFoundException. Since isSameFile, as well as this spec, defined IOException, the expected exception spec-wise and impl-wise (it uses isSameFile) is indeed IOException. > > 370: This condition for zero made me wonder if there was a test case > for files that differ at 0. Added tests for a mismatch at 0, and also at size - 1 (at the end). > > 397: fillArray could probably make good use of System.arraycopy(). Sure. Current version: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ Previous: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ Thanks, Joe > > Regards, Roger > > > On 10/17/2018 03:33 PM, Joe Wang wrote: >> >> On 10/17/18, 7:16 AM, Roger Riggs wrote: >>> Hi Joe, >>> >>> Looks good, straightforward and easy to understand. >> >> Glad to hear that, while it's been back and forth a couple of times, >> it seems "straightforward and easy" won :-) >>> >>> The spec text in the CSR need to be updated to match. (At least the >>> paragraph about reflexive and atomic). >> >> CSR: update the text and attachment >> https://bugs.openjdk.java.net/browse/JDK-8202302 >> >> Also added coverage to spec case 5 - reflexive (no new test cases), >> spec case 6 - symmetric with tests selected from case 3. >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ >> >> Thanks, >> Joe >> >>> >>> Thanks, Roger >>> >>> On 10/16/2018 02:10 PM, Joe Wang wrote: >>>> Hi Daniel, >>>> >>>> @linkplain it is! Thanks! And yes, int totalRead was fixed in the >>>> previous webrevs. >>>> >>>> Current version: >>>> specdiff: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v04/java/nio/file/Files.html >>>> >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v04/ >>>> >>>> Previous version: >>>> specdiff: >>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v03/java/nio/file/Files.html >>>> >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v03/ >>>> >>>> Best regards, >>>> Joe >>>> >>>> On 10/16/18, 2:11 AM, Daniel Fuchs wrote: >>>>> Hi Joe, >>>>> >>>>> There are a few places where {@linkplain } should be used instead >>>>> of {@link }. For instance: >>>>> >>>>> 1545 *
  • The two paths locate the {@link #isSameFile(Path, >>>>> Path) same file}, >>>>> >>>>> This should be {@linkplain } - for the record {@link } will format >>>>> the >>>>> text as code, {@linkplain } will format it as regular text. Since the >>>>> text of the link is "same file" then it should be formatted as >>>>> regular >>>>> text - not as code. >>>>> >>>>> The link on the next line should probably be {@linkplain } as well. >>>>> >>>>> Otherwise looks good to me (except for the declaration of >>>>> int totalRead that should be long but Alan already mentioned it). >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> >>>>> On 12/10/2018 20:16, Joe Wang wrote: >>>>>> Here's an update based on all of the great reviews and comments >>>>>> (thanks all!): >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8202285 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202302 >>>>>> >>>>>> Current version: >>>>>> specdiff: >>>>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_02/java/nio/file/Files.html >>>>>> >>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v02/ >>>>>> >>>>>> Previous version: >>>>>> specdiff: >>>>>> http://cr.openjdk.java.net/~joehw/jdk12/8202285/specdiff_v01/java/nio/file/Files.html >>>>>> >>>>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v01/ >>>>>> >>>>>> It's been a while, so here's a summary of what's changed: >>>>>> >>>>>> Spec: Alan's patch to fix inconsistencies in wording/terminology >>>>>> Impl: s/mismatchByAttrs and etc/isSameFile; >>>>>> Stick with the simple implementation >>>>>> (InputStream/Buffer) for now. Further improvement may be done if >>>>>> there's a need; >>>>>> The impl is smaller than the previous version, merged >>>>>> the code into Files, removed FilesMismatch.java; >>>>>> >>>>>> Test: more readable variables instead of the array of test files >>>>>> more comments on the testcases >>>>>> improved the private methods used for generating the >>>>>> test files >>>>>> >>>>>> Thanks, >>>>>> Joe >>>>> >>> > > -- > Thanks, Roger From huizhe.wang at oracle.com Fri Oct 19 18:26:01 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 19 Oct 2018 11:26:01 -0700 Subject: RFR(JDK 12/NIO) 8202285: (fs) Add a method to Files for comparing file contents In-Reply-To: <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> References: <5BA299FE.9090406@oracle.com> <26bd4131-5bf9-b213-e19c-081e47398093@oracle.com> <5BA59F92.3010601@oracle.com> <5BC0F2F2.8040600@oracle.com> <6987e4c9-258e-8299-05e9-b7d173468acc@oracle.com> <5BC62998.6040507@oracle.com> <2fafcc16-3c8f-d23c-f480-811ea3f9e907@oracle.com> <5BC78EA5.1080208@oracle.com> <657e69e1-28ef-64ec-a6f5-aa62324978d1@oracle.com> Message-ID: <5BCA21B9.7040304@oracle.com> On 10/17/18, 3:03 PM, Stuart Marks wrote: > Hi Joe, > >> webrevs: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ > > I concur with Roger's comments on the test file generation. It would > be good to find some way to reduce the redundancy. He had some > suggestions that might work. You might also want to play around with > variations to see how they look. > > 375 byte[] bytes = "ABCDEFGHIJKLMNOPQRSTUVWXYZ > abcdefghijklmnopqrstuvwxyz 0123456789 \n".getBytes(); > > A small thing, but this uses the default charset, which is > platform-specific. I think it would be good to use > StandardCharsets.US_ASCII here. ASCII it is. > > Once you have this in bytes, it looks like all the other parts of the > test deal with bytes (not characters) so I don't think there are any > other concerns about charsets and such. > > 345 /** > 346 * Creates a file with alphanumeric content with one > character altered > 347 * at the specified position. > 348 * > 349 * @param dir the directory in which the file is to be created > 350 * @param purpose the purpose of the file > 351 * @param size the size of the file > 352 * @param pos the position where the alternative char is to > be added. If it > 353 * is smaller than zero, no alternation shall be > made. > 354 * @param c the character > 355 * @return path of the created file > 356 * @throws IOException > 357 */ > 358 private static Path createANFile(Path dir, String purpose, > int size, int pos, > 359 byte c) throws IOException { > 360 Path path = Files.createFile(Paths.get(dir.toString(), > purpose + ".txt")); > 361 if (size > 0) { > 362 writeAlphanumericFile(path, size, pos, c); > 363 } > 364 return path; > 365 } > > The problem with documenting things well is that the doc gets out of > date. :-) Very true, now I get to keep the doc as we switch back to char :-) > > (Well, actually somewhat serious.) > > This method creates test data files in terms of bytes (although the > bytes happen to be derived from ASCII characters). The altered data is > a byte at a particular byte offset, not a character. Several places in > the doc need to be updated to reflect this, since they still talk > about characters. > > Even though the altered data is a byte, for the convenience of the > caller, the parameter should be a char or an int. All the places where > this is called use a char literal casted to a byte: > > 125 test1024m1014a = createANFile(testDir, "test1024m1014a", > size, size - 10, (byte)'@'); > > If the parameter were a char or a int, the caller could just do: > > 125 test1024m1014a = createANFile(testDir, "test1024m1014a", > size, size - 10, '@'); > > The byte used to alter the test data could be the low order 7 bits > (since we're using ASCII) of the parameter value. Either document it > this way and simply mask off the high order bits of the parameter > value, or assert that those high order bits are all zeroes. Sounds good, the latter looks better with a char. It's a plus as I can keep the statement that says it alters one character. While only the low order byte matters for this test data (ASCII only), it's masked off to be clear about the intention. > > In writeAlphanumericFile(), > > 370 if (pos > 0) a[pos] = c; > > This should check should be for pos >= 0, since altering a byte at > position 0 is a valid test case. You might want to add this as another > test case. Changed to >=0, and added test cases for an altered byte at position 0 (as well as at the end). Current version: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v06/ Previous: http://cr.openjdk.java.net/~joehw/jdk12/8202285/webrev_v05/ Thanks, Joe > > s'marks From thomas.stuefe at gmail.com Fri Oct 19 19:54:19 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 19 Oct 2018 21:54:19 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Hi David, On Fri, Oct 19, 2018 at 2:20 PM David Lloyd wrote: > > On Fri, Oct 19, 2018 at 1:56 AM Thomas St?fe wrote: > > > > Hi David, > > > > (for convenience, here the old thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html) > > > > I would rather not expose a third way to spawn to the end user. As a > > test switch for developers, this seems fine. > > > > AFAIK (and someone please correct me if I am wrong) posix_spawn is not > > the magical third way beside fork and vfork, it is just a wrapper > > around fork/vfork and exec. Especially posix_spawn(), if using fork(), > > will still have the same pitfalls raw fork() has - quasi-random ENOMEM > > if we hit the overcommit heuristic, and inferior performance compared > > to vfork. So you have nothing gained, you have just relegated the > > fork/vfork decision down to a different layer, one which you have > > little control over. And since that fork/vfork decision is kind of > > important, you need that contol. > > We've gained the same thing that was gained in [1] and for the same > reason: vfork is deprecated and it is an error to continue to rely > directly on it. The only non-deprecated means of using vfork is via > posix_spawn. To me this seems not a strong reason. I do not see vfork() ever going away. My issue with posix_spawn() is that we hand control over how the way we fork to the libc implementation. That implementation may change. It did so in the past, for both glibc and muslc (I think muslc is important beside glibc, see https://openjdk.java.net/projects/portola/). My point is since we know exactly what we want we may be better off doing that ourselves. Also, in the past libc implementators have not been exactly easy to deal with, so if problems with posix_spawn() come up, it may be difficult to get them fixed. > > And, posix_spawn is not the game of roulette that you make it out to > be. To quote the manual page: > > "The child process is created using vfork(2) instead of fork(2) when > either of the following is true: > > * the spawn-flags element of the attributes object pointed to by > attrp contains the GNU-specific flag POSIX_SPAWN_USEVFORK; or > > * file_actions is NULL and the spawn-flags element of the attributes > object pointed to by attrp does not contain > POSIX_SPAWN_SETSIGMASK, POSIX_SPAWN_SETSIGDEF, > POSIX_SPAWN_SETSCHEDPARAM, POSIX_SPAWN_SETSCHEDULER, > POSIX_SPAWN_SETPGROUP, or POSIX_SPAWN_RESETIDS. > > In other words, vfork(2) is used if the caller requests it, or if > there is no cleanup expected in the child before it exec(3)s the > requested file." > > It is true that we aren't explicitly requesting it, however, in our > case file_actions is NULL and attrp is also NULL, so posix_spawn will > use vfork* on Linux. > > * Actually neither fork nor vfork use anything but the clone() > syscall. To quote the sources, "The Linux implementation of > posix_spawn{p} uses the clone syscall directly with CLONE_VM and > CLONE_VFORK flags and an allocated stack." > > > Note that glibc has a flag to force always vfork behavior: > > POSIX_SPAWN_USEVFORK. > > Sure, but I don't really see this as necessary if glibc is already > following the vfork-like path. Another thing to know is that at least > in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag > is completely ignored. See also [2]. > > [1] https://bugs.openjdk.java.net/browse/JDK-8161360 > [2] https://github.com/bminor/glibc/commit/ccfb2964726512f6669fea99a43afa714e2e6a80 > > -- > - DML You may be wrong about [2]. The relevant implementation in glibc seems to be this: https://github.com/tstuefe/glibc/blob/master/sysdeps/unix/sysv/linux/spawni.c and this seems to be the relevant change: https://github.com/tstuefe/glibc/commit/9ff72da471a509a8c19791efe469f47fa6977410 ( [2] is the "posix implementation". I am not sure what that is, maybe for Hurd?) So, glibc posix_spawn() uses clone with CLONE_VM and CLONE_VFORK. Interesting: if I understand the code right, they mitigate part of the dangers of vfork aka CLONE_VM by allocating a new separate stack for the child. --- Lets see what muslc does: https://github.com/esmil/musl/blob/master/src/process/posix_spawn.c So, they do exactly the same (I think the musl folks did this before glibc switched to clone). use clone(CLONE_VM|CLONE_VFORK). Hm okay. In conjunction with jspawnhelper this may work fine... I have to mull this over a bit more. -- One concern for me is that the change in the glibc is quite recent - 2016 - and that there may be many old glibc variants in the field installed which still use fork(). On those installations, switching the java vm to suddenly use posix_spawn may introduce regressions. My main concern - reliance on glibc developers for something we should better do ourselves - is unshaken, but lets see what others say. Kind Regards, Thomas From Alan.Bateman at oracle.com Sat Oct 20 08:06:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Oct 2018 09:06:14 +0100 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> Message-ID: <02bc7237-d7c7-dd8f-2d3d-eebe64a63eee@oracle.com> On 19/10/2018 13:11, Baesken, Matthias wrote: > Hi Alan, I agree it is a pity that the minor version (dwMinorVersion) was not increased . > Looking at the build number was not my preferred way to handle this . > > My understanding (checked with our internal SAP-MS porting guys) is that the buildNumber of Windows server 2016 will not get larger than > the minimum introduced buildNumber of Windows server 2019 . > The changes in your webrev look okay to me although I assume we need to be cautious about back porting until it becomes clear if Windows Server 2019 will be re-released or not.? The Windows Server blog [1] suggests that the release is paused while an issue is investigated and maybe a re-release will mean a new build number at least. -Alan [1] https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows-server-2019-now-generally-available From christoph.dreis at freenet.de Sat Oct 20 17:43:57 2018 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Sat, 20 Oct 2018 19:43:57 +0200 Subject: [NEW BUG][JDK12] Avoid subList overhead in String.split and Pattern.split Message-ID: <005001d4689c$7a22e0c0$6e68a240$@freenet.de> Hi, while looking through the code of String.split() and Pattern.split(), I wondered if we could get rid of the calls to list.subList(0, resultSize) if resultSize matches the size of the list. If that's the case, subList() seems redundant. JMH Benchmarks in single-shot mode show the following results with a new revised version (attached below): Benchmark Mode Cnt Score Error Units MyBenchmark.testNew ss 10 12957,900 ? 7800,863 ns/op MyBenchmark.testNew:?gc.alloc.rate ss 10 6,248 ? 3,231 MB/sec MyBenchmark.testNew:?gc.alloc.rate.norm ss 10 1384,000 ? 0,001 B/op MyBenchmark.testNew:?gc.count ss 10 ? 0 counts MyBenchmark.testOld ss 10 25017,800 ? 19178,411 ns/op MyBenchmark.testOld:?gc.alloc.rate ss 10 4,887 ? 3,764 MB/sec MyBenchmark.testOld:?gc.alloc.rate.norm ss 10 1464,000 ? 0,001 B/op MyBenchmark.testOld:?gc.count ss 10 ? 0 counts Other benchmark modes show inconclusive results from the throughput perspective, yet it's clearly visible that less objects are allocated. Could anybody verify if that's a worthwhile improvement? And in case it is, potentially sponsor it? Thanks in advance. Cheers, Christoph ===== PATCH ===== diff -r 5e894b0f5e63 src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java Fri Oct 19 16:29:45 2018 -0700 +++ b/src/java.base/share/classes/java/lang/String.java Sat Oct 20 18:49:02 2018 +0200 @@ -2315,6 +2315,9 @@ } } String[] result = new String[resultSize]; + if (list.size() == resultSize) { + return list.toArray(result); + } return list.subList(0, resultSize).toArray(result); } return Pattern.compile(regex).split(this, limit); diff -r 5e894b0f5e63 src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java Fri Oct 19 16:29:45 2018 -0700 +++ b/src/java.base/share/classes/java/util/regex/Pattern.java Sat Oct 20 18:49:02 2018 +0200 @@ -1293,6 +1293,9 @@ while (resultSize > 0 && matchList.get(resultSize-1).equals("")) resultSize--; String[] result = new String[resultSize]; + if (matchList.size() == resultSize) { + return matchList.toArray(result); + } return matchList.subList(0, resultSize).toArray(result); } From wdietl at gmail.com Wed Oct 17 02:26:42 2018 From: wdietl at gmail.com (Werner Dietl) Date: Tue, 16 Oct 2018 22:26:42 -0400 Subject: JDK 12 RFR of JDK-8212081: AnnotatedType.toString implementation don't print annotations on embedded types In-Reply-To: <5c9fab13-f06c-0cba-d3f4-8ee250f94de6@oracle.com> References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> <5c9fab13-f06c-0cba-d3f4-8ee250f94de6@oracle.com> Message-ID: Hi Joe, thanks for fixing this! I like the improved testing approach. Changes look good to me, but I'm not a reviewer. Best, cu, WMD. On Mon, Oct 15, 2018 at 2:11 AM joe darcy wrote: > > Follow-up fix developed; details below. > > On 10/11/2018 12:12 PM, joe darcy wrote: > > Hi Werner, > > > > On 10/10/2018 1:23 PM, Werner Dietl wrote: > >> Hi Joe, all, > >> > >> the logic looks good to me. > >> > >> In the tests I'm wondering whether to include an annotated wildcard > >> bound. There is: > >> > >> 307 public @AnnotType(11) Set<@AnnotType(13) ? extends Number> > >> fooNumberSet2() {return null;} > >> > >> but nothing like > >> > >> Set fooNumberSet2() {return null;} > >> > >> I wouldn't expect problems for this, but a test would exercise some of > >> the code that gets added. > > > > You were correct to probe at the bounds on the wildcard components; > > the code that was reviewed and pushed does not print annotations on > > the bounds. > > > > I'll work on an update to handle this and similar cases where there > > are embedded types that could have annotations. > > > > Please review the fix for > > JDK-8212081 : AnnotatedType.toString implementation don't print > annotations on embedded types > http://cr.openjdk.java.net/~darcy/8212081.1/ > > A few notes on the test, the main structural change is that information > about the expected properties of the toString form of the AnnotatedType > of a method's return type is stored in a *declaration annotation* on the > method. The presence of the expected number of type annotations on the > full string of the AnnotatedType can thus be directly tested. > > Thanks, > > -Joe -- http://www.google.com/profiles/wdietl From martinrb at google.com Sun Oct 21 22:10:52 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 21 Oct 2018 15:10:52 -0700 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: <1539937663.2291.3.camel@paratix.ch> References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> <5BB51D1A.2000600@oracle.com> <1538683131.2782.10.camel@paratix.ch> <1539937663.2291.3.camel@paratix.ch> Message-ID: I only took a quick look. Looks good, but here's a nitpick - capitalize javadoc that begins with "returns" On Fri, Oct 19, 2018 at 1:27 AM, Philipp Kunz wrote: > Hi Martin and everyone, > > You were absolutely right to object "utf". > Please find a revised and updated patch attached. > > Regards, > Philipp > > > > On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote: > > "utf8" is a thing. "utf" is not. > > > > On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz > h> wrote: > > > Thanks to Sherman's hint, I revised the test to use the terms > > > unicode > > > character and utf encoding consistently and not utf character. > > > Affects > > > only the test, mostly in comments and a few identifiers. > > > > > > Philipp > > > > > > > > > On Wed, 2018-10-03 at 12:48 -0700, Xueming Shen wrote: > > > > +1 > > > > > > > > only nit is it might be preferred to use "utf8" directly in the > > > > test > > > > instead of current "utf" > > > > > > > > -sherman > > > > > > > > On 10/03/2018 11:55 AM, Philipp Kunz wrote: > > > > > In short, bug 6202130 is about removal of comments in > > > > > Attributes > > > > > like > > > > > > > > > > > XXX Need to handle UTF8 values and break up lines longer than > > > > > > 72 > > > > > > > > > > The patch here contains a test that shows that utf characters > > > > > are > > > > > handled correctly, which has been the case before. Breaking > > > > > lines > > > > > has > > > > > also been working before. > > > > > > > > > > In the main code, the patch only removes a few comments and > > > > > does > > > > > not > > > > > change actual code. It all has been working before and now we > > > > > know. > > > > > > > > > > Philipp > > > > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > > > > > > Hi, > > > > > > > > > > > > There are some comments in the source code like this: > > > > > > > > > > > > > XXX Need to handle UTF8 values and break up lines longer > > > > > > than 72 bytes > > > > > > > > > > > > in Attributes.java on lines 299, 327, and 370. Bug 6202130 > > > > > > also > > > > > > suggests > > > > > > to add a test to show that the character set is fully > > > > > > supported > > > > > > before > > > > > > actually removing those comments. > > > > > > > > > > > > Hence, I added such a test, see ValueUtfEncoding in attached > > > > > > patch, and > > > > > > it finds the complete utf character set supported correctly > > > > > > and > > > > > > that it > > > > > > has been so already before. > > > > > > > > > > > > The comments in Attributes also say that lines longer than 72 > > > > > > bytes need > > > > > > to be broken. That is a different issue and has been already > > > > > > addressed > > > > > > and solved in bug 6372077 and is now tested in > > > > > > LineBreakLineWidth > > > > > > and > > > > > > therefore, that line break part of the comment is obsolete > > > > > > now as > > > > > > well > > > > > > with the exception of version headers ("Manifest-Version" or > > > > > > "Signature-Version") at least when taking strictly. > > > > > > > > > > > > Version headers are not subject of bug 6202130 for which my > > > > > > patch > > > > > > intends to provide a fix and if only because multi-byte > > > > > > characters are > > > > > > not allowed in version headers and wasn't subject of 6372077 > > > > > > either > > > > > > which was about too short lines rather than too long ones. If > > > > > > I > > > > > > would > > > > > > change only the minimum I could argue was safe, there would > > > > > > have > > > > > > to > > > > > > remain a comment in Attributes.java on line 327 like > > > > > > > > > > > > > XXX Need to handle version headers longer than 72 bytes > > > > > > > > > > > > but I guess that should probably better be represented as > > > > > > another > > > > > > bug > > > > > > rather than this style of comment if at all desired. There > > > > > > are > > > > > > some bugs > > > > > > concerning version headers and particularly the behavior of > > > > > > the > > > > > > manifests in their absence, among possibly others, 6910466, > > > > > > 4935610, > > > > > > 4271239, 8196371 and 4256580 which have some relation but I > > > > > > haven't > > > > > > found one that really fits the 72 byte line length limit of > > > > > > version > > > > > > headers. Whether such a bug is created or found or not, it > > > > > > does > > > > > > not > > > > > > directly relate to the one I'm trying to fix here, 6202130. > > > > > > > > > > > > If also the test is good I would assume that the comments can > > > > > > be > > > > > > removed now without actually changing the Manifest and > > > > > > Attributes > > > > > > implementation. > > > > > > > > > > > > Regards, > > > > > > Philipp > From martinrb at google.com Mon Oct 22 00:25:24 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 21 Oct 2018 17:25:24 -0700 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: As author of the vfork strategy ... I'm supportive of the directions in this thread.???? David's patch seems like clear progress (although maybe now that we have configure, we can make the spawn strategy conditional on HAVE_SPAWN_H) vfork is even (!) less in favor than it used to be, so migrating off of it seems good. Just make sure we don't bring back the OOM problems or unacceptable overhead from e.g. an second exec. Create a 100GB heap, then run /bin/true 1000 times. That big internal comment I wrote years ago is suffering from bitrot. IIRC vfork used to call a special vfork system call, NOT clone, years ago. From martinrb at google.com Mon Oct 22 00:37:33 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 21 Oct 2018 17:37:33 -0700 Subject: Approval Request to update TreeSet#add method documentation In-Reply-To: References: Message-ID: Hi Kishor, I think your attachment was stripped out - standard policy for this mailing list, I think. For a small patch like this, you should just include the patch inline in text form. On Thu, Oct 18, 2018 at 2:21 AM, Kishor Gollapalliwar < kishor.gollapalliwar at gmail.com> wrote: > Hi Team, > > Please provide your approval to update TreeSet#add method as it's > documentation and behavior are not consistent. > > For more information, please refer my mail below and attachment. > > Thanks & Regards, > *Kishor Golapelliwar,* > The ability to convert ideas to things is the secret to outward success. > > ---------- Forwarded message --------- > From: Kishor Gollapalliwar > Date: Mon, Oct 15, 2018 at 11:40 AM > Subject: Re: Inconsistencies in TreeSet Interface > To: > Cc: > > > Hello Everyone, > > This is the first time I am writing mail to this group, hence please ignore > my nuisance and guide me towards right direction. > > As suggested by Martin, I believe documentation need to be updated. > I would happy to update the documentation, please provide your inputs. > I have attache the .java file for more details. > > @Martin : I really appreciate your advice and help, thank you. > > Thank you, > Kishor Gollapalliwar > > On Sat, Oct 13, 2018 at 11:40 PM Martin Buchholz > wrote: > > > core-libs-dev is the right mailing list. > > > > The documentation could be improved, but it's nuanced - consider using a > > TreeSet with a Comparator that accepts null. > > > > On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < > > kishor.gollapalliwar at gmail.com> wrote: > > > >> Hello Everyone, > >> > >> Introduction : I?m an enthusiast java developer. I?m a newbie in this > >> group, hence please ignore my nuisance and guide me towards right > >> direction. > >> > >> ## Problems Statement > >> > >> Treeset#add method documentations : ?adds the specified element e to > this > >> set if the set contains no element e2 such that (e==null ? e2==null : > >> e.equals(e2))? > >> > >> Inconsistencies: > >> > >> > If we try to add ?null? value, it will throws NullPointerException, > >> hence > >> > e and e2 can not be null. > >> > >> > >> > >> > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to > >> > collection. > >> > >> > >> Request you to help me understand if behavior of Treeset#add method is > as > >> expected, and differ with set interface documentation. We may have to > >> consider to update method documentations, if behavior is expected. > >> > >> For more details I have attached the sample java application. > >> > >> I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK 8u181. > >> > >> Thanks & Regards, > >> *Kishor Golapelliwar,* > >> The ability to convert ideas to things is the secret to outward success. > >> > > > > > From tobias.hartmann at oracle.com Mon Oct 22 06:26:56 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 22 Oct 2018 08:26:56 +0200 Subject: Review Request: JDK-8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference In-Reply-To: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> References: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> Message-ID: <7adbb064-d0da-e1a2-c78e-ebc389b11f0f@oracle.com> Hi Mandy, the compiler related changes look good to me. Please run hs-tier1-3 if you haven't done so yet. Best regards, Tobias On 16.10.18 18:08, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8207146/webrev.00/ > > Unsafe::getObject returns a reference to an object. Similarly > Unsafe::putObject sets a reference in the given base+offset. > This patch proposes to rename Unsafe xxxObject to xxxReference > that will make the xxxReference API very clear that these > are getters/setters for a reference (instance of object class) > and ready for adding xxxValue in the futurefor values. > Note that this renaming only applies to jdk.internal.misc.Unsafe > but not sun.misc.Unsafe.? So no impact to existing libraries > that depends on sun.misc.Unsafe in jdk.unsupported module. > > I ran jdk_core, core_tools, langtools and nashorn tier1-3, > hotspot_runtime, hotspot_compiler test groups. > > thanks > Mandy From claes.redestad at oracle.com Mon Oct 22 09:58:32 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 22 Oct 2018 11:58:32 +0200 Subject: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory Message-ID: Hi, StringConcatFactory uses a customized internal foldArguments implementation which takes positional arguments to avoid intermediary permutation steps, see JDK-8165492[1]. My intent has been to clean this up for possible inclusion in the public API. In preparation of that, I realized that we could probably profit from a filtering combinator on top of the existing folding one. Said and done: http://cr.openjdk.java.net/~redestad/8212726/jdk.00/ https://bugs.openjdk.java.net/browse/JDK-8212726 Using this new MethodHandles.filterArgumentsWithCombiner in place of MHs.dropArguments + MHs.foldArgumentsWithCombiner gets rid of a significant number of MethodHandles with retained performance characteristics. In startup tests exercising indified String concatenation the number of generated classes drops by ~25-30%, with a measurable improvement in startup time as a result. Subjectively it also makes the code in StringConcatFactory easier to read and follow. While this surely strengthens the case to include these in the public API, I'd like to move ahead with this as an internal optimization first and propose MethodHandles.filter-/foldArgumentsWithCombiner as public API points as a follow-up: apart from improving the javadoc we need to work out specification for corner cases - especially illegal values - and harden the implementation with more tests. I'm sure there might be opinions about the naming of these methods, too... :-) Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8165492 From matthias.baesken at sap.com Mon Oct 22 11:18:47 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 22 Oct 2018 11:18:47 +0000 Subject: RFR : 8211106: [windows] Update OS detection code to recognize Windows Server 2019 In-Reply-To: <02bc7237-d7c7-dd8f-2d3d-eebe64a63eee@oracle.com> References: <3F7E2792-DA3E-4AFD-9869-95841D4ED896@oracle.com> <02bc7237-d7c7-dd8f-2d3d-eebe64a63eee@oracle.com> Message-ID: Hi Alan , in case there is a re-release of Windows server 2019 the buildNumber might (or might not) increase. But it will not decrease. So I think we are fine with the current check . > although I assume we need to be cautious about back porting Sure we can wait a couple of weeks before backporting it to jdk11u . Best regards, Matthias > -----Original Message----- > From: Alan Bateman > Sent: Samstag, 20. Oktober 2018 10:06 > To: Baesken, Matthias > Cc: hotspot-dev Source Developers ; core- > libs-dev at openjdk.java.net; Moldenhauer, Niclas > > Subject: Re: RFR : 8211106: [windows] Update OS detection code to > recognize Windows Server 2019 > > On 19/10/2018 13:11, Baesken, Matthias wrote: > > Hi Alan, I agree it is a pity that the minor version (dwMinorVersion) was > not increased . > > Looking at the build number was not my preferred way to handle this . > > > > My understanding (checked with our internal SAP-MS porting guys) is > that the buildNumber of Windows server 2016 will not get larger than > > the minimum introduced buildNumber of Windows server 2019 . > > > The changes in your webrev look okay to me although I assume we need to > be cautious about back porting until it becomes clear if Windows Server > 2019 will be re-released or not.? The Windows Server blog [1] suggests > that the release is paused while an issue is investigated and maybe a > re-release will mean a new build number at least. > > -Alan > > [1] > https://cloudblogs.microsoft.com/windowsserver/2018/10/02/windows- > server-2019-now-generally-available From james.laskey at oracle.com Mon Oct 22 12:07:34 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 22 Oct 2018 09:07:34 -0300 Subject: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory In-Reply-To: References: Message-ID: <23256FEA-E07F-43C1-9D5D-E28F90033465@oracle.com> Thank you for doing this. The MethodHandle changes will simplify many a use case. Cheers, ? Jim > On Oct 22, 2018, at 6:58 AM, Claes Redestad wrote: > > Hi, > > StringConcatFactory uses a customized internal foldArguments > implementation which takes positional arguments to avoid intermediary > permutation steps, see JDK-8165492[1]. My intent has been to clean this > up for possible inclusion in the public API. > > In preparation of that, I realized that we could probably profit from a > filtering combinator on top of the existing folding one. Said and done: > > http://cr.openjdk.java.net/~redestad/8212726/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8212726 > > Using this new MethodHandles.filterArgumentsWithCombiner in place of > MHs.dropArguments + MHs.foldArgumentsWithCombiner gets rid of a > significant number of MethodHandles with retained performance > characteristics. In startup tests exercising indified String > concatenation the number of generated classes drops by ~25-30%, with a > measurable improvement in startup time as a result. Subjectively it also > makes the code in StringConcatFactory easier to read and follow. > > While this surely strengthens the case to include these in the public > API, I'd like to move ahead with this as an internal optimization first > and propose MethodHandles.filter-/foldArgumentsWithCombiner as public > API points as a follow-up: apart from improving the javadoc we need to > work out specification for corner cases - especially illegal values - > and harden the implementation with more tests. I'm sure there might be > opinions about the naming of these methods, too... :-) > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8165492 From claes.redestad at oracle.com Mon Oct 22 12:24:16 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 22 Oct 2018 14:24:16 +0200 Subject: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory In-Reply-To: <23256FEA-E07F-43C1-9D5D-E28F90033465@oracle.com> References: <23256FEA-E07F-43C1-9D5D-E28F90033465@oracle.com> Message-ID: <09ce7f07-fb66-27ae-05aa-b36def2d16fc@oracle.com> On 2018-10-22 14:07, Jim Laskey wrote: > Thank you for doing this. Thanks for looking at this, Jim! > The MethodHandle changes will simplify many a use case. Thanks! I'm particularly happy with how this optimization helped simplify the SCF code - no reason to think it won't help simplify other use cases too. /Claes From david.lloyd at redhat.com Mon Oct 22 13:25:54 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 22 Oct 2018 08:25:54 -0500 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: On Sun, Oct 21, 2018 at 7:25 PM Martin Buchholz wrote: > As author of the vfork strategy ... I'm supportive of the directions in this thread. Great. > vfork is even (!) less in favor than it used to be, so migrating off of it seems good. Just make sure we don't bring back the OOM problems or unacceptable overhead from e.g. an second exec. Create a 100GB heap, then run /bin/true 1000 times. Tried it and it succeeded without issues. I didn't use a 100GB heap though because I don't have that kind of RAM! But, I created a long chain of object arrays totalling about 8GB and forced it to stay alive until after the 1000 execs of /bin/true and it worked fine. To verify that the program works correctly, I compared the results with VFORK and FORK. As expected, VFORK also worked correctly, but FORK failed with errno=ENOMEM. -- - DML From fweimer at redhat.com Mon Oct 22 13:37:26 2018 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 22 Oct 2018 15:37:26 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: (David Lloyd's message of "Fri, 19 Oct 2018 07:20:07 -0500") References: Message-ID: <8736sy5ch5.fsf@oldenburg.str.redhat.com> * David Lloyd: > Sure, but I don't really see this as necessary if glibc is already > following the vfork-like path. Another thing to know is that at least > in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag > is completely ignored. See also [2]. Right, the manual pages are outdated. For applications, there is never a good reason to use POSIX_SPAWN_USEVFORK because the glibc implementation is either buggy when this flag is used, or the flag does nothing. The bugs may matter to applications using OpenJDK, so I don't think you can set the flag within OpenJDK. So the only thing you can do here is to use posix_spawn *without* POSIX_SPAWN_USEVFORK, and advise OS vendors to backport the glibc changes if they have customers that are impacted by the lack of process creation performance (or OOM during process creation). Another possibility would be to emulate what glibc's fixed, fork-based posix_spawn does, but this requires writing some machine code (for vfork/clone) and issuing direct system calls to bypass some abstractions in glibc (for setprocmask). > [2] https://github.com/bminor/glibc/commit/ccfb2964726512f6669fea99a43afa714e2e6a80 Note that this neither the canonical glibc source code location, nor is the code actually used on Linux. 8-) Thanks, Florian From mandy.chung at oracle.com Mon Oct 22 17:08:40 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Oct 2018 10:08:40 -0700 Subject: Review Request: JDK-8207146: Rename jdk.internal.misc.Unsafe::xxxObject to xxxReference In-Reply-To: <7adbb064-d0da-e1a2-c78e-ebc389b11f0f@oracle.com> References: <3bed4fd6-1f6f-b95d-1eb9-62396a8e9815@oracle.com> <7adbb064-d0da-e1a2-c78e-ebc389b11f0f@oracle.com> Message-ID: Thanks for the review, Tobias. I will rerun the tests and add hs-tier1-3 jobs before the push. Mandy On 10/21/18 11:26 PM, Tobias Hartmann wrote: > Hi Mandy, > > the compiler related changes look good to me. > > Please run hs-tier1-3 if you haven't done so yet. > > Best regards, > Tobias > > > On 16.10.18 18:08, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8207146/webrev.00/ >> >> Unsafe::getObject returns a reference to an object. Similarly >> Unsafe::putObject sets a reference in the given base+offset. >> This patch proposes to rename Unsafe xxxObject to xxxReference >> that will make the xxxReference API very clear that these >> are getters/setters for a reference (instance of object class) >> and ready for adding xxxValue in the futurefor values. >> Note that this renaming only applies to jdk.internal.misc.Unsafe >> but not sun.misc.Unsafe.? So no impact to existing libraries >> that depends on sun.misc.Unsafe in jdk.unsupported module. >> >> I ran jdk_core, core_tools, langtools and nashorn tier1-3, >> hotspot_runtime, hotspot_compiler test groups. >> >> thanks >> Mandy From thomas.stuefe at gmail.com Mon Oct 22 18:22:42 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 22 Oct 2018 20:22:42 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <8736sy5ch5.fsf@oldenburg.str.redhat.com> References: <8736sy5ch5.fsf@oldenburg.str.redhat.com> Message-ID: Hi all, First off, to be clear, I am certainly shedding no tears if I do not get to contribute my vfork+exec*2 patch to upstream. It is a lot of work, and I much rather do something else. However, I have spend too much of my life with the Runtime.exec() layer to be easy about changing it. So far I have not read a single technical reason in this thread why vfork needs to be abandoned now - apart from it being obsolete. If you read my initial thread from September, you know that I think we have understood vfork's shortcomings very well, and that our (SAPs) proposed patch shows that they can be dealt with. In our port, our vfork+exec*2 is solid since many years, without any issues. I see that posix_spawn(), in its current form in the glibc and muslc, could be a good option. Long term, maybe better than a home grown one. But before we switch to posix_spawn(), I would like to understand better, at least for the major distros, which distro would be affected by regressions. Also, if we decide to switch to posix_spawn(), I would like to prevent "accidental backporting" without checking the platform requirements. The current posix_spawn() implementation was added to glibc with glibc 2.24. So, what was the state of posix_spawn() before that version? Is it safe to use, does it do the right thing, or will we encounter regressions? My Ubuntu 16.04 box runs glibc 2.23. Arguably, Ubuntu 16.04 is quite a common distro. I have to check our machines at work, but I am very sure that our zoo of SLES and RHEL servers do not all run glibc>=2.24, especially on the more exotic architectures. @Florian: > and advise OS vendors to backport the > glibc changes if they have customers that are impacted by the lack of > process creation performance (or OOM during process creation). Please not. We have no leverage toward the OS vendors, we cannot "advise" anything. Even if OS vendors react and fix, we disrupt our users and make them unhappy with us and with java. Every issue has to be first analyzed before it even finds the way to us, let alone the OS vendor. Lets not risk breaking userspace (don't you guys have a rule like that :)? Best Regards, Thomas On Mon, Oct 22, 2018 at 3:37 PM Florian Weimer wrote: > > * David Lloyd: > > > Sure, but I don't really see this as necessary if glibc is already > > following the vfork-like path. Another thing to know is that at least > > in the 2.26 sources I have checked out, the POSIX_SPAWN_USEVFORK flag > > is completely ignored. See also [2]. > > Right, the manual pages are outdated. > > For applications, there is never a good reason to use > POSIX_SPAWN_USEVFORK because the glibc implementation is either buggy > when this flag is used, or the flag does nothing. The bugs may matter > to applications using OpenJDK, so I don't think you can set the flag > within OpenJDK. So the only thing you can do here is to use posix_spawn > *without* POSIX_SPAWN_USEVFORK, and advise OS vendors to backport the > glibc changes if they have customers that are impacted by the lack of > process creation performance (or OOM during process creation). > > Another possibility would be to emulate what glibc's fixed, fork-based > posix_spawn does, but this requires writing some machine code (for > vfork/clone) and issuing direct system calls to bypass some abstractions > in glibc (for setprocmask). > > > [2] https://github.com/bminor/glibc/commit/ccfb2964726512f6669fea99a43afa714e2e6a80 > > Note that this neither the canonical glibc source code location, nor > is the code actually used on Linux. 8-) > > Thanks, > Florian From vladimir.x.ivanov at oracle.com Mon Oct 22 18:52:31 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 22 Oct 2018 11:52:31 -0700 Subject: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory In-Reply-To: References: Message-ID: <09200d43-5d02-c241-c96b-2f5ec0596478@oracle.com> Looks good! Best regards, Vladimir Ivanov On 22/10/2018 02:58, Claes Redestad wrote: > Hi, > > StringConcatFactory uses a customized internal foldArguments > implementation which takes positional arguments to avoid intermediary > permutation steps, see JDK-8165492[1]. My intent has been to clean this > up for possible inclusion in the public API. > > In preparation of that, I realized that we could probably profit from a > filtering combinator on top of the existing folding one. Said and done: > > http://cr.openjdk.java.net/~redestad/8212726/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8212726 > > Using this new MethodHandles.filterArgumentsWithCombiner in place of > MHs.dropArguments + MHs.foldArgumentsWithCombiner gets rid of a > significant number of MethodHandles with retained performance > characteristics. In startup tests exercising indified String > concatenation the number of generated classes drops by ~25-30%, with a > measurable improvement in startup time as a result. Subjectively it also > makes the code in StringConcatFactory easier to read and follow. > > While this surely strengthens the case to include these in the public > API, I'd like to move ahead with this as an internal optimization first > and propose MethodHandles.filter-/foldArgumentsWithCombiner as public > API points as a follow-up: apart from improving the javadoc we need to > work out specification for corner cases - especially illegal values - > and harden the implementation with more tests. I'm sure there might be > opinions about the naming of these methods, too... :-) > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8165492 From claes.redestad at oracle.com Mon Oct 22 18:54:51 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 22 Oct 2018 20:54:51 +0200 Subject: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory In-Reply-To: <09200d43-5d02-c241-c96b-2f5ec0596478@oracle.com> References: <09200d43-5d02-c241-c96b-2f5ec0596478@oracle.com> Message-ID: <42d6a44c-411d-d5d2-e563-533b4d2c71e8@oracle.com> On 2018-10-22 20:52, Vladimir Ivanov wrote: > Looks good! Thanks, Vladimir! /Claes From fweimer at redhat.com Mon Oct 22 18:59:57 2018 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 22 Oct 2018 20:59:57 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: ("Thomas \=\?utf-8\?Q\?St\=C3\=BCfe\=22's\?\= message of "Mon, 22 Oct 2018 20:22:42 +0200") References: <8736sy5ch5.fsf@oldenburg.str.redhat.com> Message-ID: <87efch3iz6.fsf@oldenburg.str.redhat.com> * Thomas St?fe: > So far I have not read a single technical reason in this thread why > vfork needs to be abandoned now - apart from it being obsolete. If you > read my initial thread from September, you know that I think we have > understood vfork's shortcomings very well, and that our (SAPs) > proposed patch shows that they can be dealt with. In our port, our > vfork+exec*2 is solid since many years, without any issues. The main problem for vfork in application code is that you need to *all* disable signals, even signals used by the implementation. If a signal handler runs by accident while the vfork is active, memory corruption is practically guaranteed. The only way to disable the signals is with a direct system call; sigprocmask/pthread_sigmask do not work. Does your implementation do this? > The current posix_spawn() implementation was added to glibc with glibc > 2.24. So, what was the state of posix_spawn() before that version? Is > it safe to use, does it do the right thing, or will we encounter > regressions? It uses fork by default. It can be told to use vfork, via POSIX_SPAWN_USEVFORK, but then it is buggy. For generic JDK code, this seems hardly appropriate. > My Ubuntu 16.04 box runs glibc 2.23. Arguably, Ubuntu 16.04 is quite a > common distro. I have to check our machines at work, but I am very > sure that our zoo of SLES and RHEL servers do not all run glibc>=2.24, > especially on the more exotic architectures. In glibc, the vfork-based performance does not bring in any new ABIs, so it is in theory backportable. The main risk is that the vfork optimization landed in glibc 2.24, and the PID cache was removed in glibc 2.25. vfork with the PID cache was really iffy, but I would not recommend to backport the PID cache removal. But Debian 9/stretch uses glibc 2.24, and I think that shows that the vfork optimization with the PID cache should be safe enough. (Of course you need to remove the assert that fires if the vfork does not actually stop the parent process and is implemented as a fork; the glibc implementation still works, but with somewhat degraded error checking.) How far back would you want to see this changed? Debian jessie and Red Hat Enterprise Linux 6 would be rather unlikely. If you want to target those, your only chance is to essentially duplicate the glibc implementation in OpenJDK. Thanks, Florian From david.lloyd at redhat.com Mon Oct 22 19:00:08 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Mon, 22 Oct 2018 14:00:08 -0500 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <8736sy5ch5.fsf@oldenburg.str.redhat.com> Message-ID: On Mon, Oct 22, 2018 at 1:23 PM Thomas St?fe wrote: > Hi all, [...] > So far I have not read a single technical reason in this thread why > vfork needs to be abandoned now Note that my patch does not abandon vfork. It does not even change the default exec strategy away from vfork, nor does it cause any obstacle to your proposed change. It only adds the ability for users to opt in to the existing posix_spawn implementation on Linux. It's just a first step, in whatever direction we might be going, which is far from decided. As you and Martin have both implied, it's a good idea to be very cautious in this area. > The current posix_spawn() implementation was added to glibc with glibc 2.24. So, what was the state of posix_spawn() before that version? Is it safe to use, does it do the right thing, or will we encounter regressions? I certainly have not suggested making posix_spawn be the default on Linux at this time. But if we don't make it at least a possible option, it cannot be tested *at all*, by anyone, unless they're adventurous enough to hack OpenJDK themselves. The questions you ask can not be answered without at least making it a choice. There are many reasonable paths that can be taken after this patch is merged (if it is): ? It could stop here and keep the status quo; users who have trouble with the current implementation can try out posix_spawn ? The Linux port could be modified similarly to your proposal to use the existing jspawnhelper infrastructure with vfork on Linux, while still allowing posix_spawn to be manually selected ? The Linux port could be modified to use posix_spawn if gnu_get_libc_version(3) and/or other run-time probes return an acceptable value, using vfork (either the original or your modified approach) otherwise, still allowing posix_spawn to be manually selected Other possibilities exist as well. Nothing in this email thread (AFAICT) invalidates your basic proposal, other than perhaps the observation that your proposal has similarities to the existing jspawnhelper path, so that could possibly be utilized. This patch only *increases* our possible future choices; it does not impose any restrictions. -- - DML From thomas.stuefe at gmail.com Mon Oct 22 19:41:39 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 22 Oct 2018 21:41:39 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: I ran some tests on my local I ran a number of tests on various machines and architectures, all with glibc variants older than 2.24, and straced them, and they all used vfork() internally. That made me curious, and I dug into the glibc sources and examined the history. If I understand this correctly: 1) before glibc 2.4, posix_spawn() used just fork() 2) between glibc 2.4 and glibc 2.23, posix_spawn uses either fork() and vfork(), as still described in the manpage today. The relevant coding (sysdeps/posix/spawni.c) looks like this: 93 /* Do this once. */ 94 short int flags = attrp == NULL ? 0 : attrp->__flags; 95 96 /* Generate the new process. */ 97 if ((flags & POSIX_SPAWN_USEVFORK) != 0 98 /* If no major work is done, allow using vfork. Note that we 99 might perform the path searching. But this would be done by 100 a call to execvp(), too, and such a call must be OK according 101 to POSIX. */ 102 || ((flags & (POSIX_SPAWN_SETSIGMASK | POSIX_SPAWN_SETSIGDEF 103 | POSIX_SPAWN_SETSCHEDPARAM | POSIX_SPAWN_SETSCHEDULER 104 | POSIX_SPAWN_SETPGROUP | POSIX_SPAWN_RESETIDS)) == 0 105 && file_actions == NULL)) 106 new_pid = __vfork (); 107 else 108 new_pid = __fork (); 109 1 So, for our use case this means it always uses vfork() since we do not pass attributes nor actions, as David said before. We do not have to since we run the jspawnhelper which does all that for us at the expense of a second exec() call. This looks okay for me. 3) and since 2.24 we use the new linux variant in sysdeps/unix/sysv/linux/spawni.c 365 new_pid = CLONE (__spawni_child, STACK (stack, stack_size), stack_size, 366 CLONE_VM | CLONE_VFORK | SIGCHLD, &args); which is okay for me too. In fact this is better since the child process runs on its own stack before the exec(). --- Okay, seeing that (2) and (3) look fine and (1) only affects glibc versions older than 2.4, which came out in 2006, I admit this is okay and I worry too much. So I'll be quiet now :) Best Regards, Thomas Ubuntu 16.4 and various machines at work, with varying glibc versions as old as On Fri, Oct 19, 2018 at 8:55 AM Thomas St?fe wrote: > > Hi David, > > (for convenience, here the old thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055333.html) > > I would rather not expose a third way to spawn to the end user. As a > test switch for developers, this seems fine. > > AFAIK (and someone please correct me if I am wrong) posix_spawn is not > the magical third way beside fork and vfork, it is just a wrapper > around fork/vfork and exec. Especially posix_spawn(), if using fork(), > will still have the same pitfalls raw fork() has - quasi-random ENOMEM > if we hit the overcommit heuristic, and inferior performance compared > to vfork. So you have nothing gained, you have just relegated the > fork/vfork decision down to a different layer, one which you have > little control over. And since that fork/vfork decision is kind of > important, you need that contol. > > Note that glibc has a flag to force always vfork behavior: > POSIX_SPAWN_USEVFORK. The question is, how tight do we bind us to > GNU-only features, since we may run on linux with a different libc, > e.g. on Alpine we use muslc. > > My proposal, vfork() + the exec-twice-trick, is IMHO the best way to > go. That exec-twice trick takes the sting away from vfork. After > Martin made supportive noises in the other mail thread, I have planned > in some time later this year to produce a patch for this. > > -- > > However: I just realized that my proposal (vfork() + exec-twice-trick) > is very close, implementation wise, to the (posix_spawn() + > POSIX_SPAWN_USEVFORK + jspawnhelper). The jspawnhelper already > implements the exec-twice trick, if only for different reasons than to > get away from vfork dangers. Advantage of this implementation would be > that very little code would have to change. Disadvantage, in my eyes, > is that we bind us to glibc, and an aesthetic side: calling an OS API > but needing it to work in one specific way feels like programming with > mechanical gloves... > > Thanks & Best Regards, Thomas > > (Copying Martin, I'm curious what he thinks) > > -- > > On Thu, Oct 18, 2018 at 11:43 PM David Lloyd wrote: > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > launching on Linux, but it's the closest I could find out of what are > > really a surprisingly large number of issues that refer to posix_spawn > > in one way or another relating to ProcessImpl. There's a different > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > if that one was quite right to hang this off of. Maybe it should be > > yet another issue of its own. > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > : vfork() concerns and a fix proposal", where it was casually > > mentioned that maybe posix_spawn could become an option on Linux, > > whereafter it could be thoroughly tested by brave individuals and > > eventually maybe become the default on that platform, obsoleting the > > vfork support for good. > > > > The following patch does just that. I've tested it launching a > > multi-process WildFly instance a bunch of times, in conjunction with > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > and nothing exploded so here it is. The usual deal with git patches: > > apply directly through "patch -p1". > > > > commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 > > Author: David M. Lloyd > > Date: Thu Oct 18 15:56:37 2018 -0500 > > > > [JDK-6850720] Enable POSIX_SPAWN as an option for child process > > creation on Linux > > > > diff --git a/make/launcher/Launcher-java.base.gmk > > b/make/launcher/Launcher-java.base.gmk > > index 0ce0287d2be..c28fe42d102 100644 > > --- a/make/launcher/Launcher-java.base.gmk > > +++ b/make/launcher/Launcher-java.base.gmk > > @@ -84,7 +84,7 @@ endif > > > > ################################################################################ > > > > -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) > > +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) > > $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ > > NAME := jspawnhelper, \ > > SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > index 368a4f7380b..959e50dfecd 100644 > > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { > > > > private static enum Platform { > > > > - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > > + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, > > LaunchMechanism.FORK), > > > > BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), > > > > diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > index 533584fdb7a..6869a64f2cc 100644 > > --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > @@ -44,7 +44,7 @@ > > #include > > #include > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > || defined(__linux__) > > #include > > #endif > > > > @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { > > return resultPid; > > } > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > || defined(__linux__) > > static pid_t > > spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char > > *helperpath) { > > pid_t resultPid; > > @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, > > ChildStuff *c, const char *helperpath) > > #endif > > case MODE_FORK: > > return forkChild(c); > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > || defined(__linux__) > > case MODE_POSIX_SPAWN: > > return spawnChild(env, process, c, helperpath); > > #endif From brent.christian at oracle.com Mon Oct 22 19:55:29 2018 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 22 Oct 2018 12:55:29 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> Message-ID: <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> Hi, Brian 562 public void skipNBytes(long n) throws IOException { 563 if (n > 0 && skip(n) != n) { 564 throw new EOFException("End of stream before enough bytes skipped"); 565 } 566 } If an overrided skip() method were to skip < n bytes but not yet be at EOF, which I think the skip() spec allows, then wouldn't skipNBytes() throw an EOFException ? -Brent On 10/16/18 1:52 PM, Brian Burkhalter wrote: > Hi Roger, > > Updated patch: http://cr.openjdk.java.net/~bpb/6516099/webrev.01/ > > Thanks, > > Brian > >> On Oct 16, 2018, at 1:06 PM, Brian Burkhalter wrote: >> >>> On Oct 16, 2018, at 12:53 PM, Roger Riggs > wrote: >>> >>> InputStream.java: >>> >>> 584: Is there really a case where line 585 would throw the exception? >>> >>> skip(n, true) != n >>> >>> With the 2nd argument = true, it will either skip the bytes or throw. >>> I think you can just call: "skip(n, true); >> >> I think you are correct. >> >>> Given subclasses of InputStream that might override skip(n) with a more efficient mechanism >>> would it make sense to implement skipNBytes in terms of skip(n)? >>> As is, it always uses read() to skip the bytes, which might not be as efficient as possible >>> on some streams (for example a very large file) where a seek could be used. >> >> That?s a good point. I had some trepidation about the vague wording of skip(n) in terms of how many bytes it actually reads. >> >>> test/jdk/java/io/InputStream/Skip.java: >>> >>> There is a lot of whitespace in this test, spaces before "," and extra blank lines. >> >> Yes it is rather ugly. I chose to leave it as is for initial clarity intending to clean it up later. >> >>> 97: "possible result" - does that occur in the tests? The "possible" is a bit ambiguous especially given the very narrow test case. It would be useful to include the message from the exception. >> >> Copy-paste garbage. I?ll update it to include the message. > From thomas.stuefe at gmail.com Mon Oct 22 20:01:52 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 22 Oct 2018 22:01:52 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <87efch3iz6.fsf@oldenburg.str.redhat.com> References: <8736sy5ch5.fsf@oldenburg.str.redhat.com> <87efch3iz6.fsf@oldenburg.str.redhat.com> Message-ID: Hi Florian, our mails crossed... I think I am fine now with posix_spawn(), provided we do enough testing. But I'll answer your questions inline. On Mon, Oct 22, 2018 at 9:00 PM Florian Weimer wrote: > > * Thomas St?fe: > > > So far I have not read a single technical reason in this thread why > > vfork needs to be abandoned now - apart from it being obsolete. If you > > read my initial thread from September, you know that I think we have > > understood vfork's shortcomings very well, and that our (SAPs) > > proposed patch shows that they can be dealt with. In our port, our > > vfork+exec*2 is solid since many years, without any issues. > > The main problem for vfork in application code is that you need to *all* > disable signals, even signals used by the implementation. If a signal > handler runs by accident while the vfork is active, memory corruption is > practically guaranteed. The only way to disable the signals is with a > direct system call; sigprocmask/pthread_sigmask do not work. > > Does your implementation do this? I understand. No, admittedly not. But we squeeze the vulnerable time window to the minimal possible: if (vfork() == 0) exec(..); which was a large step forward from the stock Ojdk solution. While not completely bullet proof, I saw not a single instance of an error in all these years (I understand those errors would be very intermittent and difficult to attribute to vfork+signalling, so we may have missed some). > > > The current posix_spawn() implementation was added to glibc with glibc > > 2.24. So, what was the state of posix_spawn() before that version? Is > > it safe to use, does it do the right thing, or will we encounter > > regressions? > > It uses fork by default. It can be told to use vfork, via > POSIX_SPAWN_USEVFORK, but then it is buggy. For generic JDK code, this > seems hardly appropriate. Are you sure about this? The coding I saw in glibc < 2.24 was that it would use vfork if both attributes and file actions were NULL, which should be the case with the OpenJDK and jspawnhelper. fork() would be bad and a reason not to use posix_spawn(). > > > My Ubuntu 16.04 box runs glibc 2.23. Arguably, Ubuntu 16.04 is quite a > > common distro. I have to check our machines at work, but I am very > > sure that our zoo of SLES and RHEL servers do not all run glibc>=2.24, > > especially on the more exotic architectures. > > In glibc, the vfork-based performance does not bring in any new ABIs, so > it is in theory backportable. The main risk is that the vfork > optimization landed in glibc 2.24, and the PID cache was removed in > glibc 2.25. vfork with the PID cache was really iffy, but I would not > recommend to backport the PID cache removal. But Debian 9/stretch uses > glibc 2.24, and I think that shows that the vfork optimization with the > PID cache should be safe enough. (Of course you need to remove the > assert that fires if the vfork does not actually stop the parent process > and is implemented as a fork; the glibc implementation still works, but > with somewhat degraded error checking.) > > How far back would you want to see this changed? Debian jessie and Red > Hat Enterprise Linux 6 would be rather unlikely. If you want to target > those, your only chance is to essentially duplicate the glibc > implementation in OpenJDK. As I wrote before, if I understand the coding in glibc between 2.4 and 2.24 correctly, I think it uses vfork() and that should be fine by me: posix_spawn() using vfork(), with no attributes/file actions and in conjunction with the jspawnhelper, is almost exactly the same as the proposed vfork() + exec*2 patch: posix_spawn() will exec() immediately after the vfork(), then, in jspwnhelper, we set up the new process and exec() again. So I am fine with that. Provided I have understood all that stuff correctly and not made a thinking error somewhere. Cheers, Thomas > > Thanks, > Florian From thomas.stuefe at gmail.com Mon Oct 22 20:14:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 22 Oct 2018 22:14:12 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <8736sy5ch5.fsf@oldenburg.str.redhat.com> Message-ID: Hi David, On Mon, Oct 22, 2018 at 9:00 PM David Lloyd wrote: > > On Mon, Oct 22, 2018 at 1:23 PM Thomas St?fe wrote: > > Hi all, > [...] > > So far I have not read a single technical reason in this thread why > > vfork needs to be abandoned now > > Note that my patch does not abandon vfork. It does not even change > the default exec strategy away from vfork, nor does it cause any > obstacle to your proposed change. It only adds the ability for users > to opt in to the existing posix_spawn implementation on Linux. It's > just a first step, in whatever direction we might be going, which is > far from decided. As you and Martin have both implied, it's a good > idea to be very cautious in this area. > > > The current posix_spawn() implementation was added to glibc with glibc 2.24. So, what was the state of posix_spawn() before that version? Is it safe to use, does it do the right thing, or will we encounter regressions? > > I certainly have not suggested making posix_spawn be the default on > Linux at this time. But if we don't make it at least a possible > option, it cannot be tested *at all*, by anyone, unless they're > adventurous enough to hack OpenJDK themselves. The questions you ask > can not be answered without at least making it a choice. > > There are many reasonable paths that can be taken after this patch is > merged (if it is): > > ? It could stop here and keep the status quo; users who have trouble > with the current implementation can try out posix_spawn > ? The Linux port could be modified similarly to your proposal to use > the existing jspawnhelper infrastructure with vfork on Linux, while > still allowing posix_spawn to be manually selected > ? The Linux port could be modified to use posix_spawn if > gnu_get_libc_version(3) and/or other run-time probes return an > acceptable value, using vfork (either the original or your modified > approach) otherwise, still allowing posix_spawn to be manually > selected > > Other possibilities exist as well. Nothing in this email thread > (AFAICT) invalidates your basic proposal, other than perhaps the > observation that your proposal has similarities to the existing > jspawnhelper path, so that could possibly be utilized. This patch > only *increases* our possible future choices; it does not impose any > restrictions. > I understand. Sorry for being stubborn. I have spent so much time debugging Runtime.exec() problems in the past that I am very paranoid about changes. Bugs in the Runtime.exec() layer tend to be so very hard to analyze. That said, as I wrote in my earlier mail, I think using posix_spawn() may be fine. If I understand the glibc coding correctly, we are good down to glibc 2.4, which is quite old. This will also save me a lot of work, since upstreaming our patch would have been a real pain. It is tightly interwoven with other proprietary components and would have effectively been a rewrite. So I think yes, your patch is fine. Lets get it in and test it. Best Regards, Thomas > -- > - DML From jonathan.gibbons at oracle.com Mon Oct 22 20:26:15 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 22 Oct 2018 13:26:15 -0700 Subject: RFR[S]: JDK-8211876,,Broken links in java.base files (ClassLoader.html#name) Message-ID: <33339b2f-38e6-537a-adbc-42aefad390f1@oracle.com> Please review a small fix to a couple of classes in java.base to fix a number of broken links in the API documentation. In 3 places, the anchor |ClassLoader.html#name| is updated to |ClassLoader.html#binary-name|. JBS: https://bugs.openjdk.java.net/browse/JDK-8211876 Webrev: http://cr.openjdk.java.net/~jjg/8211876/webrev.00/ ? Jon The patch is small enough to also include here: |--- old/src/java.base/share/classes/java/lang/Class.java 2018-10-22 13:11:51.810081861 -0700 +++ new/src/java.base/share/classes/java/lang/Class.java 2018-10-22 13:11:51.522081849 -0700 @@ -405,7 +405,7 @@ /** - * Returns the {@code Class} with the given + * Returns the {@code Class} with the given * binary name in the given module. * *

    This method attempts to locate, load, and link the class or interface. @@ -427,7 +427,7 @@ * loads a class in another module. * * @param module A module - * @param name The binary name + * @param name The binary name * of the class * @return {@code Class} object of the given name defined in the given module; * {@code null} if not found. --- old/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 13:11:52.662081896 -0700 +++ new/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 13:11:52.306081882 -0700 @@ -100,7 +100,7 @@ */ public interface StackFrame { /** - * Gets the binary name + * Gets the binary name * of the declaring class of the method represented by this stack frame. * * @return the binary name of the declaring class of the method | ? From lance.andersen at oracle.com Mon Oct 22 20:28:20 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 22 Oct 2018 16:28:20 -0400 Subject: RFR[S]: JDK-8211876,,Broken links in java.base files (ClassLoader.html#name) In-Reply-To: <33339b2f-38e6-537a-adbc-42aefad390f1@oracle.com> References: <33339b2f-38e6-537a-adbc-42aefad390f1@oracle.com> Message-ID: <81875FBE-E095-4418-848D-B6EF32D8491B@oracle.com> +1 > On Oct 22, 2018, at 4:26 PM, Jonathan Gibbons wrote: > > Please review a small fix to a couple of classes in java.base to fix a number of broken links in the API documentation. In 3 places, the anchor |ClassLoader.html#name| is updated to |ClassLoader.html#binary-name|. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211876 > Webrev: http://cr.openjdk.java.net/~jjg/8211876/webrev.00/ > > ? Jon > > The patch is small enough to also include here: > > |--- old/src/java.base/share/classes/java/lang/Class.java 2018-10-22 13:11:51.810081861 -0700 +++ new/src/java.base/share/classes/java/lang/Class.java 2018-10-22 13:11:51.522081849 -0700 @@ -405,7 +405,7 @@ /** - * Returns the {@code Class} with the given + * Returns the {@code Class} with the given * binary name in the given module. * *

    This method attempts to locate, load, and link the class or interface. @@ -427,7 +427,7 @@ * loads a class in another module. * * @param module A module - * @param name The binary name + * @param name The binary name * of the class * @return {@code Class} object of the given name defined in the given module; * {@code null} if not found. --- old/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 13:11:52.662081896 -0700 +++ new/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 13:11:52.306081882 -0700 @@ -100,7 +100,7 @@ */ public interface StackFrame { /** - * Gets the binary name + * Gets the binary name * of the declaring class of the method represented by this stack frame. * * @return the binary name of the declaring class of the method | > > ? Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jonathan.gibbons at oracle.com Mon Oct 22 20:28:13 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 22 Oct 2018 13:28:13 -0700 Subject: RFR[S]: JDK-8211876,,Broken links in java.base files (ClassLoader.html#name) In-Reply-To: <33339b2f-38e6-537a-adbc-42aefad390f1@oracle.com> References: <33339b2f-38e6-537a-adbc-42aefad390f1@oracle.com> Message-ID: <9dd23a81-9503-8e8f-c102-d98d75c5cb7a@oracle.com> OK, enough with fancy; here's the email again: Please review a small fix to a couple of classes in java.base to fix a number of broken links in the API documentation. In 3 places, the anchor ClassLoader.html#name is updated to ClassLoader.html#binary-name. JBS: https://bugs.openjdk.java.net/browse/JDK-8211876 Webrev: http://cr.openjdk.java.net/~jjg/8211876/webrev.00/ ? Jon The patch is small enough to also include here: --- old/src/java.base/share/classes/java/lang/Class.java 2018-10-22 13:11:51.810081861 -0700 +++ new/src/java.base/share/classes/java/lang/Class.java 2018-10-22 13:11:51.522081849 -0700 @@ -405,7 +405,7 @@ ???? /** -???? * Returns the {@code Class} with the given +???? * Returns the {@code Class} with the given ????? * binary name in the given module. ????? * ????? *

    This method attempts to locate, load, and link the class or interface. @@ -427,7 +427,7 @@ ????? * loads a class in another module. ????? * ????? * @param? module?? A module -???? * @param? name???? The binary name +???? * @param? name???? The binary name ????? *????????????????? of the class ????? * @return {@code Class} object of the given name defined in the given module; ????? *???????? {@code null} if not found. --- old/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 13:11:52.662081896 -0700 +++ new/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 13:11:52.306081882 -0700 @@ -100,7 +100,7 @@ ????? */ ???? public interface StackFrame { ???????? /** -???????? * Gets the binary name +???????? * Gets the binary name ????????? * of the declaring class of the method represented by this stack frame. ????????? * ????????? * @return the binary name of the declaring class of the method ? On 10/22/2018 01:26 PM, Jonathan Gibbons wrote: > Please review a small fix to a couple of classes in java.base to fix a > number of broken links in the API documentation. In 3 places, the > anchor |ClassLoader.html#name| is updated to > |ClassLoader.html#binary-name|. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211876 > Webrev: http://cr.openjdk.java.net/~jjg/8211876/webrev.00/ > > > ? Jon > > The patch is small enough to also include here: > > |--- old/src/java.base/share/classes/java/lang/Class.java 2018-10-22 > 13:11:51.810081861 -0700 +++ > new/src/java.base/share/classes/java/lang/Class.java 2018-10-22 > 13:11:51.522081849 -0700 @@ -405,7 +405,7 @@ /** - * Returns the > {@code Class} with the given + * > Returns the {@code Class} with the given href="ClassLoader.html#binary-name"> * binary name in the given > module. * *

    This method attempts to locate, load, and link the > class or interface. @@ -427,7 +427,7 @@ * loads a class in another > module. * * @param module A module - * @param name The href="ClassLoader.html#name">binary name + * @param name The href="ClassLoader.html#binary-name">binary name * of the class * > @return {@code Class} object of the given name defined in the given > module; * {@code null} if not found. --- > old/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 > 13:11:52.662081896 -0700 +++ > new/src/java.base/share/classes/java/lang/StackWalker.java 2018-10-22 > 13:11:52.306081882 -0700 @@ -100,7 +100,7 @@ */ public interface > StackFrame { /** - * Gets the binary > name + * Gets the binary > name * of the declaring class of the method represented by this > stack frame. * * @return the binary name of the declaring class of the > method | > > ? From mandy.chung at oracle.com Mon Oct 22 21:01:27 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Oct 2018 14:01:27 -0700 Subject: RFR[S]: JDK-8211876,,Broken links in java.base files (ClassLoader.html#name) In-Reply-To: <9dd23a81-9503-8e8f-c102-d98d75c5cb7a@oracle.com> References: <33339b2f-38e6-537a-adbc-42aefad390f1@oracle.com> <9dd23a81-9503-8e8f-c102-d98d75c5cb7a@oracle.com> Message-ID: Looks good. Thanks for fixing it. Mandy On 10/22/18 1:28 PM, Jonathan Gibbons wrote: > OK, enough with fancy; here's the email again: > > Please review a small fix to a couple of classes in java.base to fix a > number of broken links in the API documentation. In 3 places, the > anchor ClassLoader.html#name is updated to ClassLoader.html#binary-name. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8211876 > Webrev: http://cr.openjdk.java.net/~jjg/8211876/webrev.00/ > > ? Jon > > The patch is small enough to also include here: > > --- old/src/java.base/share/classes/java/lang/Class.java 2018-10-22 > 13:11:51.810081861 -0700 > +++ new/src/java.base/share/classes/java/lang/Class.java 2018-10-22 > 13:11:51.522081849 -0700 > @@ -405,7 +405,7 @@ > > > ???? /** > -???? * Returns the {@code Class} with the given href="ClassLoader.html#name"> > +???? * Returns the {@code Class} with the given href="ClassLoader.html#binary-name"> > ????? * binary name in the given module. > ????? * > ????? *

    This method attempts to locate, load, and link the class > or interface. > @@ -427,7 +427,7 @@ > ????? * loads a class in another module. > ????? * > ????? * @param? module?? A module > -???? * @param? name???? The binary > name > +???? * @param? name???? The href="ClassLoader.html#binary-name">binary name > ????? *????????????????? of the class > ????? * @return {@code Class} object of the given name defined in the > given module; > ????? *???????? {@code null} if not found. > --- old/src/java.base/share/classes/java/lang/StackWalker.java > 2018-10-22 13:11:52.662081896 -0700 > +++ new/src/java.base/share/classes/java/lang/StackWalker.java > 2018-10-22 13:11:52.306081882 -0700 > @@ -100,7 +100,7 @@ > ????? */ > ???? public interface StackFrame { > ???????? /** > -???????? * Gets the binary name > +???????? * Gets the binary > name > ????????? * of the declaring class of the method represented by this > stack frame. > ????????? * > ????????? * @return the binary name of the declaring class of the method > > ? From philipp.kunz at paratix.ch Mon Oct 22 21:57:03 2018 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 22 Oct 2018 23:57:03 +0200 Subject: Review Request: 6202130: java.util.jar.Attributes.writeMain() can't handle multi-byte chars In-Reply-To: References: <5AEAB2A3.2050602@oracle.com> <1537938483.2077.4.camel@paratix.ch> <1538592945.2782.4.camel@paratix.ch> <5BB51D1A.2000600@oracle.com> <1538683131.2782.10.camel@paratix.ch> <1539937663.2291.3.camel@paratix.ch> Message-ID: <1540245423.2343.2.camel@paratix.ch> Please find another revised and updated patch attached. On Sun, 2018-10-21 at 15:10 -0700, Martin Buchholz wrote: > I only took a quick look. > Looks good, but here's a nitpick - capitalize javadoc that begins > with "returns" > On Fri, Oct 19, 2018 at 1:27 AM, Philipp Kunz h> wrote: > > Hi Martin and everyone, > > > > > > > > You were absolutely right to object "utf". > > > > Please find a revised and updated patch attached. > > > > > > > > Regards, > > > > Philipp > > > > > > > > > > > > > > > > On Thu, 2018-10-04 at 15:24 -0700, Martin Buchholz wrote: > > > > > "utf8" is a thing.??"utf" is not. > > > > >? > > > > > On Thu, Oct 4, 2018 at 12:58 PM, Philipp Kunz > ix.c > > > > > h> wrote: > > > > > > Thanks to Sherman's hint, I revised the test to use the terms > > > > > > unicode > > > > > > character and utf encoding consistently and not utf character. > > > > > > Affects > > > > > > only the test, mostly in comments and a few identifiers. > > > > > >? > > > > > > Philipp > > > > > >? > > > > > >? > > > > > > On Wed, 2018-10-03 at 12:48 -0700, Xueming Shen wrote: > > > > > > > +1 > > > > > > >? > > > > > > > only nit is it might be preferred to use "utf8" directly in > > the > > > > > > > test > > > > > > > instead of current "utf" > > > > > > >? > > > > > > > -sherman > > > > > > >? > > > > > > > On 10/03/2018 11:55 AM, Philipp Kunz wrote: > > > > > > > > In short, bug 6202130 is about removal of comments in > > > > > > > > Attributes > > > > > > > > like > > > > > > > >? > > > > > > > > > XXX Need to handle UTF8 values and break up lines longer > > than > > > > > > > > > 72 > > > > > > > >? > > > > > > > > The patch here contains a test that shows that utf > > characters > > > > > > > > are > > > > > > > > handled correctly, which has been the case before. Breaking > > > > > > > > lines > > > > > > > > has > > > > > > > > also been working before. > > > > > > > >? > > > > > > > > In the main code, the patch only removes a few comments and > > > > > > > > does > > > > > > > > not > > > > > > > > change actual code. It all has been working before and now > > we > > > > > > > > know. > > > > > > > >? > > > > > > > > Philipp > > > > > > > >? > > > > > > > >? > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-6202130 > > > > > > > >? > > > > > > > >? > > > > > > > >? > > > > > > > >? > > > > > > > > On Wed, 2018-09-26 at 07:08 +0200, Philipp Kunz wrote: > > > > > > > > > Hi, > > > > > > > > >? > > > > > > > > > There are some comments in the source code like this: > > > > > > > > >? > > > > > > > > > ? >??XXX Need to handle UTF8 values and break up lines > > longer > > > > > > > > > than 72 bytes > > > > > > > > >? > > > > > > > > > in Attributes.java on lines 299, 327, and 370. Bug > > 6202130 > > > > > > > > > also > > > > > > > > > suggests > > > > > > > > > to add a test to show that the character set is fully > > > > > > > > > supported > > > > > > > > > before > > > > > > > > > actually removing those comments. > > > > > > > > >? > > > > > > > > > Hence, I added such a test, see ValueUtfEncoding in > > attached > > > > > > > > > patch, and > > > > > > > > > it finds the complete utf character set supported > > correctly > > > > > > > > > and > > > > > > > > > that it > > > > > > > > > has been so already before. > > > > > > > > >? > > > > > > > > > The comments in Attributes also say that lines longer > > than 72 > > > > > > > > > bytes need > > > > > > > > > to be broken. That is a different issue and has been > > already > > > > > > > > > addressed > > > > > > > > > and solved in bug 6372077 and is now tested in > > > > > > > > > LineBreakLineWidth > > > > > > > > > and > > > > > > > > > therefore, that line break part of the comment is > > obsolete > > > > > > > > > now as > > > > > > > > > well > > > > > > > > > with the exception of version headers ("Manifest-Version" > > or > > > > > > > > > "Signature-Version") at least when taking strictly. > > > > > > > > >? > > > > > > > > > Version headers are not subject of bug 6202130 for which > > my > > > > > > > > > patch > > > > > > > > > intends to provide a fix and if only because multi-byte > > > > > > > > > characters are > > > > > > > > > not allowed in version headers and wasn't subject of > > 6372077 > > > > > > > > > either > > > > > > > > > which was about too short lines rather than too long > > ones. If > > > > > > > > > I > > > > > > > > > would > > > > > > > > > change only the minimum I could argue was safe, there > > would > > > > > > > > > have > > > > > > > > > to > > > > > > > > > remain a comment in Attributes.java on line 327 like > > > > > > > > >? > > > > > > > > > ? >??XXX Need to handle version headers longer than 72 > > bytes > > > > > > > > >? > > > > > > > > > but I guess that should probably better be represented as > > > > > > > > > another > > > > > > > > > bug > > > > > > > > > rather than this style of comment if at all desired. > > There > > > > > > > > > are > > > > > > > > > some bugs > > > > > > > > > concerning version headers and particularly the behavior > > of > > > > > > > > > the > > > > > > > > > manifests in their absence, among possibly others, > > 6910466, > > > > > > > > > 4935610, > > > > > > > > > 4271239, 8196371 and 4256580 which have some relation but > > I > > > > > > > > > haven't > > > > > > > > > found one that really fits the 72 byte line length limit > > of > > > > > > > > > version > > > > > > > > > headers. Whether such a bug is created or found or not, > > it > > > > > > > > > does > > > > > > > > > not > > > > > > > > > directly relate to the one I'm trying to fix here, > > 6202130. > > > > > > > > >? > > > > > > > > > If also the test is good I would assume that the comments > > can > > > > > > > > > be > > > > > > > > > removed now without actually changing the Manifest and > > > > > > > > > Attributes > > > > > > > > > implementation. > > > > > > > > >? > > > > > > > > > Regards, > > > > > > > > > Philipp > > -------------- next part -------------- A non-text attachment was scrubbed... Name: 6202130.patch Type: text/x-patch Size: 10021 bytes Desc: not available URL: From scolebourne at joda.org Mon Oct 22 22:25:44 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 22 Oct 2018 23:25:44 +0100 Subject: Time-zone database issues Message-ID: The IANA time-zone database [1] provides details of how time-zones change over time. The latest release - 2018f - cannot be processed successfully by the current JDK parser [2]. A workaround exists however unlike previous cases of tzdb incompatibility, this time it makes sense for the JDK parser and API to be changed. Problem ----------- The JDK parser and API make the assumption that a time-zone change can occur at any LocalTime or midnight-end-of-day, ie. from 00:00 to 24:00. Unfortunately, the tzdb source files allow (and now include) rules outside those valid values, in this case a value of 25:00. Specifically, the rule that causes problems says that clocks change at 25:00 on the first Saturday on or after the 8th of September. In the current problematic case, the rule can be rewritten to say that clocks change at 01:00 on the first Sunday on or after the 9th of September. However, there are cases where it is difficult to impossible to rewrite the rule (such as 25:00 on the last Saturday in a month, difficult because it goes into the next month). Proposed solution ------------------------ Fixing the parser to handle values like 25:00 would be relatively easy. However, these rules are also exposed in the public API of java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need to be deprecated and replaced by a new method `getLocalTimeDuration()` (or some other name) that returns an instance of `Duration`. A user of ThreeTen-Backport [4] has provided a branch to do this, so I know the change to be possible. However, since I have looked at the code I cannot implement the change in OpenJDK (compromised IP). It needs a cleanroom implementation by someone else. Is there agreement on the need for change? Is anyone (Oracle or otherwise) willing to volunteer do the work? thanks Stephen [1] https://www.iana.org/time-zones [2] https://bugs.openjdk.java.net/browse/JDK-8212684 [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/zone/ZoneOffsetTransitionRule.html [4] https://www.threeten.org/threetenbp/ From amy.lu at oracle.com Tue Oct 23 03:44:55 2018 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 23 Oct 2018 11:44:55 +0800 Subject: [12] RFR of JDK-8210908: Refactor java/util/prefs/PrefsSpi.sh to plain java test Message-ID: <853fad1b-bcef-1f5d-ca2c-0cc8a2558f04@oracle.com> java/util/prefs/PrefsSpi.sh Please review this patch to refactor above shell script test to java. bug: https://bugs.openjdk.java.net/browse/JDK-8210908 webrev: http://cr.openjdk.java.net/~amlu/8210908/webrev.00/ Thanks, Amy From amy.lu at oracle.com Tue Oct 23 03:46:30 2018 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 23 Oct 2018 11:46:30 +0800 Subject: [12] RFR of JDK-8209768: Refactor java/util/prefs/CheckUserPrefsStorage.sh to plain java test In-Reply-To: <9c7dab1b-9ffc-2187-08b1-b30e958bae84@oracle.com> References: <9c7dab1b-9ffc-2187-08b1-b30e958bae84@oracle.com> Message-ID: Please review. Thanks, Amy On 2018/10/11 4:47 PM, Amy Lu wrote: > java/util/prefs/CheckUserPrefsStorage.sh > > Please review this patch to refactor above shell script test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8209768 > webrev: http://cr.openjdk.java.net/~amlu/8209768/webrev.00/ > > Thanks, > Amy From kishor.gollapalliwar at gmail.com Tue Oct 23 04:31:37 2018 From: kishor.gollapalliwar at gmail.com (Kishor Gollapalliwar) Date: Tue, 23 Oct 2018 10:01:37 +0530 Subject: [PATCH] improve javadoc in TreeSet#add api documentation In-Reply-To: References: Message-ID: Hello Martin and Everyone, @Martin : Thank you for the response. I have attached the PATCH file to this email. Request you to sponsor this change. Please find file extract in case my attachment stripped out. diff -r ebe635565ff3 src/share/classes/java/util/TreeSet.java --- a/src/share/classes/java/util/TreeSet.java Fri Oct 19 10:30:26 2018 -0700 +++ b/src/share/classes/java/util/TreeSet.java Tue Oct 23 09:44:44 2018 +0530 @@ -235,14 +235,19 @@ } /** - * Adds the specified element to this set if it is not already present. - * More formally, adds the specified element {@code e} to this set if - * the set contains no element {@code e2} such that - * (e==null ? e2==null : e.equals(e2)). - * If this set already contains the element, the call leaves the set - * unchanged and returns {@code false}. + * Adds the specified {@code newElement} to this set, if and only if following conditions are met. + *

      + *
    1. The {@code newElement} is NOT {@code null} (unless, {@link Comparator} + * which supports/permits {@code null} comparison was provided at set creation time.
      2. + *
    2. AND there is no {@code setElement}, such that {@code newElement.compareTo(setElement)==0} + * ({@link Comparator#compare} {@code (newElement, setElement)==0}, + * in case {@link Comparator} was provided at set creation time.)
      3. + *
    + * + *

    If any of above conditions are NOT met, it will be interpreted as + * set already contains the element, hence call leaves the set unchanged and returns {@code false}.

    * - * @param e element to be added to this set + * @param newElement, the element to be added to this set * @return {@code true} if this set did not already contain the specified * element * @throws ClassCastException if the specified object cannot be compared @@ -251,8 +256,8 @@ * and this set uses natural ordering, or its comparator * does not permit null elements */ - public boolean add(E e) { - return m.put(e, PRESENT)==null; + public boolean add(E newElement) { + return m.put(newElement, PRESENT)==null; } /** Please revert in case of any queries. Thanks & Regards, *Kishor Golapelliwar,* The ability to convert ideas to things is the secret to outward success. On Mon, Oct 22, 2018 at 6:07 AM Martin Buchholz wrote: > Hi Kishor, > > I think your attachment was stripped out - standard policy for this > mailing list, I think. > For a small patch like this, you should just include the patch inline in > text form. > > > On Thu, Oct 18, 2018 at 2:21 AM, Kishor Gollapalliwar < > kishor.gollapalliwar at gmail.com> wrote: > >> Hi Team, >> >> Please provide your approval to update TreeSet#add method as it's >> documentation and behavior are not consistent. >> >> For more information, please refer my mail below and attachment. >> >> Thanks & Regards, >> *Kishor Golapelliwar,* >> The ability to convert ideas to things is the secret to outward success. >> >> ---------- Forwarded message --------- >> From: Kishor Gollapalliwar >> Date: Mon, Oct 15, 2018 at 11:40 AM >> Subject: Re: Inconsistencies in TreeSet Interface >> To: >> Cc: >> >> >> Hello Everyone, >> >> This is the first time I am writing mail to this group, hence please >> ignore >> my nuisance and guide me towards right direction. >> >> As suggested by Martin, I believe documentation need to be updated. >> I would happy to update the documentation, please provide your inputs. >> I have attache the .java file for more details. >> >> @Martin : I really appreciate your advice and help, thank you. >> >> Thank you, >> Kishor Gollapalliwar >> >> On Sat, Oct 13, 2018 at 11:40 PM Martin Buchholz >> wrote: >> >> > core-libs-dev is the right mailing list. >> > >> > The documentation could be improved, but it's nuanced - consider using a >> > TreeSet with a Comparator that accepts null. >> > >> > On Sat, Oct 13, 2018 at 7:26 AM, Kishor Gollapalliwar < >> > kishor.gollapalliwar at gmail.com> wrote: >> > >> >> Hello Everyone, >> >> >> >> Introduction : I?m an enthusiast java developer. I?m a newbie in this >> >> group, hence please ignore my nuisance and guide me towards right >> >> direction. >> >> >> >> ## Problems Statement >> >> >> >> Treeset#add method documentations : ?adds the specified element e to >> this >> >> set if the set contains no element e2 such that (e==null ? e2==null : >> >> e.equals(e2))? >> >> >> >> Inconsistencies: >> >> >> >> > If we try to add ?null? value, it will throws NullPointerException, >> >> hence >> >> > e and e2 can not be null. >> >> >> >> >> >> >> >> > And e.compareTo(e2) ==0 || compare(e, e2)==0, it will not add to >> >> > collection. >> >> >> >> >> >> Request you to help me understand if behavior of Treeset#add method is >> as >> >> expected, and differ with set interface documentation. We may have to >> >> consider to update method documentations, if behavior is expected. >> >> >> >> For more details I have attached the sample java application. >> >> >> >> I?ve tested the behavior on Orack JDK 8u181 (64 bit) and Open JDK >> 8u181. >> >> >> >> Thanks & Regards, >> >> *Kishor Golapelliwar,* >> >> The ability to convert ideas to things is the secret to outward >> success. >> >> >> > >> > >> > > From weijun.wang at oracle.com Tue Oct 23 05:24:40 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 23 Oct 2018 13:24:40 +0800 Subject: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 In-Reply-To: <1427462186.14360.1539239241513.JavaMail.zimbra@u-pem.fr> References: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com> <1427462186.14360.1539239241513.JavaMail.zimbra@u-pem.fr> Message-ID: <4D0B5C43-ABAB-40CB-A622-52B8A208572A@oracle.com> +1. Thanks Max > On Oct 11, 2018, at 2:27 PM, Remi Forax wrote: > > Looks good ! > > R?mi > > ----- Mail original ----- >> De: "Amy Lu" >> ?: "core-libs-dev" >> Envoy?: Jeudi 11 Octobre 2018 08:13:44 >> Objet: Re: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 > >> Ping ~ >> >> It's no longer running this test in a separate job as test OOM issue >> (JDK-8199265) fixed. >> >> Thanks, >> Amy >> >> On 2018/9/4 5:46 PM, Amy Lu wrote: >>> test/jdk/java/util/Arrays/TimSortStackSize2.java >>> >>> This test was demoted to tier2 due to JDK-8199265 (test fails with >>> OOM). This issue has been fixed (in jdk-11+20) and test has been run >>> (in tier2) without failure happening after that. >>> >>> Let's move it back to tier1. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210353 >>> webrev: http://cr.openjdk.java.net/~amlu/8210353/webrev.00/ >>> >>> Thanks, >>> Amy >>> >>> diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups >>> --- a/test/jdk/TEST.groups >>> +++ b/test/jdk/TEST.groups >>> @@ -35,8 +35,7 @@ >>> :jdk_lang >>> >>> tier1_part2 = \ >>> - :jdk_util \ >>> - -java/util/Arrays/TimSortStackSize2.java >>> + :jdk_util >>> >>> tier1_part3 = \ >>> :jdk_math \ >>> @@ -67,9 +66,7 @@ >>> -sun/nio/cs/ISO8859x.java \ >>> :jdk_other \ >>> :jdk_text \ >>> - :jdk_time \ >>> - java/util/Arrays/TimSortStackSize2.java >>> - >>> + :jdk_time >>> >>> tier2_part3 = \ >>> :jdk_net >>> diff --git a/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> b/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java >>> @@ -25,7 +25,6 @@ >>> * @test >>> * @bug 8072909 >>> * @summary Test TimSort stack size on big arrays >>> - * @key intermittent >>> * @library /lib/testlibrary /test/lib >>> * @modules java.management >>> * java.base/jdk.internal From fweimer at redhat.com Tue Oct 23 05:45:22 2018 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 23 Oct 2018 07:45:22 +0200 Subject: Time-zone database issues In-Reply-To: (Stephen Colebourne's message of "Mon, 22 Oct 2018 23:25:44 +0100") References: Message-ID: <87r2ghz05p.fsf@oldenburg.str.redhat.com> * Stephen Colebourne: > Fixing the parser to handle values like 25:00 would be relatively > easy. However, these rules are also exposed in the public API of > java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has > methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need > to be deprecated and replaced by a new method `getLocalTimeDuration()` > (or some other name) that returns an instance of `Duration`. I think getLocalTimeDuration() would have to be paired with new methods getDayOfMonthIndicator(), getDayOfWeek(). The values returned by these methods will have to change between normalized and non-normalized transition times. The branch appears to be here: Thanks, Florian From amy.lu at oracle.com Tue Oct 23 06:04:06 2018 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 23 Oct 2018 14:04:06 +0800 Subject: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 In-Reply-To: <4D0B5C43-ABAB-40CB-A622-52B8A208572A@oracle.com> References: <02ce3f4e-3ee3-d580-df7c-4b096fde906b@oracle.com> <1427462186.14360.1539239241513.JavaMail.zimbra@u-pem.fr> <4D0B5C43-ABAB-40CB-A622-52B8A208572A@oracle.com> Message-ID: <3c2c01be-05cf-d301-0171-0a1cabd69b03@oracle.com> Thank you for reviewing! Change now pushed. Thanks, Amy On 2018/10/23 1:24 PM, Weijun Wang wrote: > +1. > > Thanks > Max > >> On Oct 11, 2018, at 2:27 PM, Remi Forax wrote: >> >> Looks good ! >> >> R?mi >> >> ----- Mail original ----- >>> De: "Amy Lu" >>> ?: "core-libs-dev" >>> Envoy?: Jeudi 11 Octobre 2018 08:13:44 >>> Objet: Re: [12] RFR of JDK-8210353: Move java/util/Arrays/TimSortStackSize2.java back to tier1 >>> Ping ~ >>> >>> It's no longer running this test in a separate job as test OOM issue >>> (JDK-8199265) fixed. >>> >>> Thanks, >>> Amy >>> >>> On 2018/9/4 5:46 PM, Amy Lu wrote: >>>> test/jdk/java/util/Arrays/TimSortStackSize2.java >>>> >>>> This test was demoted to tier2 due to JDK-8199265 (test fails with >>>> OOM). This issue has been fixed (in jdk-11+20) and test has been run >>>> (in tier2) without failure happening after that. >>>> >>>> Let's move it back to tier1. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210353 >>>> webrev: http://cr.openjdk.java.net/~amlu/8210353/webrev.00/ >>>> >>>> Thanks, >>>> Amy >>>> >>>> diff --git a/test/jdk/TEST.groups b/test/jdk/TEST.groups >>>> --- a/test/jdk/TEST.groups >>>> +++ b/test/jdk/TEST.groups >>>> @@ -35,8 +35,7 @@ >>>> :jdk_lang >>>> >>>> tier1_part2 = \ >>>> - :jdk_util \ >>>> - -java/util/Arrays/TimSortStackSize2.java >>>> + :jdk_util >>>> >>>> tier1_part3 = \ >>>> :jdk_math \ >>>> @@ -67,9 +66,7 @@ >>>> -sun/nio/cs/ISO8859x.java \ >>>> :jdk_other \ >>>> :jdk_text \ >>>> - :jdk_time \ >>>> - java/util/Arrays/TimSortStackSize2.java >>>> - >>>> + :jdk_time >>>> >>>> tier2_part3 = \ >>>> :jdk_net >>>> diff --git a/test/jdk/java/util/Arrays/TimSortStackSize2.java >>>> b/test/jdk/java/util/Arrays/TimSortStackSize2.java >>>> --- a/test/jdk/java/util/Arrays/TimSortStackSize2.java >>>> +++ b/test/jdk/java/util/Arrays/TimSortStackSize2.java >>>> @@ -25,7 +25,6 @@ >>>> * @test >>>> * @bug 8072909 >>>> * @summary Test TimSort stack size on big arrays >>>> - * @key intermittent >>>> * @library /lib/testlibrary /test/lib >>>> * @modules java.management >>>> * java.base/jdk.internal From ying.z.zhou at oracle.com Tue Oct 23 06:16:06 2018 From: ying.z.zhou at oracle.com (Ying Zhou) Date: Tue, 23 Oct 2018 14:16:06 +0800 Subject: [12]RFR of JDK-8210407:Refactor java.util.Calendar:i18n shell tests to plain java tests Message-ID: Hello, test/java/util/Calendar/SupplementalJapaneseEraTest.sh test/java/util/Calendar/GenericTimeZoneNamesTest.sh test/java/util/Calendar/NarrowNamesTest.sh Please review this patch to refactor above shell script tests to java. Bug: https://bugs.openjdk.java.net/browse/JDK-8210407 Webrev: http://cr.openjdk.java.net/~dzhou/8210407/webrev.00/ Thanks, Daisy From scolebourne at joda.org Tue Oct 23 08:40:10 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 23 Oct 2018 09:40:10 +0100 Subject: Time-zone database issues In-Reply-To: <87r2ghz05p.fsf@oldenburg.str.redhat.com> References: <87r2ghz05p.fsf@oldenburg.str.redhat.com> Message-ID: No, the day-of-month and day-of-week would remain the same, as the time is relative to those dates. I didn't provide that link for IP reasons! Please avoid clicking on the link below! Stephen On Tue, 23 Oct 2018 at 06:45, Florian Weimer wrote: > > * Stephen Colebourne: > > > Fixing the parser to handle values like 25:00 would be relatively > > easy. However, these rules are also exposed in the public API of > > java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has > > methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need > > to be deprecated and replaced by a new method `getLocalTimeDuration()` > > (or some other name) that returns an instance of `Duration`. > > I think getLocalTimeDuration() would have to be paired with new methods > getDayOfMonthIndicator(), getDayOfWeek(). The values returned by these > methods will have to change between normalized and non-normalized > transition times. > > The branch appears to be here: > > > > Thanks, > Florian From fweimer at redhat.com Tue Oct 23 08:44:43 2018 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 23 Oct 2018 10:44:43 +0200 Subject: Time-zone database issues In-Reply-To: (Stephen Colebourne's message of "Tue, 23 Oct 2018 09:40:10 +0100") References: <87r2ghz05p.fsf@oldenburg.str.redhat.com> Message-ID: <87o9blxdac.fsf@oldenburg.str.redhat.com> * Stephen Colebourne: > No, the day-of-month and day-of-week would remain the same, as the > time is relative to those dates. My expectation is that the values returned by the other methods would change for a getLocalTime() that provides a normalized return value because the transition rule in normalized time is different (i.e., last Saturday in a month turns into something else). Thanks, Florian From fweimer at redhat.com Tue Oct 23 09:39:49 2018 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 23 Oct 2018 11:39:49 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: ("Thomas \=\?utf-8\?Q\?St\=C3\=BCfe\=22's\?\= message of "Mon, 22 Oct 2018 22:01:52 +0200") References: <8736sy5ch5.fsf@oldenburg.str.redhat.com> <87efch3iz6.fsf@oldenburg.str.redhat.com> Message-ID: <87k1m9vw62.fsf@oldenburg.str.redhat.com> * Thomas St?fe: >> The main problem for vfork in application code is that you need to *all* >> disable signals, even signals used by the implementation. If a signal >> handler runs by accident while the vfork is active, memory corruption is >> practically guaranteed. The only way to disable the signals is with a >> direct system call; sigprocmask/pthread_sigmask do not work. >> >> Does your implementation do this? > > I understand. No, admittedly not. But we squeeze the vulnerable time > window to the minimal possible: > > if (vfork() == 0) exec(..); > > which was a large step forward from the stock Ojdk solution. > > While not completely bullet proof, I saw not a single instance of an > error in all these years (I understand those errors would be very > intermittent and difficult to attribute to vfork+signalling, so we may > have missed some). Well, such tight races never matter until they suddenly do. I'm always amazed how races previously thought impossible reproduce reliably with high probability, given the right circumstances. The highlight so far was a single-instruction race (not even a data race) in our condition variable implementation, which broke our iSCSI implementation. >> > The current posix_spawn() implementation was added to glibc with glibc >> > 2.24. So, what was the state of posix_spawn() before that version? Is >> > it safe to use, does it do the right thing, or will we encounter >> > regressions? >> >> It uses fork by default. It can be told to use vfork, via >> POSIX_SPAWN_USEVFORK, but then it is buggy. For generic JDK code, this >> seems hardly appropriate. > > Are you sure about this? The coding I saw in glibc < 2.24 was that it > would use vfork if both attributes and file actions were NULL, which > should be the case with the OpenJDK and jspawnhelper. Oh, right. All the more reason to backport the glibc 2.24 change. 8-) Thanks, Florian From scolebourne at joda.org Tue Oct 23 09:57:25 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 23 Oct 2018 10:57:25 +0100 Subject: Time-zone database issues In-Reply-To: <87o9blxdac.fsf@oldenburg.str.redhat.com> References: <87r2ghz05p.fsf@oldenburg.str.redhat.com> <87o9blxdac.fsf@oldenburg.str.redhat.com> Message-ID: On Tue, 23 Oct 2018 at 09:44, Florian Weimer wrote: > * Stephen Colebourne: > > > No, the day-of-month and day-of-week would remain the same, as the > > time is relative to those dates. > > My expectation is that the values returned by the other methods would > change for a getLocalTime() that provides a normalized return value > because the transition rule in normalized time is different (i.e., last > Saturday in a month turns into something else). As mentioned in the original mail, it is not always possible to normalize the values back to sane values. Trying to do so would result in a worse outcome than the proposed change (more deprecations and more chance of users hitting compatibility problems). Current response (until tzdb made their recent change): - getDayOfWeek() = Sun - getLocalTime() = 01:00 Proposed response: - getDayOfWeek() = Sat - getLocalTime() = 01:00 (deprecated) - getLocalTimeDuration() = 25:00 Use of these methods is incredibly rare - it is a very specialist API - and is supposed to match the data in tzdb. In addition, the most important method of the class is createTransition(int) which is unaffected by the changes. So the compatibility risk here really is absolutely tiny. Stephen From fweimer at redhat.com Tue Oct 23 10:47:25 2018 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 23 Oct 2018 12:47:25 +0200 Subject: Time-zone database issues In-Reply-To: (Stephen Colebourne's message of "Tue, 23 Oct 2018 10:57:25 +0100") References: <87r2ghz05p.fsf@oldenburg.str.redhat.com> <87o9blxdac.fsf@oldenburg.str.redhat.com> Message-ID: <8736sxvt1e.fsf@oldenburg.str.redhat.com> * Stephen Colebourne: > On Tue, 23 Oct 2018 at 09:44, Florian Weimer wrote: >> * Stephen Colebourne: >> >> > No, the day-of-month and day-of-week would remain the same, as the >> > time is relative to those dates. >> >> My expectation is that the values returned by the other methods would >> change for a getLocalTime() that provides a normalized return value >> because the transition rule in normalized time is different (i.e., last >> Saturday in a month turns into something else). > > As mentioned in the original mail, it is not always possible to > normalize the values back to sane values. Trying to do so would result > in a worse outcome than the proposed change (more deprecations and > more chance of users hitting compatibility problems). > > Current response (until tzdb made their recent change): > - getDayOfWeek() = Sun > - getLocalTime() = 01:00 > > Proposed response: > - getDayOfWeek() = Sat > - getLocalTime() = 01:00 (deprecated) > - getLocalTimeDuration() = 25:00 Hmm. I'm no longer sure if normalization is always possible. If the rule says, ?last Saturady in the month at 25:00?, there is no normalized equivalent because every normalized rule can only express dates that always fall into the same month, as far as I can see. If this is correct, I think offering normalized and non-normalized interfaces is futile. Does it even make sense to expose this level of detail? Many transition rules cannot be expressed in terms of the Gregorian calendar anyway. Thanks, Florian From david.lloyd at redhat.com Tue Oct 23 13:17:22 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 23 Oct 2018 08:17:22 -0500 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: I've submitted a bug report via bugreport.java.com. If/when it gets promoted to a proper JIRA with an issue number, I'll see if I can put the patch up on jdk/submit. On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > launching on Linux, but it's the closest I could find out of what are > really a surprisingly large number of issues that refer to posix_spawn > in one way or another relating to ProcessImpl. There's a different > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > if that one was quite right to hang this off of. Maybe it should be > yet another issue of its own. > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > : vfork() concerns and a fix proposal", where it was casually > mentioned that maybe posix_spawn could become an option on Linux, > whereafter it could be thoroughly tested by brave individuals and > eventually maybe become the default on that platform, obsoleting the > vfork support for good. > > The following patch does just that. I've tested it launching a > multi-process WildFly instance a bunch of times, in conjunction with > the conveniently existent "jdk.lang.Process.launchMechanism" property, > and nothing exploded so here it is. The usual deal with git patches: > apply directly through "patch -p1". > > commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 > Author: David M. Lloyd > Date: Thu Oct 18 15:56:37 2018 -0500 > > [JDK-6850720] Enable POSIX_SPAWN as an option for child process > creation on Linux > > diff --git a/make/launcher/Launcher-java.base.gmk > b/make/launcher/Launcher-java.base.gmk > index 0ce0287d2be..c28fe42d102 100644 > --- a/make/launcher/Launcher-java.base.gmk > +++ b/make/launcher/Launcher-java.base.gmk > @@ -84,7 +84,7 @@ endif > > ################################################################################ > > -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) > +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) > $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ > NAME := jspawnhelper, \ > SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > index 368a4f7380b..959e50dfecd 100644 > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { > > private static enum Platform { > > - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, > LaunchMechanism.FORK), > > BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), > > diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c > b/src/java.base/unix/native/libjava/ProcessImpl_md.c > index 533584fdb7a..6869a64f2cc 100644 > --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c > +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c > @@ -44,7 +44,7 @@ > #include > #include > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > || defined(__linux__) > #include > #endif > > @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { > return resultPid; > } > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > || defined(__linux__) > static pid_t > spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char > *helperpath) { > pid_t resultPid; > @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, > ChildStuff *c, const char *helperpath) > #endif > case MODE_FORK: > return forkChild(c); > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > || defined(__linux__) > case MODE_POSIX_SPAWN: > return spawnChild(env, process, c, helperpath); > #endif -- - DML From adinn at redhat.com Tue Oct 23 13:58:25 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 23 Oct 2018 14:58:25 +0100 Subject: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory In-Reply-To: References: <07d4d0fe-3a2a-414c-74ac-69e8527785d9@redhat.com> <8e1fe763-c631-1060-e714-9f9b9481cfe2@redhat.com> <50ed4716-b76e-6557-1146-03084776c160@redhat.com> <7ab7fb00-92aa-b952-0c63-9b1ab2479def@oracle.com> <600e8c67-80a4-fef5-b441-72c51c6ccddb@oracle.com> <3df3b5cd-dbc7-7fdd-bfc5-2a54d11127da@redhat.com> <27c9458d-7257-378a-4e3a-bd03402794be@oracle.com> <09c92b1a-c6da-e16b-bb68-553876e8a6ea@oracle.com> Message-ID: Hi Alan, Apologies for the 2 week+ delay in replying -- I was away on holiday. On 03/10/18 15:24, Alan Bateman wrote: > On 03/10/2018 10:14, Andrew Dinn wrote: >> : >> Sure, I'd be happy to change this. >> >> Would READ_ONLY_SYNC and READ_WRITE_SYNC be suitable alternatives? Or do >> you have something else in mind? >> > I think that works but it means looking at the proposed > MappedByteBuffer::isPersistent too. MappedByteBuffer hasn't needed > methods to test if the mapping is read-only, read-write or private > mapping and I wonder if isPersistent is really needed. That's a good question. I guess isPersistent is not really needed as a private method since a field lookup would do. It is obviously of no use as a protected method because MappedByteBuffer sits in a sandwich between ByteBuffer and DirectByteBuffer and, hence, cannot be specialized. So, why make it public? The immediate intentions here is to use the new MappedByteBuffer API as a base layer for implementation of a library of classes that provide equivalent capabilities to the libs that extend Intel's libpmem, providing various managed persistent data overlays on the raw NVM bytes such as journals, block array stores etc. As far as that goal is concerned there is arguably no need to provide isPersistent as a public API because these client classes would normally only employ a buffer mapped to NVM. However, I am not sure that is always going to be the only desired mode of operation. It may be, for example, that we want to use these classes to operate over mapped files as well as mapped NVM. That's very likely not going to give great performance (although in the case of a block array store whose block sizes are file page multiples it might not make that much difference). However, it does allow for compatibility mode operation when NVM is not available. Even so, I believe those clients will not actually care what type of buffer they use. Other client classes might also need to be able to provide these two alternative modes of operation -- where the underlying ByteBuffer may or may not be persistent -- and it is not clear to me that they would not care about whether the mapping was to NVM or to a conventional file. It might be that some clients would want to use the buffer in different ways depending on how it is mapped. Jonathan Halliday (in cc) actually defined the method as public on the rather liberal assumption that this might be how it was used but it seems he did not have a specific use case in mind. Of course, a client could always track this information itself. However, since this datum is i) a property of the ByteBuffer and ii) already stored in the ByteBuffer I felt it was best to expose the property via a public getter -- arguably it ought to be final. If you think that is inappropriate or would prefer to remove it so as to minimize the new API surface I would be happy to follow your decision. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.stuefe at gmail.com Tue Oct 23 14:01:41 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 23 Oct 2018 16:01:41 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Oh, I can open a bug report on JBS for you. Should I? (Now I understand the "reuse bug id"). On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > I've submitted a bug report via bugreport.java.com. If/when it gets > promoted to a proper JIRA with an issue number, I'll see if I can put > the patch up on jdk/submit. > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > launching on Linux, but it's the closest I could find out of what are > > really a surprisingly large number of issues that refer to posix_spawn > > in one way or another relating to ProcessImpl. There's a different > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > if that one was quite right to hang this off of. Maybe it should be > > yet another issue of its own. > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > : vfork() concerns and a fix proposal", where it was casually > > mentioned that maybe posix_spawn could become an option on Linux, > > whereafter it could be thoroughly tested by brave individuals and > > eventually maybe become the default on that platform, obsoleting the > > vfork support for good. > > > > The following patch does just that. I've tested it launching a > > multi-process WildFly instance a bunch of times, in conjunction with > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > and nothing exploded so here it is. The usual deal with git patches: > > apply directly through "patch -p1". > > > > commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 > > Author: David M. Lloyd > > Date: Thu Oct 18 15:56:37 2018 -0500 > > > > [JDK-6850720] Enable POSIX_SPAWN as an option for child process > > creation on Linux > > > > diff --git a/make/launcher/Launcher-java.base.gmk > > b/make/launcher/Launcher-java.base.gmk > > index 0ce0287d2be..c28fe42d102 100644 > > --- a/make/launcher/Launcher-java.base.gmk > > +++ b/make/launcher/Launcher-java.base.gmk > > @@ -84,7 +84,7 @@ endif > > > > ################################################################################ > > > > -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) > > +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) > > $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ > > NAME := jspawnhelper, \ > > SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > index 368a4f7380b..959e50dfecd 100644 > > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { > > > > private static enum Platform { > > > > - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > > + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, > > LaunchMechanism.FORK), > > > > BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), > > > > diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > index 533584fdb7a..6869a64f2cc 100644 > > --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > @@ -44,7 +44,7 @@ > > #include > > #include > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > || defined(__linux__) > > #include > > #endif > > > > @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { > > return resultPid; > > } > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > || defined(__linux__) > > static pid_t > > spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char > > *helperpath) { > > pid_t resultPid; > > @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, > > ChildStuff *c, const char *helperpath) > > #endif > > case MODE_FORK: > > return forkChild(c); > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > || defined(__linux__) > > case MODE_POSIX_SPAWN: > > return spawnChild(env, process, c, helperpath); > > #endif > > > > -- > - DML From david.lloyd at redhat.com Tue Oct 23 14:18:32 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 23 Oct 2018 09:18:32 -0500 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Sure. I don't have any tracking information on the bugreport one I submitted, but if you can track that down and promote it, it would save you some typing. Otherwise whatever you can do would be great, thanks. On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > > Oh, I can open a bug report on JBS for you. Should I? > > (Now I understand the "reuse bug id"). > > > On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > > > I've submitted a bug report via bugreport.java.com. If/when it gets > > promoted to a proper JIRA with an issue number, I'll see if I can put > > the patch up on jdk/submit. > > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > > launching on Linux, but it's the closest I could find out of what are > > > really a surprisingly large number of issues that refer to posix_spawn > > > in one way or another relating to ProcessImpl. There's a different > > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > > if that one was quite right to hang this off of. Maybe it should be > > > yet another issue of its own. > > > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > > : vfork() concerns and a fix proposal", where it was casually > > > mentioned that maybe posix_spawn could become an option on Linux, > > > whereafter it could be thoroughly tested by brave individuals and > > > eventually maybe become the default on that platform, obsoleting the > > > vfork support for good. > > > > > > The following patch does just that. I've tested it launching a > > > multi-process WildFly instance a bunch of times, in conjunction with > > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > > and nothing exploded so here it is. The usual deal with git patches: > > > apply directly through "patch -p1". > > > > > > commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 > > > Author: David M. Lloyd > > > Date: Thu Oct 18 15:56:37 2018 -0500 > > > > > > [JDK-6850720] Enable POSIX_SPAWN as an option for child process > > > creation on Linux > > > > > > diff --git a/make/launcher/Launcher-java.base.gmk > > > b/make/launcher/Launcher-java.base.gmk > > > index 0ce0287d2be..c28fe42d102 100644 > > > --- a/make/launcher/Launcher-java.base.gmk > > > +++ b/make/launcher/Launcher-java.base.gmk > > > @@ -84,7 +84,7 @@ endif > > > > > > ################################################################################ > > > > > > -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) > > > +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) > > > $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ > > > NAME := jspawnhelper, \ > > > SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ > > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > index 368a4f7380b..959e50dfecd 100644 > > > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { > > > > > > private static enum Platform { > > > > > > - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > > > + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, > > > LaunchMechanism.FORK), > > > > > > BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), > > > > > > diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > index 533584fdb7a..6869a64f2cc 100644 > > > --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > @@ -44,7 +44,7 @@ > > > #include > > > #include > > > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > || defined(__linux__) > > > #include > > > #endif > > > > > > @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { > > > return resultPid; > > > } > > > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > || defined(__linux__) > > > static pid_t > > > spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char > > > *helperpath) { > > > pid_t resultPid; > > > @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, > > > ChildStuff *c, const char *helperpath) > > > #endif > > > case MODE_FORK: > > > return forkChild(c); > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > || defined(__linux__) > > > case MODE_POSIX_SPAWN: > > > return spawnChild(env, process, c, helperpath); > > > #endif > > > > > > > > -- > > - DML -- - DML From naoto.sato at oracle.com Tue Oct 23 15:32:32 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 23 Oct 2018 08:32:32 -0700 Subject: [12]RFR of JDK-8210407:Refactor java.util.Calendar:i18n shell tests to plain java tests In-Reply-To: References: Message-ID: <45e6c7bf-9d1a-581a-b209-c5f6d739fa07@oracle.com> Hi Daisy, Looks good to me. Please add noreg-self label to the issue. Naoto On 10/22/18 11:16 PM, Ying Zhou wrote: > Hello, > > test/java/util/Calendar/SupplementalJapaneseEraTest.sh > test/java/util/Calendar/GenericTimeZoneNamesTest.sh > test/java/util/Calendar/NarrowNamesTest.sh > > Please review this patch to refactor above shell script tests to java. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210407 > > Webrev: http://cr.openjdk.java.net/~dzhou/8210407/webrev.00/ > > > Thanks, > > Daisy > From thomas.stuefe at gmail.com Tue Oct 23 15:48:52 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 23 Oct 2018 17:48:52 +0200 Subject: 6850720: Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Here you go: https://bugs.openjdk.java.net/browse/JDK-8212828 If noone else steps in, I can sponsor the change for you. Cheers, Thomas On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: > > Sure. I don't have any tracking information on the bugreport one I > submitted, but if you can track that down and promote it, it would > save you some typing. Otherwise whatever you can do would be great, > thanks. > On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > > > > Oh, I can open a bug report on JBS for you. Should I? > > > > (Now I understand the "reuse bug id"). > > > > > > On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > > > > > I've submitted a bug report via bugreport.java.com. If/when it gets > > > promoted to a proper JIRA with an issue number, I'll see if I can put > > > the patch up on jdk/submit. > > > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > > > launching on Linux, but it's the closest I could find out of what are > > > > really a surprisingly large number of issues that refer to posix_spawn > > > > in one way or another relating to ProcessImpl. There's a different > > > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > > > if that one was quite right to hang this off of. Maybe it should be > > > > yet another issue of its own. > > > > > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > > > : vfork() concerns and a fix proposal", where it was casually > > > > mentioned that maybe posix_spawn could become an option on Linux, > > > > whereafter it could be thoroughly tested by brave individuals and > > > > eventually maybe become the default on that platform, obsoleting the > > > > vfork support for good. > > > > > > > > The following patch does just that. I've tested it launching a > > > > multi-process WildFly instance a bunch of times, in conjunction with > > > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > > > and nothing exploded so here it is. The usual deal with git patches: > > > > apply directly through "patch -p1". > > > > > > > > commit f0eb9ff7c46dff76f91160491fcca0eb25d0ab95 > > > > Author: David M. Lloyd > > > > Date: Thu Oct 18 15:56:37 2018 -0500 > > > > > > > > [JDK-6850720] Enable POSIX_SPAWN as an option for child process > > > > creation on Linux > > > > > > > > diff --git a/make/launcher/Launcher-java.base.gmk > > > > b/make/launcher/Launcher-java.base.gmk > > > > index 0ce0287d2be..c28fe42d102 100644 > > > > --- a/make/launcher/Launcher-java.base.gmk > > > > +++ b/make/launcher/Launcher-java.base.gmk > > > > @@ -84,7 +84,7 @@ endif > > > > > > > > ################################################################################ > > > > > > > > -ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix), ) > > > > +ifneq ($(findstring $(OPENJDK_TARGET_OS), macosx solaris aix linux), ) > > > > $(eval $(call SetupJdkExecutable, BUILD_JSPAWNHELPER, \ > > > > NAME := jspawnhelper, \ > > > > SRC := $(TOPDIR)/src/$(MODULE)/unix/native/jspawnhelper, \ > > > > diff --git a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > > b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > > index 368a4f7380b..959e50dfecd 100644 > > > > --- a/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > > +++ b/src/java.base/unix/classes/java/lang/ProcessImpl.java > > > > @@ -89,7 +89,7 @@ final class ProcessImpl extends Process { > > > > > > > > private static enum Platform { > > > > > > > > - LINUX(LaunchMechanism.VFORK, LaunchMechanism.FORK), > > > > + LINUX(LaunchMechanism.VFORK, LaunchMechanism.POSIX_SPAWN, > > > > LaunchMechanism.FORK), > > > > > > > > BSD(LaunchMechanism.POSIX_SPAWN, LaunchMechanism.FORK), > > > > > > > > diff --git a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > > b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > > index 533584fdb7a..6869a64f2cc 100644 > > > > --- a/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > > +++ b/src/java.base/unix/native/libjava/ProcessImpl_md.c > > > > @@ -44,7 +44,7 @@ > > > > #include > > > > #include > > > > > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > > || defined(__linux__) > > > > #include > > > > #endif > > > > > > > > @@ -390,7 +390,7 @@ forkChild(ChildStuff *c) { > > > > return resultPid; > > > > } > > > > > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > > || defined(__linux__) > > > > static pid_t > > > > spawnChild(JNIEnv *env, jobject process, ChildStuff *c, const char > > > > *helperpath) { > > > > pid_t resultPid; > > > > @@ -489,7 +489,7 @@ startChild(JNIEnv *env, jobject process, > > > > ChildStuff *c, const char *helperpath) > > > > #endif > > > > case MODE_FORK: > > > > return forkChild(c); > > > > -#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > > +#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) > > > > || defined(__linux__) > > > > case MODE_POSIX_SPAWN: > > > > return spawnChild(env, process, c, helperpath); > > > > #endif > > > > > > > > > > > > -- > > > - DML > > > > -- > - DML From andy.herrick at oracle.com Tue Oct 23 15:49:30 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 23 Oct 2018 11:49:30 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation Message-ID: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> This patch implements the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool jpackager is a simple packaging tool, based on the JavaFX |javapackager| tool, that: * Supports native packaging formats to give the end user a natural installation experience. These formats include |msi| and |exe| on Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. * Allows launch-time parameters to be specified at packaging time. * Can be invoked directly, from the command line, or programmatically, via the |ToolProvider| API. Webrev: http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ please send feedback to core-libs-dev at openjdk.java.net /Andy Herrick From brent.christian at oracle.com Tue Oct 23 18:24:39 2018 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 23 Oct 2018 11:24:39 -0700 Subject: [12] RFR of JDK-8209768: Refactor java/util/prefs/CheckUserPrefsStorage.sh to plain java test In-Reply-To: References: <9c7dab1b-9ffc-2187-08b1-b30e958bae84@oracle.com> Message-ID: <16b1c4b2-646f-d63b-8dec-23b0e28c1cd5@oracle.com> Hi, Amy So one difference from the original test is that the process that creates the preferences store is still active at the time that the preference is checked. I don't know if this is material to what is being tested or not. It would be more similar to the original test to keep CheckUserPrefFirst.java and CheckUserPrefLater.java, and have the new CheckUserPrefsStorage.java behave more like the original script and just launch CheckUserPrefFirst and CheckUserPrefLater in sequence. That way the preference store is created and written to, then that process exits before a new process checks the written store. Other opinions? Thanks, -Brent On 10/22/18 8:46 PM, Amy Lu wrote: > Please review. > > Thanks, > Amy > > On 2018/10/11 4:47 PM, Amy Lu wrote: >> java/util/prefs/CheckUserPrefsStorage.sh >> >> Please review this patch to refactor above shell script test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8209768 >> webrev: http://cr.openjdk.java.net/~amlu/8209768/webrev.00/ >> >> Thanks, >> Amy > From brian.burkhalter at oracle.com Tue Oct 23 18:29:19 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Oct 2018 11:29:19 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> Message-ID: <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> Hi Brent, That is exactly why version .00 of the patch implemented skipNBytes() in a fixed way in terms of read(). I think that there is a good compromise however and I shall update the patch accordingly. Thanks, Brian > On Oct 22, 2018, at 12:55 PM, Brent Christian wrote: > > 562 public void skipNBytes(long n) throws IOException { > 563 if (n > 0 && skip(n) != n) { > 564 throw new EOFException("End of stream before enough bytes skipped"); > 565 } > 566 } > > If an overrided skip() method were to skip < n bytes but not yet be at EOF, which I think the skip() spec allows, then wouldn't skipNBytes() throw an EOFException ? From Roger.Riggs at oracle.com Tue Oct 23 19:26:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 23 Oct 2018 15:26:27 -0400 Subject: [NEW BUG][JDK12] Avoid subList overhead in String.split and Pattern.split In-Reply-To: <005001d4689c$7a22e0c0$6e68a240$@freenet.de> References: <005001d4689c$7a22e0c0$6e68a240$@freenet.de> Message-ID: <55159410-23b6-7192-1575-24db9dee75b2@oracle.com> Hi Christoph, Can you take another look at the code just ahead of those instances. Suppose when limit == 0, the empty elements were removed from the tail of list. It would seem then that the matchList would always be exactly the size. Can you compare the performance? Adding a check for an optimization usually is a bit slower in every non-optimized case and that's worth watching out for. Given the overhead of proposing and reviewing a change, will this be worth it? $.02, Roger On 10/20/2018 01:43 PM, Christoph Dreis wrote: > Hi, > > while looking through the code of String.split() and Pattern.split(), I > wondered if we could get rid of the calls to list.subList(0, resultSize) if > resultSize matches the size of the list. If that's the case, subList() seems > redundant. > > JMH Benchmarks in single-shot mode show the following results with a new > revised version (attached below): > > Benchmark Mode > Cnt Score Error Units > MyBenchmark.testNew ss 10 12957,900 > ? 7800,863 ns/op > MyBenchmark.testNew:?gc.alloc.rate ss 10 6,248 ? > 3,231 MB/sec > MyBenchmark.testNew:?gc.alloc.rate.norm ss 10 1384,000 ? 0,001 > B/op > MyBenchmark.testNew:?gc.count ss 10 ? 0 > counts > MyBenchmark.testOld ss 10 > 25017,800 ? 19178,411 ns/op > MyBenchmark.testOld:?gc.alloc.rate ss 10 4,887 ? > 3,764 MB/sec > MyBenchmark.testOld:?gc.alloc.rate.norm ss 10 1464,000 ? 0,001 > B/op > MyBenchmark.testOld:?gc.count ss 10 ? 0 > counts > > Other benchmark modes show inconclusive results from the throughput > perspective, yet it's clearly visible that less objects are allocated. > > Could anybody verify if that's a worthwhile improvement? And in case it is, > potentially sponsor it? > > Thanks in advance. > Cheers, > Christoph > > > ===== PATCH ===== > diff -r 5e894b0f5e63 src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java Fri Oct 19 16:29:45 > 2018 -0700 > +++ b/src/java.base/share/classes/java/lang/String.java Sat Oct 20 18:49:02 > 2018 +0200 > @@ -2315,6 +2315,9 @@ > } > } > String[] result = new String[resultSize]; > + if (list.size() == resultSize) { > + return list.toArray(result); > + } > return list.subList(0, resultSize).toArray(result); > } > return Pattern.compile(regex).split(this, limit); > diff -r 5e894b0f5e63 > src/java.base/share/classes/java/util/regex/Pattern.java > --- a/src/java.base/share/classes/java/util/regex/Pattern.java Fri Oct 19 > 16:29:45 2018 -0700 > +++ b/src/java.base/share/classes/java/util/regex/Pattern.java Sat Oct 20 > 18:49:02 2018 +0200 > @@ -1293,6 +1293,9 @@ > while (resultSize > 0 && > matchList.get(resultSize-1).equals("")) > resultSize--; > String[] result = new String[resultSize]; > + if (matchList.size() == resultSize) { > + return matchList.toArray(result); > + } > return matchList.subList(0, resultSize).toArray(result); > } > From david.lloyd at redhat.com Tue Oct 23 19:26:56 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 23 Oct 2018 14:26:56 -0500 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: My plans to try jdk/submit have fallen through unfortunately, as I cannot seem to gain direct or indirect access to that system. So I guess I'm looking for any reviews on this patch now. Thomas has volunteered to sponsor. Thanks. On Tue, Oct 23, 2018 at 10:49 AM Thomas St?fe wrote: > > Here you go: > > https://bugs.openjdk.java.net/browse/JDK-8212828 > > If noone else steps in, I can sponsor the change for you. > > Cheers, Thomas > On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: > > > > Sure. I don't have any tracking information on the bugreport one I > > submitted, but if you can track that down and promote it, it would > > save you some typing. Otherwise whatever you can do would be great, > > thanks. > > On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > > > > > > Oh, I can open a bug report on JBS for you. Should I? > > > > > > (Now I understand the "reuse bug id"). > > > > > > > > > On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > > > > > > > I've submitted a bug report via bugreport.java.com. If/when it gets > > > > promoted to a proper JIRA with an issue number, I'll see if I can put > > > > the patch up on jdk/submit. > > > > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > > > > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > > > > launching on Linux, but it's the closest I could find out of what are > > > > > really a surprisingly large number of issues that refer to posix_spawn > > > > > in one way or another relating to ProcessImpl. There's a different > > > > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > > > > if that one was quite right to hang this off of. Maybe it should be > > > > > yet another issue of its own. > > > > > > > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > > > > : vfork() concerns and a fix proposal", where it was casually > > > > > mentioned that maybe posix_spawn could become an option on Linux, > > > > > whereafter it could be thoroughly tested by brave individuals and > > > > > eventually maybe become the default on that platform, obsoleting the > > > > > vfork support for good. > > > > > > > > > > The following patch does just that. I've tested it launching a > > > > > multi-process WildFly instance a bunch of times, in conjunction with > > > > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > > > > and nothing exploded so here it is. The usual deal with git patches: > > > > > apply directly through "patch -p1". -- - DML -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8212828-posix_spawn.patch Type: text/x-patch Size: 2738 bytes Desc: not available URL: From Roger.Riggs at oracle.com Tue Oct 23 19:51:54 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 23 Oct 2018 15:51:54 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: <47084079-2acd-9675-7126-4927772ebdf2@oracle.com> Hi David, et.al. What would be the rest of the plan for testing? Usually, changes come with tests and a plan. What build parameters are needed to run a full set of tests with the change? Are there build changes needed? Thanks, Roger On 10/23/2018 03:26 PM, David Lloyd wrote: > My plans to try jdk/submit have fallen through unfortunately, as I > cannot seem to gain direct or indirect access to that system. So I > guess I'm looking for any reviews on this patch now. Thomas has > volunteered to sponsor. > > Thanks. > > On Tue, Oct 23, 2018 at 10:49 AM Thomas St?fe wrote: >> Here you go: >> >> https://bugs.openjdk.java.net/browse/JDK-8212828 >> >> If noone else steps in, I can sponsor the change for you. >> >> Cheers, Thomas >> On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: >>> Sure. I don't have any tracking information on the bugreport one I >>> submitted, but if you can track that down and promote it, it would >>> save you some typing. Otherwise whatever you can do would be great, >>> thanks. >>> On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: >>>> Oh, I can open a bug report on JBS for you. Should I? >>>> >>>> (Now I understand the "reuse bug id"). >>>> >>>> >>>> On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: >>>>> I've submitted a bug report via bugreport.java.com. If/when it gets >>>>> promoted to a proper JIRA with an issue number, I'll see if I can put >>>>> the patch up on jdk/submit. >>>>> On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: >>>>>> The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process >>>>>> launching on Linux, but it's the closest I could find out of what are >>>>>> really a surprisingly large number of issues that refer to posix_spawn >>>>>> in one way or another relating to ProcessImpl. There's a different >>>>>> issue to move from vfork to posix_spawn on Solaris, but I wasn't sure >>>>>> if that one was quite right to hang this off of. Maybe it should be >>>>>> yet another issue of its own. >>>>>> >>>>>> Anyway: this is a follow-up to the email thread entitled "Runtime.exec >>>>>> : vfork() concerns and a fix proposal", where it was casually >>>>>> mentioned that maybe posix_spawn could become an option on Linux, >>>>>> whereafter it could be thoroughly tested by brave individuals and >>>>>> eventually maybe become the default on that platform, obsoleting the >>>>>> vfork support for good. >>>>>> >>>>>> The following patch does just that. I've tested it launching a >>>>>> multi-process WildFly instance a bunch of times, in conjunction with >>>>>> the conveniently existent "jdk.lang.Process.launchMechanism" property, >>>>>> and nothing exploded so here it is. The usual deal with git patches: >>>>>> apply directly through "patch -p1". > > From david.lloyd at redhat.com Tue Oct 23 20:37:00 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Tue, 23 Oct 2018 15:37:00 -0500 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <47084079-2acd-9675-7126-4927772ebdf2@oracle.com> References: <47084079-2acd-9675-7126-4927772ebdf2@oracle.com> Message-ID: I'm not really sure TBH. I did some manual testing; beyond that, in a way, the point of this change is to *get* more real-world testing. I haven't yet found any existing tests which try out the various process creation options for a given platform, however. Maybe an idea would be to have a variation on test/jdk/java/lang/ProcessBuilder/BigFork.java which tries all of the LaunchMechanism options (other than FORK, which I believe is known to likely fail with this test) which are available on the current arch? Also there's test/jdk/java/lang/ProcessBuilder/Basic.java which could possibly be adapted to run multiple times as well (and maybe also to cover FORK which is supported for many archs but AFAICT not tested on archs where there are other options, i.e. all of them). But I'm not really sure how to make that happen with the OpenJDK test infrastructure. As for build changes, no I do not believe any are needed, though I am not able to build on non-Linux platforms to be sure; I was hoping to get a run through jdk-submit to verify that but I don't seem to have access to that either, having no particular status in the OpenJDK project other than sometime contributor. Martin did suggest that maybe the spawn native code could be modified to use config-based macros (e.g. HAS_SPAWN_H) instead of the current platform-based detection but I feel that's out of scope for this little change. On Tue, Oct 23, 2018 at 2:53 PM Roger Riggs wrote: > > Hi David, et.al. > > What would be the rest of the plan for testing? > Usually, changes come with tests and a plan. > What build parameters are needed to run a full set of tests with the change? > > Are there build changes needed? > > Thanks, Roger > > > On 10/23/2018 03:26 PM, David Lloyd wrote: > > My plans to try jdk/submit have fallen through unfortunately, as I > > cannot seem to gain direct or indirect access to that system. So I > > guess I'm looking for any reviews on this patch now. Thomas has > > volunteered to sponsor. > > > > Thanks. > > > > On Tue, Oct 23, 2018 at 10:49 AM Thomas St?fe wrote: > >> Here you go: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8212828 > >> > >> If noone else steps in, I can sponsor the change for you. > >> > >> Cheers, Thomas > >> On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: > >>> Sure. I don't have any tracking information on the bugreport one I > >>> submitted, but if you can track that down and promote it, it would > >>> save you some typing. Otherwise whatever you can do would be great, > >>> thanks. > >>> On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > >>>> Oh, I can open a bug report on JBS for you. Should I? > >>>> > >>>> (Now I understand the "reuse bug id"). > >>>> > >>>> > >>>> On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > >>>>> I've submitted a bug report via bugreport.java.com. If/when it gets > >>>>> promoted to a proper JIRA with an issue number, I'll see if I can put > >>>>> the patch up on jdk/submit. > >>>>> On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > >>>>>> The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > >>>>>> launching on Linux, but it's the closest I could find out of what are > >>>>>> really a surprisingly large number of issues that refer to posix_spawn > >>>>>> in one way or another relating to ProcessImpl. There's a different > >>>>>> issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > >>>>>> if that one was quite right to hang this off of. Maybe it should be > >>>>>> yet another issue of its own. > >>>>>> > >>>>>> Anyway: this is a follow-up to the email thread entitled "Runtime.exec > >>>>>> : vfork() concerns and a fix proposal", where it was casually > >>>>>> mentioned that maybe posix_spawn could become an option on Linux, > >>>>>> whereafter it could be thoroughly tested by brave individuals and > >>>>>> eventually maybe become the default on that platform, obsoleting the > >>>>>> vfork support for good. > >>>>>> > >>>>>> The following patch does just that. I've tested it launching a > >>>>>> multi-process WildFly instance a bunch of times, in conjunction with > >>>>>> the conveniently existent "jdk.lang.Process.launchMechanism" property, > >>>>>> and nothing exploded so here it is. The usual deal with git patches: > >>>>>> apply directly through "patch -p1". > > > > > -- - DML From brent.christian at oracle.com Tue Oct 23 20:39:13 2018 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 23 Oct 2018 13:39:13 -0700 Subject: [12] RFR of JDK-8210908: Refactor java/util/prefs/PrefsSpi.sh to plain java test In-Reply-To: <853fad1b-bcef-1f5d-ca2c-0cc8a2558f04@oracle.com> References: <853fad1b-bcef-1f5d-ca2c-0cc8a2558f04@oracle.com> Message-ID: <9b6f2156-54dd-22ae-6053-f92997fbcecc@oracle.com> Hi, Amy I think this looks quite good as it is. Just a couple very minor comments, that you can take or leave: * I don't think a List is needed for the 'expected' argument, it can just be a String. The @DataProvider should be able to return Object[]s of a List and a String. * Really, the argument to PrefsSpi is a regex pattern, rather than an expected result. So overall testProvider() could look like: public void testProvider(List opts, String pattern) throws Throwable * Also, maybe update the comment (+ copyright year, I suppose) in PrefsSpi.java: /* * main class used by regtest PrefsSpi.sh */ Thanks, -Brent On 10/22/18 8:44 PM, Amy Lu wrote: > java/util/prefs/PrefsSpi.sh > > Please review this patch to refactor above shell script test to java. > > bug: https://bugs.openjdk.java.net/browse/JDK-8210908 > webrev: http://cr.openjdk.java.net/~amlu/8210908/webrev.00/ > > Thanks, > Amy From brian.burkhalter at oracle.com Tue Oct 23 22:02:44 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 23 Oct 2018 15:02:44 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> Message-ID: <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> Here is an updated version which hopefully addresses the shortcoming pointed out below: http://cr.openjdk.java.net/~bpb/6516099/webrev.02/ The remaining assumption here is that skip(long) never returns a negative value. Thanks, Brian > On Oct 23, 2018, at 11:29 AM, Brian Burkhalter wrote: > > That is exactly why version .00 of the patch implemented skipNBytes() in a fixed way in terms of read(). I think that there is a good compromise however and I shall update the patch accordingly. > >> On Oct 22, 2018, at 12:55 PM, Brent Christian > wrote: >> >> 562 public void skipNBytes(long n) throws IOException { >> 563 if (n > 0 && skip(n) != n) { >> 564 throw new EOFException("End of stream before enough bytes skipped"); >> 565 } >> 566 } >> >> If an overrided skip() method were to skip < n bytes but not yet be at EOF, which I think the skip() spec allows, then wouldn't skipNBytes() throw an EOFException ? From amy.lu at oracle.com Wed Oct 24 02:07:43 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 24 Oct 2018 10:07:43 +0800 Subject: [12] RFR of JDK-8210908: Refactor java/util/prefs/PrefsSpi.sh to plain java test In-Reply-To: <9b6f2156-54dd-22ae-6053-f92997fbcecc@oracle.com> References: <853fad1b-bcef-1f5d-ca2c-0cc8a2558f04@oracle.com> <9b6f2156-54dd-22ae-6053-f92997fbcecc@oracle.com> Message-ID: <8436a2b4-bb38-bbcd-537b-d5a9c3e2a357@oracle.com> Thank you Brent for the comments! All fixed in the new webrev: http://cr.openjdk.java.net/~amlu/8210908/webrev.01/ Thanks, Amy On 2018/10/24 4:39 AM, Brent Christian wrote: > Hi, Amy > > I think this looks quite good as it is.? Just a couple very minor > comments, that you can take or leave: > > * I don't think a List is needed for the 'expected' argument, > it can just be a String.? The @DataProvider should be able to return > Object[]s of a List and a String. > > * Really, the argument to PrefsSpi is a regex pattern, rather than an > expected result. > > So overall testProvider() could look like: > > ??? public void testProvider(List opts, String pattern) throws > Throwable > > * Also, maybe update the comment (+ copyright year, I suppose) in > PrefsSpi.java: > > /* > ?* main class used by regtest PrefsSpi.sh > ?*/ > > Thanks, > -Brent > > On 10/22/18 8:44 PM, Amy Lu wrote: >> java/util/prefs/PrefsSpi.sh >> >> Please review this patch to refactor above shell script test to java. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210908 >> webrev: http://cr.openjdk.java.net/~amlu/8210908/webrev.00/ >> >> Thanks, >> Amy From thomas.stuefe at gmail.com Wed Oct 24 05:51:08 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 07:51:08 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: For the convenience of the reviewers, here webrev and bug: https://bugs.openjdk.java.net/browse/JDK-8212828 http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev/ submit tests are currently running. ..Thomas On Tue, Oct 23, 2018 at 9:27 PM David Lloyd wrote: > > My plans to try jdk/submit have fallen through unfortunately, as I > cannot seem to gain direct or indirect access to that system. So I > guess I'm looking for any reviews on this patch now. Thomas has > volunteered to sponsor. > > Thanks. > > On Tue, Oct 23, 2018 at 10:49 AM Thomas St?fe wrote: > > > > Here you go: > > > > https://bugs.openjdk.java.net/browse/JDK-8212828 > > > > If noone else steps in, I can sponsor the change for you. > > > > Cheers, Thomas > > On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: > > > > > > Sure. I don't have any tracking information on the bugreport one I > > > submitted, but if you can track that down and promote it, it would > > > save you some typing. Otherwise whatever you can do would be great, > > > thanks. > > > On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > > > > > > > > Oh, I can open a bug report on JBS for you. Should I? > > > > > > > > (Now I understand the "reuse bug id"). > > > > > > > > > > > > On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > > > > > > > > > I've submitted a bug report via bugreport.java.com. If/when it gets > > > > > promoted to a proper JIRA with an issue number, I'll see if I can put > > > > > the patch up on jdk/submit. > > > > > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > > > > > > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > > > > > launching on Linux, but it's the closest I could find out of what are > > > > > > really a surprisingly large number of issues that refer to posix_spawn > > > > > > in one way or another relating to ProcessImpl. There's a different > > > > > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > > > > > if that one was quite right to hang this off of. Maybe it should be > > > > > > yet another issue of its own. > > > > > > > > > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > > > > > : vfork() concerns and a fix proposal", where it was casually > > > > > > mentioned that maybe posix_spawn could become an option on Linux, > > > > > > whereafter it could be thoroughly tested by brave individuals and > > > > > > eventually maybe become the default on that platform, obsoleting the > > > > > > vfork support for good. > > > > > > > > > > > > The following patch does just that. I've tested it launching a > > > > > > multi-process WildFly instance a bunch of times, in conjunction with > > > > > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > > > > > and nothing exploded so here it is. The usual deal with git patches: > > > > > > apply directly through "patch -p1". > > > > -- > - DML From thomas.stuefe at gmail.com Wed Oct 24 06:04:45 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 08:04:45 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Hi all, Basic considerations: This patch enables an untested function to the end user. I am unsure about this. I would feel better if we had something like "-XX:+UnlockDiagnosticVMOptions" for the JDK. That said, I can see the merit in having this switch to play around with. It would it make easier for us to test posix_spawn() (for us, the next step would be to enable it by default in our nightly tests at SAP and just run the nightlies with it for a couple of days or weeks). So, bottomline, I have no strong reservations if no one else has.+ --- Review: - copyright dates need updating on the C-sources - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || defined(_AIX) || defined(__linux__)" to be removed completely from unix-specific source files. The ifdef now covers all OpenJDK Unix platforms. Looks fine otherwise. --- Best, Thomas On Wed, Oct 24, 2018 at 7:51 AM Thomas St?fe wrote: > > For the convenience of the reviewers, here webrev and bug: > > https://bugs.openjdk.java.net/browse/JDK-8212828 > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev/ > > submit tests are currently running. > > ..Thomas > > On Tue, Oct 23, 2018 at 9:27 PM David Lloyd wrote: > > > > My plans to try jdk/submit have fallen through unfortunately, as I > > cannot seem to gain direct or indirect access to that system. So I > > guess I'm looking for any reviews on this patch now. Thomas has > > volunteered to sponsor. > > > > Thanks. > > > > On Tue, Oct 23, 2018 at 10:49 AM Thomas St?fe wrote: > > > > > > Here you go: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8212828 > > > > > > If noone else steps in, I can sponsor the change for you. > > > > > > Cheers, Thomas > > > On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: > > > > > > > > Sure. I don't have any tracking information on the bugreport one I > > > > submitted, but if you can track that down and promote it, it would > > > > save you some typing. Otherwise whatever you can do would be great, > > > > thanks. > > > > On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > > > > > > > > > > Oh, I can open a bug report on JBS for you. Should I? > > > > > > > > > > (Now I understand the "reuse bug id"). > > > > > > > > > > > > > > > On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > > > > > > > > > > > I've submitted a bug report via bugreport.java.com. If/when it gets > > > > > > promoted to a proper JIRA with an issue number, I'll see if I can put > > > > > > the patch up on jdk/submit. > > > > > > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > > > > > > > > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > > > > > > launching on Linux, but it's the closest I could find out of what are > > > > > > > really a surprisingly large number of issues that refer to posix_spawn > > > > > > > in one way or another relating to ProcessImpl. There's a different > > > > > > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > > > > > > if that one was quite right to hang this off of. Maybe it should be > > > > > > > yet another issue of its own. > > > > > > > > > > > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > > > > > > : vfork() concerns and a fix proposal", where it was casually > > > > > > > mentioned that maybe posix_spawn could become an option on Linux, > > > > > > > whereafter it could be thoroughly tested by brave individuals and > > > > > > > eventually maybe become the default on that platform, obsoleting the > > > > > > > vfork support for good. > > > > > > > > > > > > > > The following patch does just that. I've tested it launching a > > > > > > > multi-process WildFly instance a bunch of times, in conjunction with > > > > > > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > > > > > > and nothing exploded so here it is. The usual deal with git patches: > > > > > > > apply directly through "patch -p1". > > > > > > > > -- > > - DML From Alan.Bateman at oracle.com Wed Oct 24 07:42:24 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Oct 2018 08:42:24 +0100 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: On 24/10/2018 06:51, Thomas St?fe wrote: > For the convenience of the reviewers, here webrev and bug: > > https://bugs.openjdk.java.net/browse/JDK-8212828 > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev/ > > submit tests are currently running. > Adding the posix_spawn to the Linux build make sense. As regards testing then we need to at least get ProcessBuilder/Basic.java running with -Djdk.lang.Process.launchMechanism=posix_spawn, maybe a wrapper that has @requires (os.family == "linux") in its description. -Alan From thomas.stuefe at gmail.com Wed Oct 24 08:46:02 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 10:46:02 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: jdk-submit tests were clean. ..Thomas On Wed, Oct 24, 2018 at 7:51 AM Thomas St?fe wrote: > > For the convenience of the reviewers, here webrev and bug: > > https://bugs.openjdk.java.net/browse/JDK-8212828 > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev/ > > submit tests are currently running. > > ..Thomas > > On Tue, Oct 23, 2018 at 9:27 PM David Lloyd wrote: > > > > My plans to try jdk/submit have fallen through unfortunately, as I > > cannot seem to gain direct or indirect access to that system. So I > > guess I'm looking for any reviews on this patch now. Thomas has > > volunteered to sponsor. > > > > Thanks. > > > > On Tue, Oct 23, 2018 at 10:49 AM Thomas St?fe wrote: > > > > > > Here you go: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8212828 > > > > > > If noone else steps in, I can sponsor the change for you. > > > > > > Cheers, Thomas > > > On Tue, Oct 23, 2018 at 4:19 PM David Lloyd wrote: > > > > > > > > Sure. I don't have any tracking information on the bugreport one I > > > > submitted, but if you can track that down and promote it, it would > > > > save you some typing. Otherwise whatever you can do would be great, > > > > thanks. > > > > On Tue, Oct 23, 2018 at 9:02 AM Thomas St?fe wrote: > > > > > > > > > > Oh, I can open a bug report on JBS for you. Should I? > > > > > > > > > > (Now I understand the "reuse bug id"). > > > > > > > > > > > > > > > On Tue, Oct 23, 2018 at 3:18 PM David Lloyd wrote: > > > > > > > > > > > > I've submitted a bug report via bugreport.java.com. If/when it gets > > > > > > promoted to a proper JIRA with an issue number, I'll see if I can put > > > > > > the patch up on jdk/submit. > > > > > > On Thu, Oct 18, 2018 at 4:42 PM David Lloyd wrote: > > > > > > > > > > > > > > The issue 6850720 isn't _exactly_ to use POSIX_SPAWN for process > > > > > > > launching on Linux, but it's the closest I could find out of what are > > > > > > > really a surprisingly large number of issues that refer to posix_spawn > > > > > > > in one way or another relating to ProcessImpl. There's a different > > > > > > > issue to move from vfork to posix_spawn on Solaris, but I wasn't sure > > > > > > > if that one was quite right to hang this off of. Maybe it should be > > > > > > > yet another issue of its own. > > > > > > > > > > > > > > Anyway: this is a follow-up to the email thread entitled "Runtime.exec > > > > > > > : vfork() concerns and a fix proposal", where it was casually > > > > > > > mentioned that maybe posix_spawn could become an option on Linux, > > > > > > > whereafter it could be thoroughly tested by brave individuals and > > > > > > > eventually maybe become the default on that platform, obsoleting the > > > > > > > vfork support for good. > > > > > > > > > > > > > > The following patch does just that. I've tested it launching a > > > > > > > multi-process WildFly instance a bunch of times, in conjunction with > > > > > > > the conveniently existent "jdk.lang.Process.launchMechanism" property, > > > > > > > and nothing exploded so here it is. The usual deal with git patches: > > > > > > > apply directly through "patch -p1". > > > > > > > > -- > > - DML From amy.lu at oracle.com Wed Oct 24 09:04:07 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 24 Oct 2018 17:04:07 +0800 Subject: [12] RFR of JDK-8209768: Refactor java/util/prefs/CheckUserPrefsStorage.sh to plain java test In-Reply-To: <16b1c4b2-646f-d63b-8dec-23b0e28c1cd5@oracle.com> References: <9c7dab1b-9ffc-2187-08b1-b30e958bae84@oracle.com> <16b1c4b2-646f-d63b-8dec-23b0e28c1cd5@oracle.com> Message-ID: <46aad41f-ae78-b223-2738-05ea56a7bbec@oracle.com> On 2018/10/24 2:24 AM, Brent Christian wrote: > Hi, Amy > > So one difference from the original test is that the process that > creates the preferences store is still active at the time that the > preference is checked.? I don't know if this is material to what is > being tested or not. > > It would be more similar to the original test to keep > CheckUserPrefFirst.java and CheckUserPrefLater.java, and have the new > CheckUserPrefsStorage.java behave more like the original script and > just launch CheckUserPrefFirst and CheckUserPrefLater in sequence. > > That way the preference store is created and written to, then that > process exits before a new process checks the written store. Agree. Thank you, Brent! Please review the updated version: http://cr.openjdk.java.net/~amlu/8209768/webrev.01/ Thanks, Amy > > Other opinions? > > Thanks, > -Brent > > On 10/22/18 8:46 PM, Amy Lu wrote: >> Please review. >> >> Thanks, >> Amy >> >> On 2018/10/11 4:47 PM, Amy Lu wrote: >>> java/util/prefs/CheckUserPrefsStorage.sh >>> >>> Please review this patch to refactor above shell script test to java. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8209768 >>> webrev: http://cr.openjdk.java.net/~amlu/8209768/webrev.00/ >>> >>> Thanks, >>> Amy >> From david.lloyd at redhat.com Wed Oct 24 13:35:44 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 24 Oct 2018 08:35:44 -0500 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > Review: > > - copyright dates need updating on the C-sources > > - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > defined(_AIX) || defined(__linux__)" to be removed completely from > unix-specific source files. The ifdef now covers all OpenJDK Unix > platforms. Here's a version with these changes. -- - DML -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8212828-posix_spawn-v2.patch Type: text/x-patch Size: 3414 bytes Desc: not available URL: From thomas.stuefe at gmail.com Wed Oct 24 13:51:51 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 15:51:51 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Hi David, I think we need some form of test, as Alan indicated. java/lang/ProcessBuilder/Basic.java should run through. Actually, I would like it if we would run this test for all valid enabled launch mechanisms, regardless which one is default. Can this be done? To save time I will only rerun the tests once all reviews are completed and the test is added. Thanks, Thomas On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > > On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > > Review: > > > > - copyright dates need updating on the C-sources > > > > - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > > defined(_AIX) || defined(__linux__)" to be removed completely from > > unix-specific source files. The ifdef now covers all OpenJDK Unix > > platforms. > > Here's a version with these changes. > > -- > - DML From david.lloyd at redhat.com Wed Oct 24 13:56:17 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Wed, 24 Oct 2018 08:56:17 -0500 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: On Wed, Oct 24, 2018 at 8:52 AM Thomas St?fe wrote: > > Hi David, > > I think we need some form of test, as Alan indicated. > > java/lang/ProcessBuilder/Basic.java should run through. Actually, I > would like it if we would run this test for all valid enabled launch > mechanisms, regardless which one is default. Can this be done? I agree, however, I do not know how this can be accomplished. Someone who understands this test infrastructure will have to take over. -- - DML From thomas.stuefe at gmail.com Wed Oct 24 14:12:46 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 16:12:46 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: On Wed, Oct 24, 2018 at 3:56 PM David Lloyd wrote: > > On Wed, Oct 24, 2018 at 8:52 AM Thomas St?fe wrote: > > > > Hi David, > > > > I think we need some form of test, as Alan indicated. > > > > java/lang/ProcessBuilder/Basic.java should run through. Actually, I > > would like it if we would run this test for all valid enabled launch > > mechanisms, regardless which one is default. Can this be done? > > I agree, however, I do not know how this can be accomplished. Someone > who understands this test infrastructure will have to take over. > Okay I'll add the test. ..Thomas > -- > - DML From Alan.Bateman at oracle.com Wed Oct 24 14:22:55 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Oct 2018 15:22:55 +0100 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: On 23/10/2018 16:49, Andy Herrick wrote: > This patch implements the Java Packager Tool (jpackager) as described > in JEP 343: Packaging Tool > > > jpackager is a simple packaging tool, based on the JavaFX > |javapackager| tool, that: > > ?* Supports native packaging formats to give the end user a natural > ?? installation experience. These formats include |msi| and |exe| on > ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. > ?* Allows launch-time parameters to be specified at packaging time. > ?* Can be invoked directly, from the command line, or programmatically, > ?? via the |ToolProvider| API. > > Webrev: > > http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ > cc'ing build-dev as it's important to get it reviewed there. What is the plan for tests to go with this tool? I see there is one test in the webrev to do some argument validation but I don't see anything else right now. What is the status of the JNLPConverter tool? I see it is included as a "demo" but maybe it would be better to host somewhere else as this is for developers migrating Java Web Start applications. Would it be possible to update the JEP with all the CLI options? That would be useful for review and also useful for those invoking it with the ToolProvider API. If I read the webrev correctly then it adds two modules, one with the jpackager tool and the other with an API. It would be useful to get a bit more information on the split. Also I think the name of the API module and the package that it exports needs discussion to make sure that the right names are chosen. -Alan From thomas.stuefe at gmail.com Wed Oct 24 14:35:22 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 16:35:22 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: Hi all, version 2 of Davids patch, with test changes: http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ Executed the test on my local Ubuntu box, works fine. Submit job runs. About the test: I added a new line: * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic + * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic The way I understand those tests work is that the first line causes the test to be run with the default launch mechanism, the second line with jdk.lang.Process.launchMechanism=fork explicitly. The third line, added by me, will now explicitly test with posix_spawn. I did not limit the platforms, since posix_spawn should now be available on all platforms, so it should work on all platforms. But then, on all other platforms it has already been the default. This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism gets ignored, so we just executed the same test twice (now three times)? And now we execute the posix_spawn variant twice on all platforms where this is the default, so line 1 and 3 are the same? You see I am not a jtreg expert :) Can I specify a @run directive for only one platform? In that case I would limit the explicit posix_spawn test to Linux. Note however that if we really abondon vfork in the future and make posix_spawn the default, this test becomes simpler too. Best, Thomas On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > > On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > > Review: > > > > - copyright dates need updating on the C-sources > > > > - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > > defined(_AIX) || defined(__linux__)" to be removed completely from > > unix-specific source files. The ifdef now covers all OpenJDK Unix > > platforms. > > Here's a version with these changes. > > -- > - DML From Roger.Riggs at oracle.com Wed Oct 24 15:22:33 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 24 Oct 2018 11:22:33 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: Message-ID: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> Hi Thomas, Thanks for adding the test. There's a feature of jtreg that was exposed a couple of month ago that can be used to deal with running the test too many times. There can be multiple @test blocks with different @requires. * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires (os.family == "linux") * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic I'll run this through our build system too. To fully test out using posix_spawn in many more different scenarios the build system should be augmented to be able to use it as the default for an entire build/CI/CD/test runs. Thanks, Roger On 10/24/2018 10:35 AM, Thomas St?fe wrote: > Hi all, > > version 2 of Davids patch, with test changes: > > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ > > Executed the test on my local Ubuntu box, works fine. Submit job runs. > > About the test: I added a new line: > > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > + * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > The way I understand those tests work is that the first line causes > the test to be run with the default launch mechanism, the second line > with jdk.lang.Process.launchMechanism=fork explicitly. The third line, > added by me, will now explicitly test with posix_spawn. I did not > limit the platforms, since posix_spawn should now be available on all > platforms, so it should work on all platforms. But then, on all other > platforms it has already been the default. > > This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism > gets ignored, so we just executed the same test twice (now three > times)? And now we execute the posix_spawn variant twice on all > platforms where this is the default, so line 1 and 3 are the same? You > see I am not a jtreg expert :) Can I specify a @run directive for only > one platform? In that case I would limit the explicit posix_spawn test > to Linux. > > Note however that if we really abondon vfork in the future and make > posix_spawn the default, this test becomes simpler too. > > Best, Thomas > > > > > > > > > > > > > On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: >> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: >>> Review: >>> >>> - copyright dates need updating on the C-sources >>> >>> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || >>> defined(_AIX) || defined(__linux__)" to be removed completely from >>> unix-specific source files. The ifdef now covers all OpenJDK Unix >>> platforms. >> Here's a version with these changes. >> >> -- >> - DML From Roger.Riggs at oracle.com Wed Oct 24 15:26:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 24 Oct 2018 11:26:00 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> Message-ID: <8bf0e98b-a70c-c3e7-fa81-70b82d07d666@oracle.com> Oops, it dropped the newlines. * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires (os.family == "linux") * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic Roger On 10/24/2018 11:22 AM, Roger Riggs wrote: > > > There can be multiple @test blocks with different @requires. > > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic > * > * @test * @requires (os.family == "linux") > * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > > I'll run this through our build system too. > > To fully test out using posix_spawn in many more different scenarios > the build system should be augmented to be able to use it as the > default for an entire build/CI/CD/test runs. > > Thanks, Roger > > On 10/24/2018 10:35 AM, Thomas St?fe wrote: >> Hi all, >> >> version 2 of Davids patch, with test changes: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ >> >> >> Executed the test on my local Ubuntu box, works fine. Submit job runs. >> >> About the test: I added a new line: >> >> ?? * @run main/othervm/timeout=300 Basic >> ?? * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=fork Basic >> + * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> >> The way I understand those tests work is that the first line causes >> the test to be run with the default launch mechanism, the second line >> with jdk.lang.Process.launchMechanism=fork explicitly. The third line, >> added by me, will now explicitly test with posix_spawn. I did not >> limit the platforms, since posix_spawn should now be available on all >> platforms, so it should work on all platforms. But then, on all other >> platforms it has already been the default. >> >> This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism >> gets ignored, so we just executed the same test twice (now three >> times)? And now we execute the posix_spawn variant twice on all >> platforms where this is the default, so line 1 and 3 are the same? You >> see I am not a jtreg expert :) Can I specify a @run directive for only >> one platform? In that case I would limit the explicit posix_spawn test >> to Linux. >> >> Note however that if we really abondon vfork in the future and make >> posix_spawn the default, this test becomes simpler too. >> >> Best, Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Oct 24, 2018 at 3:36 PM David Lloyd >> wrote: >>> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe >>> wrote: >>>> Review: >>>> >>>> - copyright dates need updating on the C-sources >>>> >>>> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || >>>> defined(_AIX) || defined(__linux__)" to be removed completely from >>>> unix-specific source files. The ifdef now covers all OpenJDK Unix >>>> platforms. >>> Here's a version with these changes. >>> >>> -- >>> - DML > From hannes.wallnoefer at oracle.com Wed Oct 24 16:42:33 2018 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Wed, 24 Oct 2018 18:42:33 +0200 Subject: RFR: 8212726: Replace some use of drop- and foldArguments with filtering argument combinator in StringConcatFactory In-Reply-To: <23256FEA-E07F-43C1-9D5D-E28F90033465@oracle.com> References: <23256FEA-E07F-43C1-9D5D-E28F90033465@oracle.com> Message-ID: <9C2B6278-4A31-49D1-A13F-0CA83F287388@oracle.com> This would definitely be a useful addition to the public MethodHandles API. Achieving this functionality with currently available means is extremely tricky and certainly does not produce readable or maintainable code. Hannes > Am 22.10.2018 um 14:07 schrieb Jim Laskey : > > Thank you for doing this. The MethodHandle changes will simplify many a use case. > > Cheers, > > ? Jim > > >> On Oct 22, 2018, at 6:58 AM, Claes Redestad wrote: >> >> Hi, >> >> StringConcatFactory uses a customized internal foldArguments >> implementation which takes positional arguments to avoid intermediary >> permutation steps, see JDK-8165492[1]. My intent has been to clean this >> up for possible inclusion in the public API. >> >> In preparation of that, I realized that we could probably profit from a >> filtering combinator on top of the existing folding one. Said and done: >> >> http://cr.openjdk.java.net/~redestad/8212726/jdk.00/ >> https://bugs.openjdk.java.net/browse/JDK-8212726 >> >> Using this new MethodHandles.filterArgumentsWithCombiner in place of >> MHs.dropArguments + MHs.foldArgumentsWithCombiner gets rid of a >> significant number of MethodHandles with retained performance >> characteristics. In startup tests exercising indified String >> concatenation the number of generated classes drops by ~25-30%, with a >> measurable improvement in startup time as a result. Subjectively it also >> makes the code in StringConcatFactory easier to read and follow. >> >> While this surely strengthens the case to include these in the public >> API, I'd like to move ahead with this as an internal optimization first >> and propose MethodHandles.filter-/foldArgumentsWithCombiner as public >> API points as a follow-up: apart from improving the javadoc we need to >> work out specification for corner cases - especially illegal values - >> and harden the implementation with more tests. I'm sure there might be >> opinions about the naming of these methods, too... :-) >> >> Thanks! >> >> /Claes >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8165492 > From brent.christian at oracle.com Wed Oct 24 16:51:03 2018 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 24 Oct 2018 09:51:03 -0700 Subject: [12] RFR of JDK-8209768: Refactor java/util/prefs/CheckUserPrefsStorage.sh to plain java test In-Reply-To: <46aad41f-ae78-b223-2738-05ea56a7bbec@oracle.com> References: <9c7dab1b-9ffc-2187-08b1-b30e958bae84@oracle.com> <16b1c4b2-646f-d63b-8dec-23b0e28c1cd5@oracle.com> <46aad41f-ae78-b223-2738-05ea56a7bbec@oracle.com> Message-ID: <1d88d21b-8ad7-dae6-90c3-0458063e006f@oracle.com> Looks great. -Brent On 10/24/18 2:04 AM, Amy Lu wrote: > > Please review the updated version: > http://cr.openjdk.java.net/~amlu/8209768/webrev.01/ > > Thanks, > Amy > >> >> Other opinions? >> >> Thanks, >> -Brent >> >> On 10/22/18 8:46 PM, Amy Lu wrote: >>> Please review. >>> >>> Thanks, >>> Amy >>> >>> On 2018/10/11 4:47 PM, Amy Lu wrote: >>>> java/util/prefs/CheckUserPrefsStorage.sh >>>> >>>> Please review this patch to refactor above shell script test to java. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8209768 >>>> webrev: http://cr.openjdk.java.net/~amlu/8209768/webrev.00/ >>>> >>>> Thanks, >>>> Amy >>> > From brent.christian at oracle.com Wed Oct 24 17:10:08 2018 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 24 Oct 2018 10:10:08 -0700 Subject: [12] RFR of JDK-8210908: Refactor java/util/prefs/PrefsSpi.sh to plain java test In-Reply-To: <8436a2b4-bb38-bbcd-537b-d5a9c3e2a357@oracle.com> References: <853fad1b-bcef-1f5d-ca2c-0cc8a2558f04@oracle.com> <9b6f2156-54dd-22ae-6053-f92997fbcecc@oracle.com> <8436a2b4-bb38-bbcd-537b-d5a9c3e2a357@oracle.com> Message-ID: <04cee500-fd91-5a43-bd4c-328e69346cdf@oracle.com> Super - thanks, Amy. -Brent On 10/23/18 7:07 PM, Amy Lu wrote: > Thank you Brent for the comments! > > All fixed in the new webrev: > http://cr.openjdk.java.net/~amlu/8210908/webrev.01/ > > Thanks, > Amy > > On 2018/10/24 4:39 AM, Brent Christian wrote: >> Hi, Amy >> >> I think this looks quite good as it is.? Just a couple very minor >> comments, that you can take or leave: >> >> * I don't think a List is needed for the 'expected' argument, >> it can just be a String.? The @DataProvider should be able to return >> Object[]s of a List and a String. >> >> * Really, the argument to PrefsSpi is a regex pattern, rather than an >> expected result. >> >> So overall testProvider() could look like: >> >> ??? public void testProvider(List opts, String pattern) throws >> Throwable >> >> * Also, maybe update the comment (+ copyright year, I suppose) in >> PrefsSpi.java: >> >> /* >> ?* main class used by regtest PrefsSpi.sh >> ?*/ >> >> Thanks, >> -Brent >> >> On 10/22/18 8:44 PM, Amy Lu wrote: >>> java/util/prefs/PrefsSpi.sh >>> >>> Please review this patch to refactor above shell script test to java. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210908 >>> webrev: http://cr.openjdk.java.net/~amlu/8210908/webrev.00/ >>> >>> Thanks, >>> Amy > From erik.joelsson at oracle.com Wed Oct 24 17:18:41 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 24 Oct 2018 10:18:41 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: <756780e6-78ab-5759-7f7a-63f00f1e3feb@oracle.com> Hello, Nice to see this finally happening! Are we actually adding a new demo? I thought we were working towards getting rid of the demos completely. CompileJavaModules.gmk: The jdk.packager_CLEAN_FILES could be replaced with a simple "jdk.packager_CLEAN := .properties" unless you actually need to add all the platform specific files to builds for all platforms (which I doubt?). To clarify, the current patch will add all linux, windows and mac properties to builds of all OSes. Is that intended? Modules.gmk: I would rather have the filter be conditional on an inclusive list of platforms. Other OpenJDK contributors are building for other OSes like AIX and we don't want to have to keep track of all those. The list of OSes that jpackager supports is well defined, so better check for those explicitly. src/jdk.jlink/share/classes/module-info.java: I believe the qualified export needs to be put in a module-info.java.extra file since we filter out the target module on unsupported platforms. Launcher-jdk.packager.gmk: * Please use $$(call FindExecutableDirForModule, $$(MODULE)) for the DEST dir in the copy. * Please adjust the indentation of the big windows/else blocks. We indent everything with 2 spaces in conditional blocks. * A minor style nit on the copy-and-chmod macro, since it's meant to be used as a recipe, we usually indent those with tabs to indicate that they are recipe lines, in this case, one tab is enough even though the surrounding define should be indented with 2 spaces (don't combine tab and spaces here). * The (new) SetupJdkExecutable macro handles VERSIONINFO_RESOURCE automatically for you unless you have specific needs. This looks like the defaults should be fine. * Since this is just for windows, the TOOLCHAIN_LINK_CXX should not make any difference. (It's only needed for GCC to force linking with g++ instead of gcc) So please remove. * You could consider using FindSrcDirsForComponent for the src dir. Lib-jdk.packager.gmk: * The native source files are not organized according to the standards introduced with JEP 201. If they were, most of these SetupJdkLibrary calls would automatically find the correct sources. I realize there is a special case for the windows papplauncherc executable as it's built from the same sources as papplauncher, so that will need a special case. Building of the executables should be moved to Launcher-jdk.packager.gmk however. * Why are you changing the build output dir and copying debuginfo files around? We have a standard way of building and places where files are put. If that is not working for you, we need to fix it on a global level. Having each native library being built differently is not good for maintainability. * VERSIONINFO_RESOURCE is handled automatically so does not need to be specified. * Please indent the full contents of logic blocks with 2 spaces. Not having proper indents makes it much harder to read the code. * Several lines are too long for future side by side comparisons, please break them up. You can use the # lines as a soft guidance. /Erik On 2018-10-24 07:22, Alan Bateman wrote: > On 23/10/2018 16:49, Andy Herrick wrote: >> This patch implements the Java Packager Tool (jpackager) as described >> in JEP 343: Packaging Tool >> >> >> jpackager is a simple packaging tool, based on the JavaFX >> |javapackager| tool, that: >> >> ?* Supports native packaging formats to give the end user a natural >> ?? installation experience. These formats include |msi| and |exe| on >> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >> ?* Allows launch-time parameters to be specified at packaging time. >> ?* Can be invoked directly, from the command line, or programmatically, >> ?? via the |ToolProvider| API. >> >> Webrev: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >> > cc'ing build-dev as it's important to get it reviewed there. > > What is the plan for tests to go with this tool? I see there is one > test in the webrev to do some argument validation but I don't see > anything else right now. > > What is the status of the JNLPConverter tool? I see it is included as > a "demo" but maybe it would be better to host somewhere else as this > is for developers migrating Java Web Start applications. > > Would it be possible to update the JEP with all the CLI options? That > would be useful for review and also useful for those invoking it with > the ToolProvider API. > > If I read the webrev correctly then it adds two modules, one with the > jpackager tool and the other with an API. It would be useful to get a > bit more information on the split. Also I think the name of the API > module and the package that it exports needs discussion to make sure > that the right names are chosen. > > -Alan From lance.andersen at oracle.com Wed Oct 24 17:19:32 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 24 Oct 2018 13:19:32 -0400 Subject: RFR 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator Message-ID: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> Hi all, This change removes the finalize methods from java.util.zip.ZipFIle/Inflator/Deflator. These methods were deprecated and marked for removal in JDK 9 The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212129/webrev.00/ The relevant JCK tests for zip and jar continue to run clean as do the JDK tier1 - tier3 tests The CSR has also been finalized Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From thomas.stuefe at gmail.com Wed Oct 24 17:53:19 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 19:53:19 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> Message-ID: Hi Roger, On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: > > Hi Thomas, > > Thanks for adding the test. > > There's a feature of jtreg that was exposed a couple of month ago that > can be used to deal with running the test too many times. > > There can be multiple @test blocks with different @requires. > > * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires > (os.family == "linux") * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > Does not seem to work, sorry: 24 /* 25 * @test 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 30 * 8067796 31 * @key intermittent 32 * @summary Basic tests for Process and Environment Variable code 33 * @modules java.base/java.lang:open 34 * @run main/othervm/timeout=300 Basic 35 * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic 36 * @test 37 * @requires (os.family == "liinux") 38 * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic 39 * @author Martin Buchholz 40 */ If I have @requires (os.family == "linux") all three variants are executed - ok. Then I wanted to have a negative test, so I misnamed linux as "liinux" and would have expected the first @test block to fire, the second to be ignored. But in fact: thomas at mainframe /shared/projects/openjdk/jtreg $ ../jtreg-prebuilt/jtreg/bin/jtreg -jdk ../jdk-jdk/output-slowdebug/images/jdk/ ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java Test results: no tests selected So to me it looks like as if the @requires tag is valid for both @test blocks, not only the one it appears in. > I'll run this through our build system too. > > To fully test out using posix_spawn in many more different scenarios the > build system should be augmented to be able to use it as the default for > an entire build/CI/CD/test runs. Sure! But I think this is out of scope for this patch. Thanks, Thomas > > Thanks, Roger > > On 10/24/2018 10:35 AM, Thomas St?fe wrote: > > Hi all, > > > > version 2 of Davids patch, with test changes: > > > > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ > > > > Executed the test on my local Ubuntu box, works fine. Submit job runs. > > > > About the test: I added a new line: > > > > * @run main/othervm/timeout=300 Basic > > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > > + * @run main/othervm/timeout=300 > > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > > > The way I understand those tests work is that the first line causes > > the test to be run with the default launch mechanism, the second line > > with jdk.lang.Process.launchMechanism=fork explicitly. The third line, > > added by me, will now explicitly test with posix_spawn. I did not > > limit the platforms, since posix_spawn should now be available on all > > platforms, so it should work on all platforms. But then, on all other > > platforms it has already been the default. > > > > This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism > > gets ignored, so we just executed the same test twice (now three > > times)? And now we execute the posix_spawn variant twice on all > > platforms where this is the default, so line 1 and 3 are the same? You > > see I am not a jtreg expert :) Can I specify a @run directive for only > > one platform? In that case I would limit the explicit posix_spawn test > > to Linux. > > > > Note however that if we really abondon vfork in the future and make > > posix_spawn the default, this test becomes simpler too. > > > > Best, Thomas > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > >> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > >>> Review: > >>> > >>> - copyright dates need updating on the C-sources > >>> > >>> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > >>> defined(_AIX) || defined(__linux__)" to be removed completely from > >>> unix-specific source files. The ifdef now covers all OpenJDK Unix > >>> platforms. > >> Here's a version with these changes. > >> > >> -- > >> - DML > From thomas.stuefe at gmail.com Wed Oct 24 18:16:04 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 20:16:04 +0200 Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: Hi Martin, sorry for letting this rest for so long - I got sidetracked by other issues. On Wed, Sep 12, 2018 at 3:17 PM Martin Buchholz wrote: > > In 2018, we can assume everyone has implemented FD_CLOEXEC. > > Back in 1970, 20 file descriptors was enough for any program, but > today they're effectively unlimited, so futilely closing _SC_OPEN_MAX > descriptors has become unreasonable (as you say). OTOH, there is > still no standard way of ensuring all our file descriptors are closed. > Do we need the fallback on your beloved HP-UX? Should we simply close > the first 64k file descriptors and pray, as is traditional? This sounds like a reasonable limit. If I understand this correctly, this only affects stray JVM/JDK file descriptors which were not opened with FD_CLOEXEC - which is an error - and third party native code. In hotspot, os::open() sets FD_CLOEXEC, and java file descriptors are set to FD_CLOEXEC too. So the error surface is quiet small nowadays. So I think giving up after 64K is okay. > > freebsd offers closefrom(2) > https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpath=freebsd-release-ports > and today we can autoconfiscate the existence of closefrom and use > that where available (BSD and Solaris?) > Here is what I think is theoretically possible: AIX: has a fcntl command which closes all file descriptors above X which is fine BSD (but apparently not MacOS): has int closefrom(2) which is fine Solaris: has a useless closefrom(3) which returns no exit code. Unless one wants to ignore the exit code, this is no option. However, Solaris has fdwalk(3), which we use in our port to walk open file descriptors and close them. But I am not sure about the merit here, this may be actually more expensive than walking the proc file system itself. ----- In any case I would suggest to keep the fallback code, which walks the proc file system, for all Unices. And also to keep the fallback from that, which closes a range brute force - possibly with a reasonable max. Is that too strict? The question is now what is more important to you: code clarity (few platform ifdefs) or trying out every technique we can think of? A) If code clarity and simplicity is important, I would basically keep the coding we have now: just walk the proc file system - including the AIX ifdefs unfortunately - and as fallback close the range with brute force until reasonable max. B) If we want to try everything, we will have more ifdefs, not less, which would look something like this: #ifdef AIX try fcntl(F_CLOSEM) #endif #if defined(_ALL_BSD_SOURCE) && !defined(APPLE) try closefrom() #endif #ifdef SOLARIS try fdwalk (?) #endif fallback: walk proc file system fallback: close range until 64K or so. ------ Not sure this is worth it... In our port I did (B) but today I personally would go with (A). (B) has too many difficult-to-test-branches. And it may be actually slower, since you may do work twice (if e.g. fdwalk fails for the same reason that manually walking the proc fs fails). What do you think? > closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ? > > I'd give this function a javadoc style docstring. > Will fix both. > (Finding the FD_DIR directory has become rather ugly, especially the > AIX-specific code) Sorry. I keep hoping that sometime in the future IBM will actually take part in this AIX port and share some of the work. And blame :( Best Regards, Thomas From thomas.stuefe at gmail.com Wed Oct 24 18:17:47 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 20:17:47 +0200 Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: "Do we need the fallback on your beloved HP-UX?" We do not ship OpenJDK on HPUX, so I do not really care. And I really do not love it :) ..Thomas On Wed, Oct 24, 2018 at 8:16 PM Thomas St?fe wrote: > > Hi Martin, > > sorry for letting this rest for so long - I got sidetracked by other issues. > > On Wed, Sep 12, 2018 at 3:17 PM Martin Buchholz wrote: > > > > In 2018, we can assume everyone has implemented FD_CLOEXEC. > > > > Back in 1970, 20 file descriptors was enough for any program, but > > today they're effectively unlimited, so futilely closing _SC_OPEN_MAX > > descriptors has become unreasonable (as you say). OTOH, there is > > still no standard way of ensuring all our file descriptors are closed. > > Do we need the fallback on your beloved HP-UX? Should we simply close > > the first 64k file descriptors and pray, as is traditional? > > This sounds like a reasonable limit. > > If I understand this correctly, this only affects stray JVM/JDK file > descriptors which were not opened with FD_CLOEXEC - which is an error > - and third party native code. In hotspot, os::open() sets FD_CLOEXEC, > and java file descriptors are set to FD_CLOEXEC too. > > So the error surface is quiet small nowadays. So I think giving up > after 64K is okay. > > > > > freebsd offers closefrom(2) > > https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpath=freebsd-release-ports > > and today we can autoconfiscate the existence of closefrom and use > > that where available (BSD and Solaris?) > > > > Here is what I think is theoretically possible: > > AIX: has a fcntl command which closes all file descriptors above X which is fine > > BSD (but apparently not MacOS): has int closefrom(2) which is fine > > Solaris: has a useless closefrom(3) which returns no exit code. Unless > one wants to ignore the exit code, this is no option. However, Solaris > has fdwalk(3), which we use in our port to walk open file descriptors > and close them. But I am not sure about the merit here, this may be > actually more expensive than walking the proc file system itself. > > ----- > > In any case I would suggest to keep the fallback code, which walks the > proc file system, for all Unices. And also to keep the fallback from > that, which closes a range brute force - possibly with a reasonable > max. Is that too strict? > > The question is now what is more important to you: code clarity (few > platform ifdefs) or trying out every technique we can think of? > > A) If code clarity and simplicity is important, I would basically keep > the coding we have now: just walk the proc file system - including the > AIX ifdefs unfortunately - and as fallback close the range with brute > force until reasonable max. > > B) If we want to try everything, we will have more ifdefs, not less, > which would look something like this: > > #ifdef AIX > try fcntl(F_CLOSEM) > #endif > > #if defined(_ALL_BSD_SOURCE) && !defined(APPLE) > try closefrom() > #endif > > #ifdef SOLARIS > try fdwalk (?) > #endif > > fallback: walk proc file system > > fallback: close range until 64K or so. > > ------ > > Not sure this is worth it... > > In our port I did (B) but today I personally would go with (A). (B) > has too many difficult-to-test-branches. And it may be actually > slower, since you may do work twice (if e.g. fdwalk fails for the same > reason that manually walking the proc fs fails). > > What do you think? > > > closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ? > > > > I'd give this function a javadoc style docstring. > > > > Will fix both. > > > (Finding the FD_DIR directory has become rather ugly, especially the > > AIX-specific code) > > Sorry. > > I keep hoping that sometime in the future IBM will actually take part > in this AIX port and share some of the work. And blame :( > > Best Regards, Thomas From brent.christian at oracle.com Wed Oct 24 19:08:05 2018 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 24 Oct 2018 12:08:05 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> Message-ID: Hi, I think that's looking pretty good. One thing: InputStream.java 515 * @param n the number of bytes to be skipped. How about an @param for throwOnEOF, too? Regarding the tests: NullInputStream.java 237 @Test(groups = "closed") 238 public static void testSkipNBytesClosed() { Can this method also use the "expectedExceptions" attribute of @Test ? -- Skip.java Is there a test for skipNBytes() where the skip() call skips < n bytes ? I'm thinking about code coverage of: 588 // If not enough skipped, read and discard bytes, failing on EOF 589 if (ns != n) { 590 discardNBytes(n - ns, true); 591 } If not, maybe MyInputStream could override skip(long), with a mode where it would skip < n bytes. Thanks, -Brent On 10/23/18 3:02 PM, Brian Burkhalter wrote: > Here is an updated version which hopefully addresses the shortcoming > pointed out below: > > http://cr.openjdk.java.net/~bpb/6516099/webrev.02/ > > > The remaining assumption here is that skip(long) never returns a > negative value. > > Thanks, > > Brian > >> On Oct 23, 2018, at 11:29 AM, Brian Burkhalter >> > wrote: >> >> That is exactly why version .00 of the patch implemented skipNBytes() >> in a fixed way in terms of read(). I think that there is a good >> compromise however and I shall update the patch accordingly. >> >>> On Oct 22, 2018, at 12:55 PM, Brent Christian >>> > wrote: >>> >>> 562 ????public void skipNBytes(long n) throws IOException { >>> 563 ????????if (n > 0 && skip(n) != n) { >>> 564 ????????????throw new EOFException("End of stream before enough >>> bytes skipped"); >>> 565 ????????} >>> 566 ????} >>> >>> If an overrided skip() method were to skip < n bytes but not yet be >>> at EOF, which I think the skip() spec allows, then wouldn't >>> skipNBytes() throw an EOFException ? > From xueming.shen at oracle.com Wed Oct 24 19:28:13 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 24 Oct 2018 12:28:13 -0700 Subject: Fwd: RFR: JDK-8212694 - Using Raw String Literals with align() and Integer.MIN_VALUE causes out of memory error In-Reply-To: References: <7D8502E9-B0F3-4F3A-9163-64C01BB54842@oracle.com> Message-ID: <5BD0C7CD.2090304@oracle.com> looks good. -sherman >> *From: *Jim Laskey > > >> *Subject: **RFR: JDK-8212694 - Using Raw String Literals with align() >> and Integer.MIN_VALUE causes out of memory error* >> *Date: *October 19, 2018 at 2:50:19 PM ADT >> *To: *core-libs-dev > > >> >> This fix proper clips large negative values for n. >> >> webrev: >> http://cr.openjdk.java.net/~jlaskey/8212694/webrev-00/index.html >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8212694 > From roger.riggs at oracle.com Wed Oct 24 19:39:07 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 24 Oct 2018 15:39:07 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> Message-ID: <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> Hi Thomas, Sorry, I had the incantation for multiple tests wrong. Separate test configurations need to be in separate /* */ comment blocks. BTW, it creates separate .jtr files for each block. diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java --- a/test/jdk/java/lang/ProcessBuilder/Basic.java +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java @@ -33,8 +33,10 @@ ? * @modules java.base/java.lang:open ? * @run main/othervm/timeout=300 Basic ? * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic - * + */ +/* ? * @test + * @modules java.base/java.lang:open ? * @requires (os.family == "linux") ? * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic ? * @author Martin Buchholz As for the build configuration being out of scope... I don't want to see part of the work done and then the rest forgotten or worse yet someone comes along in the future and incorrectly believes that posix_spawn is ready for production and starts filing bugs or getting bit by something. There's a lot more testing to do before it could be come the default and perhaps a significant warning should be attached to the code so it does not get forgotten. Regards, Roger On 10/24/18 1:53 PM, Thomas St?fe wrote: > Hi Roger, > > On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: >> Hi Thomas, >> >> Thanks for adding the test. >> >> There's a feature of jtreg that was exposed a couple of month ago that >> can be used to deal with running the test too many times. >> >> There can be multiple @test blocks with different @requires. >> >> * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires >> (os.family == "linux") * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> >> > Does not seem to work, sorry: > > 24 /* > 25 * @test > 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 > 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 > 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 > 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 > 30 * 8067796 > 31 * @key intermittent > 32 * @summary Basic tests for Process and Environment Variable code > 33 * @modules java.base/java.lang:open > 34 * @run main/othervm/timeout=300 Basic > 35 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic > 36 * @test > 37 * @requires (os.family == "liinux") > 38 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > 39 * @author Martin Buchholz > 40 */ > > If I have @requires (os.family == "linux") all three variants are executed - ok. > > Then I wanted to have a negative test, so I misnamed linux as "liinux" > and would have expected the first @test block to fire, the second to > be ignored. But in fact: > > thomas at mainframe /shared/projects/openjdk/jtreg $ > ../jtreg-prebuilt/jtreg/bin/jtreg -jdk > ../jdk-jdk/output-slowdebug/images/jdk/ > ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java > Test results: no tests selected > > So to me it looks like as if the @requires tag is valid for both @test > blocks, not only the one it appears in. > >> I'll run this through our build system too. >> >> To fully test out using posix_spawn in many more different scenarios the >> build system should be augmented to be able to use it as the default for >> an entire build/CI/CD/test runs. > Sure! But I think this is out of scope for this patch. > > Thanks, Thomas > >> Thanks, Roger >> >> On 10/24/2018 10:35 AM, Thomas St?fe wrote: >>> Hi all, >>> >>> version 2 of Davids patch, with test changes: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ >>> >>> Executed the test on my local Ubuntu box, works fine. Submit job runs. >>> >>> About the test: I added a new line: >>> >>> * @run main/othervm/timeout=300 Basic >>> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >>> + * @run main/othervm/timeout=300 >>> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >>> >>> The way I understand those tests work is that the first line causes >>> the test to be run with the default launch mechanism, the second line >>> with jdk.lang.Process.launchMechanism=fork explicitly. The third line, >>> added by me, will now explicitly test with posix_spawn. I did not >>> limit the platforms, since posix_spawn should now be available on all >>> platforms, so it should work on all platforms. But then, on all other >>> platforms it has already been the default. >>> >>> This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism >>> gets ignored, so we just executed the same test twice (now three >>> times)? And now we execute the posix_spawn variant twice on all >>> platforms where this is the default, so line 1 and 3 are the same? You >>> see I am not a jtreg expert :) Can I specify a @run directive for only >>> one platform? In that case I would limit the explicit posix_spawn test >>> to Linux. >>> >>> Note however that if we really abondon vfork in the future and make >>> posix_spawn the default, this test becomes simpler too. >>> >>> Best, Thomas >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: >>>> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: >>>>> Review: >>>>> >>>>> - copyright dates need updating on the C-sources >>>>> >>>>> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || >>>>> defined(_AIX) || defined(__linux__)" to be removed completely from >>>>> unix-specific source files. The ifdef now covers all OpenJDK Unix >>>>> platforms. >>>> Here's a version with these changes. >>>> >>>> -- >>>> - DML From andrewluotechnologies at outlook.com Wed Oct 24 19:39:56 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 24 Oct 2018 19:39:56 +0000 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> Message-ID: I'm not a reviewer/committer but just a suggestion: You can use assert to ensure "document" that skip(long) should never return negative (and also provide useful debugging when assertions are enabled), for example: 586 long ns = skip(n); assert ns >= 0 : "skip(long) returned negative value " + ns; 587 588 // If not enough skipped, read and discard bytes, failing on EOF 589 if (ns != n) { 590 discardNBytes(n - ns, true); 591 } Thanks, Andrew -----Original Message----- From: core-libs-dev On Behalf Of Brent Christian Sent: Wednesday, October 24, 2018 12:08 PM To: Brian Burkhalter ; Java Core Libs Subject: Re: 6516099: InputStream.skipFully(int k) to skip exactly k bytes Hi, I think that's looking pretty good. One thing: InputStream.java 515 * @param n the number of bytes to be skipped. How about an @param for throwOnEOF, too? Regarding the tests: NullInputStream.java 237 @Test(groups = "closed") 238 public static void testSkipNBytesClosed() { Can this method also use the "expectedExceptions" attribute of @Test ? -- Skip.java Is there a test for skipNBytes() where the skip() call skips < n bytes ? I'm thinking about code coverage of: 588 // If not enough skipped, read and discard bytes, failing on EOF 589 if (ns != n) { 590 discardNBytes(n - ns, true); 591 } If not, maybe MyInputStream could override skip(long), with a mode where it would skip < n bytes. Thanks, -Brent On 10/23/18 3:02 PM, Brian Burkhalter wrote: > Here is an updated version which hopefully addresses the shortcoming > pointed out below: > > http://cr.openjdk.java.net/~bpb/6516099/webrev.02/ > > > The remaining assumption here is that skip(long) never returns a > negative value. > > Thanks, > > Brian > >> On Oct 23, 2018, at 11:29 AM, Brian Burkhalter >> > wrote: >> >> That is exactly why version .00 of the patch implemented skipNBytes() >> in a fixed way in terms of read(). I think that there is a good >> compromise however and I shall update the patch accordingly. >> >>> On Oct 22, 2018, at 12:55 PM, Brent Christian >>> > wrote: >>> >>> 562 ????public void skipNBytes(long n) throws IOException { >>> 563 ????????if (n > 0 && skip(n) != n) { >>> 564 ????????????throw new EOFException("End of stream before enough >>> bytes skipped"); >>> 565 ????????} >>> 566 ????} >>> >>> If an overrided skip() method were to skip < n bytes but not yet be >>> at EOF, which I think the skip() spec allows, then wouldn't >>> skipNBytes() throw an EOFException ? > From brian.burkhalter at oracle.com Wed Oct 24 19:54:42 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Oct 2018 12:54:42 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> Message-ID: <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> Hi Brent, Sadly we had a sort of race condition going on here. Here is one more update which gets rid of excess code, namely the discardNBytes() method: http://cr.openjdk.java.net/~bpb/6516099/webrev.03/ This implementation assumes that in most cases skip(n) will actually skip n bytes. For ?bad? implementations which do not do so, single bytes are read and discarded until either the requested number of bytes has been skipped or EOF is reached. In the latter situation, an EOFException is thrown. This still assumes that skip(n) itself never returns a negative value. The test Skip.java is also updated so that the fallback path in skipNBytes is tested. Please also see comments inline below. Thanks, Brian > On Oct 24, 2018, at 12:08 PM, Brent Christian wrote: > > I think that's looking pretty good. One thing: > > InputStream.java > > 515 * @param n the number of bytes to be skipped. > > How about an @param for throwOnEOF, too? No longer pertinent. > Regarding the tests: > > NullInputStream.java > > 237 @Test(groups = "closed") > 238 public static void testSkipNBytesClosed() { > > Can this method also use the "expectedExceptions" attribute of @Test ? Need to revisit that. > -- > Skip.java > > Is there a test for skipNBytes() where the skip() call skips < n bytes ? I'm thinking about code coverage of: > > 588 // If not enough skipped, read and discard bytes, failing on EOF > 589 if (ns != n) { > 590 discardNBytes(n - ns, true); > 591 } > > If not, maybe MyInputStream could override skip(long), with a mode where it would skip < n bytes. This is addressed in the patch version .03. From brian.burkhalter at oracle.com Wed Oct 24 19:56:01 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Oct 2018 12:56:01 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> Message-ID: <874110BA-4A5B-4705-85D3-0D2000B3A544@oracle.com> Hi Andrew, Thanks for the suggestion. Will consider it for the final check-in. Brian > On Oct 24, 2018, at 12:39 PM, Andrew Luo wrote: > > I'm not a reviewer/committer but just a suggestion: > > You can use assert to ensure "document" that skip(long) should never return negative (and also provide useful debugging when assertions are enabled), for example: > > 586 long ns = skip(n); > assert ns >= 0 : "skip(long) returned negative value " + ns; > 587 > 588 // If not enough skipped, read and discard bytes, failing on EOF > 589 if (ns != n) { > 590 discardNBytes(n - ns, true); > 591 } From joe.darcy at oracle.com Wed Oct 24 20:11:52 2018 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 24 Oct 2018 13:11:52 -0700 Subject: JDK 12 RFR of JDK-8212880: Cannot access ftp: site for fdlibm.tar Message-ID: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> Hello, Seems the ftp option for the fdlibm sources has gone away; the URL reference in the JDK sources in StrictMath should be updated to a live page: ??? ??? JDK-8212880: Cannot access ftp: site for fdlibm.tar Patch: diff -r 211998500d39 src/java.base/share/classes/java/lang/StrictMath.java --- a/src/java.base/share/classes/java/lang/StrictMath.java??? Thu Aug 16 19:49:25 2018 -0400 +++ b/src/java.base/share/classes/java/lang/StrictMath.java??? Wed Oct 24 13:08:41 2018 -0700 @@ -40,7 +40,7 @@ ? * algorithms are available from the well-known network library ? * {@code netlib} as the package "Freely Distributable Math ? * Library," {@code fdlibm}. These + * href="https://www.netlib.org/fdlibm/">{@code fdlibm}. These ? * algorithms, which are written in the C programming language, are ? * then to be understood as executed with all floating-point ? * operations following the rules of Java floating-point arithmetic. Thanks, -Joe From jonathan.gibbons at oracle.com Wed Oct 24 20:13:41 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 24 Oct 2018 13:13:41 -0700 Subject: JDK 12 RFR of JDK-8212880: Cannot access ftp: site for fdlibm.tar In-Reply-To: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> References: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> Message-ID: +1 -- Jon On 10/24/2018 01:11 PM, joe darcy wrote: > Hello, > > Seems the ftp option for the fdlibm sources has gone away; the URL > reference in the JDK sources in StrictMath should be updated to a live > page: > > ??? ??? JDK-8212880: Cannot access ftp: site for fdlibm.tar > > Patch: > > diff -r 211998500d39 > src/java.base/share/classes/java/lang/StrictMath.java > --- a/src/java.base/share/classes/java/lang/StrictMath.java??? Thu Aug > 16 19:49:25 2018 -0400 > +++ b/src/java.base/share/classes/java/lang/StrictMath.java??? Wed Oct > 24 13:08:41 2018 -0700 > @@ -40,7 +40,7 @@ > ? * algorithms are available from the well-known network library > ? * {@code netlib} as the package "Freely Distributable Math > ? * Library," - * href="ftp://ftp.netlib.org/fdlibm.tar">{@code fdlibm}. These > + * href="https://www.netlib.org/fdlibm/">{@code fdlibm}. These > ? * algorithms, which are written in the C programming language, are > ? * then to be understood as executed with all floating-point > ? * operations following the rules of Java floating-point arithmetic. > > Thanks, > > -Joe > From lance.andersen at oracle.com Wed Oct 24 20:14:43 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 24 Oct 2018 16:14:43 -0400 Subject: JDK 12 RFR of JDK-8212880: Cannot access ftp: site for fdlibm.tar In-Reply-To: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> References: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> Message-ID: <91D5C7BD-720D-49D4-9E67-1A696EEF2F44@oracle.com> looks fine joe > On Oct 24, 2018, at 4:11 PM, joe darcy wrote: > > Hello, > > Seems the ftp option for the fdlibm sources has gone away; the URL reference in the JDK sources in StrictMath should be updated to a live page: > > JDK-8212880: Cannot access ftp: site for fdlibm.tar > > Patch: > > diff -r 211998500d39 src/java.base/share/classes/java/lang/StrictMath.java > --- a/src/java.base/share/classes/java/lang/StrictMath.java Thu Aug 16 19:49:25 2018 -0400 > +++ b/src/java.base/share/classes/java/lang/StrictMath.java Wed Oct 24 13:08:41 2018 -0700 > @@ -40,7 +40,7 @@ > * algorithms are available from the well-known network library > * {@code netlib} as the package "Freely Distributable Math > * Library," - * href="ftp://ftp.netlib.org/fdlibm.tar">{@code fdlibm}. These > + * href="https://www.netlib.org/fdlibm/">{@code fdlibm}. These > * algorithms, which are written in the C programming language, are > * then to be understood as executed with all floating-point > * operations following the rules of Java floating-point arithmetic. > > Thanks, > > -Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Wed Oct 24 20:15:54 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Oct 2018 13:15:54 -0700 Subject: JDK 12 RFR of JDK-8212880: Cannot access ftp: site for fdlibm.tar In-Reply-To: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> References: <512da75a-183e-2836-f528-7a73d6a35a88@oracle.com> Message-ID: <2DB693ED-9BEB-4E06-993B-3A6D945B81D5@oracle.com> Hi Joe, Looks fine. Brian > On Oct 24, 2018, at 1:11 PM, joe darcy wrote: > > Seems the ftp option for the fdlibm sources has gone away; the URL reference in the JDK sources in StrictMath should be updated to a live page: > > JDK-8212880: Cannot access ftp: site for fdlibm.tar > > Patch: > > diff -r 211998500d39 src/java.base/share/classes/java/lang/StrictMath.java > --- a/src/java.base/share/classes/java/lang/StrictMath.java Thu Aug 16 19:49:25 2018 -0400 > +++ b/src/java.base/share/classes/java/lang/StrictMath.java Wed Oct 24 13:08:41 2018 -0700 > @@ -40,7 +40,7 @@ > * algorithms are available from the well-known network library > * {@code netlib} as the package "Freely Distributable Math > * Library," - * href="ftp://ftp.netlib.org/fdlibm.tar ">{@code fdlibm}. These > + * href="https://www.netlib.org/fdlibm /">{@code fdlibm}. These > * algorithms, which are written in the C programming language, are > * then to be understood as executed with all floating-point > * operations following the rules of Java floating-point arithmetic. From andrewluotechnologies at outlook.com Wed Oct 24 20:17:51 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 24 Oct 2018 20:17:51 +0000 Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: By the way, there is some related work on CLOEXEC for networking that I had done. It seems like this work is somewhat similar (although my work addresses a different use case - when JNI code calls exec on its own and doesn't go through and close its inherited FDs): http://mail.openjdk.java.net/pipermail/net-dev/2018-August/011730.html "> If I understand this correctly, this only affects stray JVM/JDK file > descriptors which were not opened with FD_CLOEXEC - which is an error > - and third party native code. In hotspot, os::open() sets FD_CLOEXEC, > and java file descriptors are set to FD_CLOEXEC too." Unfortunately, that is only for sockets... sockets in Linux are file descriptors as well, but OpenJDK is (currently) not opening them with CLOEXEC. Thanks, -Andrew -----Original Message----- From: core-libs-dev On Behalf Of Thomas St?fe Sent: Wednesday, October 24, 2018 11:18 AM To: Martin Buchholz Cc: Java Core Libs Subject: Re: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() "Do we need the fallback on your beloved HP-UX?" We do not ship OpenJDK on HPUX, so I do not really care. And I really do not love it :) ..Thomas On Wed, Oct 24, 2018 at 8:16 PM Thomas St?fe wrote: > > Hi Martin, > > sorry for letting this rest for so long - I got sidetracked by other issues. > > On Wed, Sep 12, 2018 at 3:17 PM Martin Buchholz wrote: > > > > In 2018, we can assume everyone has implemented FD_CLOEXEC. > > > > Back in 1970, 20 file descriptors was enough for any program, but > > today they're effectively unlimited, so futilely closing > > _SC_OPEN_MAX descriptors has become unreasonable (as you say). > > OTOH, there is still no standard way of ensuring all our file descriptors are closed. > > Do we need the fallback on your beloved HP-UX? Should we simply > > close the first 64k file descriptors and pray, as is traditional? > > This sounds like a reasonable limit. > > If I understand this correctly, this only affects stray JVM/JDK file > descriptors which were not opened with FD_CLOEXEC - which is an error > - and third party native code. In hotspot, os::open() sets FD_CLOEXEC, > and java file descriptors are set to FD_CLOEXEC too. > > So the error surface is quiet small nowadays. So I think giving up > after 64K is okay. > > > > > freebsd offers closefrom(2) > > https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpat > > h=freebsd-release-ports and today we can autoconfiscate the > > existence of closefrom and use that where available (BSD and > > Solaris?) > > > > Here is what I think is theoretically possible: > > AIX: has a fcntl command which closes all file descriptors above X > which is fine > > BSD (but apparently not MacOS): has int closefrom(2) which is fine > > Solaris: has a useless closefrom(3) which returns no exit code. Unless > one wants to ignore the exit code, this is no option. However, Solaris > has fdwalk(3), which we use in our port to walk open file descriptors > and close them. But I am not sure about the merit here, this may be > actually more expensive than walking the proc file system itself. > > ----- > > In any case I would suggest to keep the fallback code, which walks the > proc file system, for all Unices. And also to keep the fallback from > that, which closes a range brute force - possibly with a reasonable > max. Is that too strict? > > The question is now what is more important to you: code clarity (few > platform ifdefs) or trying out every technique we can think of? > > A) If code clarity and simplicity is important, I would basically keep > the coding we have now: just walk the proc file system - including the > AIX ifdefs unfortunately - and as fallback close the range with brute > force until reasonable max. > > B) If we want to try everything, we will have more ifdefs, not less, > which would look something like this: > > #ifdef AIX > try fcntl(F_CLOSEM) > #endif > > #if defined(_ALL_BSD_SOURCE) && !defined(APPLE) > try closefrom() > #endif > > #ifdef SOLARIS > try fdwalk (?) > #endif > > fallback: walk proc file system > > fallback: close range until 64K or so. > > ------ > > Not sure this is worth it... > > In our port I did (B) but today I personally would go with (A). (B) > has too many difficult-to-test-branches. And it may be actually > slower, since you may do work twice (if e.g. fdwalk fails for the same > reason that manually walking the proc fs fails). > > What do you think? > > > closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ? > > > > I'd give this function a javadoc style docstring. > > > > Will fix both. > > > (Finding the FD_DIR directory has become rather ugly, especially the > > AIX-specific code) > > Sorry. > > I keep hoping that sometime in the future IBM will actually take part > in this AIX port and share some of the work. And blame :( > > Best Regards, Thomas From thomas.stuefe at gmail.com Wed Oct 24 20:59:08 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 24 Oct 2018 22:59:08 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> Message-ID: Hi Roger, On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: > Hi Thomas, > > Sorry, I had the incantation for multiple tests wrong. > Separate test configurations need to be in separate /* */ comment blocks. > BTW, it creates separate .jtr files for each block. > > diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java > b/test/jdk/java/lang/ProcessBuilder/Basic.java > --- a/test/jdk/java/lang/ProcessBuilder/Basic.java > +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java > @@ -33,8 +33,10 @@ > * @modules java.base/java.lang:open > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork > Basic > - * > + */ > +/* > * @test > + * @modules java.base/java.lang:open > * @requires (os.family == "linux") > * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > * @author Martin Buchholz > > > As for the build configuration being out of scope... > > I don't want to see part of the work done and then the rest forgotten or > worse yet someone comes along in the future and incorrectly believes that > posix_spawn is ready for production and starts filing bugs or getting bit > by something. > There's a lot more testing to do before it could be come the default > and perhaps a significant warning should be attached to the code so it > does not get forgotten. > I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. Do you have an idea how to proceed? Thanks, Thomas > Regards, Roger > > > On 10/24/18 1:53 PM, Thomas St?fe wrote: > > Hi Roger, > > On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: > > Hi Thomas, > > Thanks for adding the test. > > There's a feature of jtreg that was exposed a couple of month ago that > can be used to deal with running the test too many times. > > There can be multiple @test blocks with different @requires. > > * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires > (os.family == "linux") * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > > > Does not seem to work, sorry: > > 24 /* > 25 * @test > 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 > 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 > 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 > 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 > 30 * 8067796 > 31 * @key intermittent > 32 * @summary Basic tests for Process and Environment Variable code > 33 * @modules java.base/java.lang:open > 34 * @run main/othervm/timeout=300 Basic > 35 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic > 36 * @test > 37 * @requires (os.family == "liinux") > 38 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > 39 * @author Martin Buchholz > 40 */ > > If I have @requires (os.family == "linux") all three variants are executed - ok. > > Then I wanted to have a negative test, so I misnamed linux as "liinux" > and would have expected the first @test block to fire, the second to > be ignored. But in fact: > > thomas at mainframe /shared/projects/openjdk/jtreg $ > ../jtreg-prebuilt/jtreg/bin/jtreg -jdk > ../jdk-jdk/output-slowdebug/images/jdk/ > ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java > Test results: no tests selected > > So to me it looks like as if the @requires tag is valid for both @test > blocks, not only the one it appears in. > > > I'll run this through our build system too. > > To fully test out using posix_spawn in many more different scenarios the > build system should be augmented to be able to use it as the default for > an entire build/CI/CD/test runs. > > Sure! But I think this is out of scope for this patch. > > Thanks, Thomas > > > Thanks, Roger > > On 10/24/2018 10:35 AM, Thomas St?fe wrote: > > Hi all, > > version 2 of Davids patch, with test changes: > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ > > Executed the test on my local Ubuntu box, works fine. Submit job runs. > > About the test: I added a new line: > > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > + * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > The way I understand those tests work is that the first line causes > the test to be run with the default launch mechanism, the second line > with jdk.lang.Process.launchMechanism=fork explicitly. The third line, > added by me, will now explicitly test with posix_spawn. I did not > limit the platforms, since posix_spawn should now be available on all > platforms, so it should work on all platforms. But then, on all other > platforms it has already been the default. > > This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism > gets ignored, so we just executed the same test twice (now three > times)? And now we execute the posix_spawn variant twice on all > platforms where this is the default, so line 1 and 3 are the same? You > see I am not a jtreg expert :) Can I specify a @run directive for only > one platform? In that case I would limit the explicit posix_spawn test > to Linux. > > Note however that if we really abondon vfork in the future and make > posix_spawn the default, this test becomes simpler too. > > Best, Thomas > > > > > > > > > > > > > On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > > On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > > Review: > > - copyright dates need updating on the C-sources > > - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > defined(_AIX) || defined(__linux__)" to be removed completely from > unix-specific source files. The ifdef now covers all OpenJDK Unix > platforms. > > Here's a version with these changes. > > -- > - DML > > > From mandy.chung at oracle.com Wed Oct 24 22:17:01 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Oct 2018 15:17:01 -0700 Subject: Review Request JDK-8212948: Remove unused jdk.internal.misc.VMNotification interface Message-ID: Remove a leftover file from JDK-8159590 that removed jdk.internal.misc.VM.registerVMNotification method taking VMNotification parameter. $ hg remove src/java.base/share/classes/jdk/internal/misc/VMNotification.java Mandy diff --git a/src/java.base/share/classes/jdk/internal/misc/VMNotification.java b/src/java.base/share/classes/jdk/internal/misc/VMNotification.java deleted file mode 100644 --- a/src/java.base/share/classes/jdk/internal/misc/VMNotification.java +++ /dev/null @@ -1,39 +0,0 @@ -/* - * Copyright (c) 1996, 2004, Oracle and/or its affiliates. All rights reserved. - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. - * - * This code is free software; you can redistribute it and/or modify it - * under the terms of the GNU General Public License version 2 only, as - * published by the Free Software Foundation.? Oracle designates this - * particular file as subject to the "Classpath" exception as provided - * by Oracle in the LICENSE file that accompanied this code. - * - * This code is distributed in the hope that it will be useful, but WITHOUT - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or - * FITNESS FOR A PARTICULAR PURPOSE.? See the GNU General Public License - * version 2 for more details (a copy is included in the LICENSE file that - * accompanied this code). - * - * You should have received a copy of the GNU General Public License version - * 2 along with this work; if not, write to the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. - * - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA - * or visit www.oracle.com if you need additional information or have any - * questions. - */ - -package jdk.internal.misc; - -/** @deprecated */ - at Deprecated -public interface VMNotification { - -??? // when the vm switches allocation states, we get notified -??? // (possible semantics: if the state changes while in this -??? // notification, don't recursively notify). -??? // oldState and newState may be the same if we are just releasing -??? // suspended threads. -??? void newAllocState(int oldState, int newState, -?????????????????????? boolean threadsSuspended); -} From lance.andersen at oracle.com Wed Oct 24 22:29:06 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 24 Oct 2018 18:29:06 -0400 Subject: Review Request JDK-8212948: Remove unused jdk.internal.misc.VMNotification interface In-Reply-To: References: Message-ID: <23DF64E8-D91F-451E-AE8A-5ABFA4C3CCF4@oracle.com> +1 > On Oct 24, 2018, at 6:17 PM, Mandy Chung wrote: > > Remove a leftover file from JDK-8159590 that removed > jdk.internal.misc.VM.registerVMNotification method taking > VMNotification parameter. > > $ hg remove src/java.base/share/classes/jdk/internal/misc/VMNotification.java > > Mandy > > diff --git a/src/java.base/share/classes/jdk/internal/misc/VMNotification.java b/src/java.base/share/classes/jdk/internal/misc/VMNotification.java > deleted file mode 100644 > --- a/src/java.base/share/classes/jdk/internal/misc/VMNotification.java > +++ /dev/null > @@ -1,39 +0,0 @@ > -/* > - * Copyright (c) 1996, 2004, Oracle and/or its affiliates. All rights reserved. > - * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > - * > - * This code is free software; you can redistribute it and/or modify it > - * under the terms of the GNU General Public License version 2 only, as > - * published by the Free Software Foundation. Oracle designates this > - * particular file as subject to the "Classpath" exception as provided > - * by Oracle in the LICENSE file that accompanied this code. > - * > - * This code is distributed in the hope that it will be useful, but WITHOUT > - * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > - * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > - * version 2 for more details (a copy is included in the LICENSE file that > - * accompanied this code). > - * > - * You should have received a copy of the GNU General Public License version > - * 2 along with this work; if not, write to the Free Software Foundation, > - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > - * > - * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > - * or visit www.oracle.com if you need additional information or have any > - * questions. > - */ > - > -package jdk.internal.misc; > - > -/** @deprecated */ > - at Deprecated > -public interface VMNotification { > - > - // when the vm switches allocation states, we get notified > - // (possible semantics: if the state changes while in this > - // notification, don't recursively notify). > - // oldState and newState may be the same if we are just releasing > - // suspended threads. > - void newAllocState(int oldState, int newState, > - boolean threadsSuspended); > -} > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From andrewluotechnologies at outlook.com Wed Oct 24 23:10:37 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Wed, 24 Oct 2018 23:10:37 +0000 Subject: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() In-Reply-To: References: Message-ID: Sorry, I meant to say: "Unfortunately, that is only for files... sockets in Linux are file descriptors as well, but OpenJDK is (currently) not opening them with CLOEXEC." -----Original Message----- From: core-libs-dev On Behalf Of Andrew Luo Sent: Wednesday, October 24, 2018 1:18 PM To: Thomas St?fe ; Martin Buchholz Cc: Java Core Libs Subject: RE: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() By the way, there is some related work on CLOEXEC for networking that I had done. It seems like this work is somewhat similar (although my work addresses a different use case - when JNI code calls exec on its own and doesn't go through and close its inherited FDs): http://mail.openjdk.java.net/pipermail/net-dev/2018-August/011730.html "> If I understand this correctly, this only affects stray JVM/JDK file > descriptors which were not opened with FD_CLOEXEC - which is an error > - and third party native code. In hotspot, os::open() sets FD_CLOEXEC, > and java file descriptors are set to FD_CLOEXEC too." Unfortunately, that is only for sockets... sockets in Linux are file descriptors as well, but OpenJDK is (currently) not opening them with CLOEXEC. Thanks, -Andrew -----Original Message----- From: core-libs-dev On Behalf Of Thomas St?fe Sent: Wednesday, October 24, 2018 11:18 AM To: Martin Buchholz Cc: Java Core Libs Subject: Re: RFR(s): 8210549: Runtime.exec: in closeDescriptors(), use FD_CLOEXEC instead of close() "Do we need the fallback on your beloved HP-UX?" We do not ship OpenJDK on HPUX, so I do not really care. And I really do not love it :) ..Thomas On Wed, Oct 24, 2018 at 8:16 PM Thomas St?fe wrote: > > Hi Martin, > > sorry for letting this rest for so long - I got sidetracked by other issues. > > On Wed, Sep 12, 2018 at 3:17 PM Martin Buchholz wrote: > > > > In 2018, we can assume everyone has implemented FD_CLOEXEC. > > > > Back in 1970, 20 file descriptors was enough for any program, but > > today they're effectively unlimited, so futilely closing > > _SC_OPEN_MAX descriptors has become unreasonable (as you say). > > OTOH, there is still no standard way of ensuring all our file descriptors are closed. > > Do we need the fallback on your beloved HP-UX? Should we simply > > close the first 64k file descriptors and pray, as is traditional? > > This sounds like a reasonable limit. > > If I understand this correctly, this only affects stray JVM/JDK file > descriptors which were not opened with FD_CLOEXEC - which is an error > - and third party native code. In hotspot, os::open() sets FD_CLOEXEC, > and java file descriptors are set to FD_CLOEXEC too. > > So the error surface is quiet small nowadays. So I think giving up > after 64K is okay. > > > > > freebsd offers closefrom(2) > > https://www.freebsd.org/cgi/man.cgi?query=closefrom&sektion=2&manpat > > h=freebsd-release-ports and today we can autoconfiscate the > > existence of closefrom and use that where available (BSD and > > Solaris?) > > > > Here is what I think is theoretically possible: > > AIX: has a fcntl command which closes all file descriptors above X > which is fine > > BSD (but apparently not MacOS): has int closefrom(2) which is fine > > Solaris: has a useless closefrom(3) which returns no exit code. Unless > one wants to ignore the exit code, this is no option. However, Solaris > has fdwalk(3), which we use in our port to walk open file descriptors > and close them. But I am not sure about the merit here, this may be > actually more expensive than walking the proc file system itself. > > ----- > > In any case I would suggest to keep the fallback code, which walks the > proc file system, for all Unices. And also to keep the fallback from > that, which closes a range brute force - possibly with a reasonable > max. Is that too strict? > > The question is now what is more important to you: code clarity (few > platform ifdefs) or trying out every technique we can think of? > > A) If code clarity and simplicity is important, I would basically keep > the coding we have now: just walk the proc file system - including the > AIX ifdefs unfortunately - and as fallback close the range with brute > force until reasonable max. > > B) If we want to try everything, we will have more ifdefs, not less, > which would look something like this: > > #ifdef AIX > try fcntl(F_CLOSEM) > #endif > > #if defined(_ALL_BSD_SOURCE) && !defined(APPLE) > try closefrom() > #endif > > #ifdef SOLARIS > try fdwalk (?) > #endif > > fallback: walk proc file system > > fallback: close range until 64K or so. > > ------ > > Not sure this is worth it... > > In our port I did (B) but today I personally would go with (A). (B) > has too many difficult-to-test-branches. And it may be actually > slower, since you may do work twice (if e.g. fdwalk fails for the same > reason that manually walking the proc fs fails). > > What do you think? > > > closeDescriptors needs a better name now - maybe ensureDescriptorsAreClosed ? > > > > I'd give this function a javadoc style docstring. > > > > Will fix both. > > > (Finding the FD_DIR directory has become rather ugly, especially the > > AIX-specific code) > > Sorry. > > I keep hoping that sometime in the future IBM will actually take part > in this AIX port and share some of the work. And blame :( > > Best Regards, Thomas From Sergey.Bylokhov at oracle.com Wed Oct 24 23:41:22 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Oct 2018 16:41:22 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> Message-ID: Hi, Brian. It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n); "

    This method may skip more bytes than what are remaining in the * backing file. This produces no exception and the number of bytes skipped * may include some number of bytes that were beyond the EOF of the * backing file. Attempting to read from the stream after skipping past * the end will result in -1 indicating the end of the file." On 24/10/2018 12:54, Brian Burkhalter wrote: > Hi Brent, > > Sadly we had a sort of race condition going on here. Here is one more update which gets rid of excess code, namely the discardNBytes() method: > > http://cr.openjdk.java.net/~bpb/6516099/webrev.03/ > > This implementation assumes that in most cases skip(n) will actually skip n bytes. For ?bad? implementations which do not do so, single bytes are read and discarded until either the requested number of bytes has been skipped or EOF is reached. In the latter situation, an EOFException is thrown. This still assumes that skip(n) itself never returns a negative value. The test Skip.java is also updated so that the fallback path in skipNBytes is tested. > > Please also see comments inline below. > > Thanks, > > Brian > >> On Oct 24, 2018, at 12:08 PM, Brent Christian wrote: >> >> I think that's looking pretty good. One thing: >> >> InputStream.java >> >> 515 * @param n the number of bytes to be skipped. >> >> How about an @param for throwOnEOF, too? > > No longer pertinent. > >> Regarding the tests: >> >> NullInputStream.java >> >> 237 @Test(groups = "closed") >> 238 public static void testSkipNBytesClosed() { >> >> Can this method also use the "expectedExceptions" attribute of @Test ? > > Need to revisit that. > >> -- >> Skip.java >> >> Is there a test for skipNBytes() where the skip() call skips < n bytes ? I'm thinking about code coverage of: >> >> 588 // If not enough skipped, read and discard bytes, failing on EOF >> 589 if (ns != n) { >> 590 discardNBytes(n - ns, true); >> 591 } >> >> If not, maybe MyInputStream could override skip(long), with a mode where it would skip < n bytes. > > This is addressed in the patch version .03. > -- Best regards, Sergey. From brian.burkhalter at oracle.com Wed Oct 24 23:44:15 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Oct 2018 16:44:15 -0700 Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results In-Reply-To: <797af194-b4f8-3ee8-9068-c561ebf067da@gmail.com> References: <797af194-b4f8-3ee8-9068-c561ebf067da@gmail.com> Message-ID: Hello, I think I neglected to post the link here before, but the Compatibility and Specification Request (CSR) corresponding to this issue is at [2]. It has a specdiff attached to it which would be helpful in comparing the changes to the javadoc specification of {Double,Float}.toString(). Any comments or reviews from interested parties would be appreciated. Thanks, Brian [1] https://wiki.openjdk.java.net/display/csr [2] https://bugs.openjdk.java.net/browse/JDK-8202555 From brian.burkhalter at oracle.com Thu Oct 25 00:14:30 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 24 Oct 2018 17:14:30 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> Message-ID: Hi Sergey, That is rather ugly. Thanks for pointing it out. The previous version which merely repeatedly read and discarded a buffer of bytes did not have this problem, but it also did not take advantage of any performance improvement to be obtained by subclass overriding of skip(). It does introduce some randomness into the situation. For example if some FileInputStream with a backing file of length L were used in two different scenarios the results could differ. A) skip(L-4) then skipNBytes(8) B) skip(L) then skipNBytes(4) In case A, skipNBytes(8) could conceivably succeed while in case B, skipNBytes(4) could fail, which is inconsistent given that the final positions in stream terms are theoretically identical. Unclear what to do here ... Thanks, Brian > On Oct 24, 2018, at 4:41 PM, Sergey Bylokhov wrote: > > It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n); > > "

    This method may skip more bytes than what are remaining in the > * backing file. This produces no exception and the number of bytes skipped > * may include some number of bytes that were beyond the EOF of the > * backing file. Attempting to read from the stream after skipping past > * the end will result in -1 indicating the end of the file." From Alan.Bateman at oracle.com Thu Oct 25 06:12:31 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Oct 2018 07:12:31 +0100 Subject: Review Request JDK-8212948: Remove unused jdk.internal.misc.VMNotification interface In-Reply-To: References: Message-ID: <5385be2f-76fd-d051-f7d1-51631bbe4146@oracle.com> On 24/10/2018 23:17, Mandy Chung wrote: > Remove a leftover file from JDK-8159590 that removed > jdk.internal.misc.VM.registerVMNotification method taking > VMNotification parameter. > > $ hg remove > src/java.base/share/classes/jdk/internal/misc/VMNotification.java Looks okay to me. I assume you've checked that there aren't any tests using it. -Alan From christoph.langer at sap.com Thu Oct 25 07:15:46 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 25 Oct 2018 07:15:46 +0000 Subject: RFR 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator In-Reply-To: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> References: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> Message-ID: Hi Lance, looks fine, reviewed. Good to see this happening. Best regards Christoph > -----Original Message----- > From: core-libs-dev On Behalf > Of Lance Andersen > Sent: Mittwoch, 24. Oktober 2018 19:20 > To: core-libs-dev > Subject: RFR 8212129: Remove finalize methods from > java.util.zip.ZipFIle/Inflator/Deflator > > Hi all, > > This change removes the finalize methods from > java.util.zip.ZipFIle/Inflator/Deflator. These methods were deprecated and > marked for removal in JDK 9 > > The webrev can be found at: > http://cr.openjdk.java.net/~lancea/8212129/webrev.00/ > > > The relevant JCK tests for zip and jar continue to run clean as do the JDK tier1 > - tier3 tests > > The CSR has also been finalized > > Best, > Lance > > > > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From aph at redhat.com Thu Oct 25 08:37:15 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Oct 2018 09:37:15 +0100 Subject: Time-zone database issues In-Reply-To: References: Message-ID: <6090086a-e8bb-9449-ed71-ce99e1ca0ef5@redhat.com> On 10/22/2018 11:25 PM, Stephen Colebourne wrote: > The IANA time-zone database [1] provides details of how time-zones > change over time. The latest release - 2018f - cannot be processed > successfully by the current JDK parser [2]. A workaround exists > however unlike previous cases of tzdb incompatibility, this time it > makes sense for the JDK parser and API to be changed. I don't think so. This patch is in the development version of tzdata: mm.icann.org/pipermail/tz/attachments/20181018/a1734c98/0001-Avoid-25-00-in-rearguard-format.patch -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.fuchs at oracle.com Thu Oct 25 10:09:30 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 25 Oct 2018 11:09:30 +0100 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> Message-ID: Hi Brian, Hmmm... Just thinking aloud: Should InputStream provide a safe but non-optimized version of skipNBytes() that does not rely on skip(), and should subclasses that override skip() for performance also be changed to override skipNBytes too if performance improvement can be gained? best regards, -- daniel On 25/10/2018 01:14, Brian Burkhalter wrote: > Hi Sergey, > > That is rather ugly. Thanks for pointing it out. The previous version which merely repeatedly read and discarded a buffer of bytes did not have this problem, but it also did not take advantage of any performance improvement to be obtained by subclass overriding of skip(). > > It does introduce some randomness into the situation. For example if some FileInputStream with a backing file of length L were used in two different scenarios the results could differ. > > A) skip(L-4) then skipNBytes(8) > B) skip(L) then skipNBytes(4) > > In case A, skipNBytes(8) could conceivably succeed while in case B, skipNBytes(4) could fail, which is inconsistent given that the final positions in stream terms are theoretically identical. > > Unclear what to do here ... > > Thanks, > > Brian > >> On Oct 24, 2018, at 4:41 PM, Sergey Bylokhov wrote: >> >> It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n); >> >> "

    This method may skip more bytes than what are remaining in the >> * backing file. This produces no exception and the number of bytes skipped >> * may include some number of bytes that were beyond the EOF of the >> * backing file. Attempting to read from the stream after skipping past >> * the end will result in -1 indicating the end of the file." > From scolebourne at joda.org Thu Oct 25 10:08:19 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 25 Oct 2018 11:08:19 +0100 Subject: Time-zone database issues In-Reply-To: <6090086a-e8bb-9449-ed71-ce99e1ca0ef5@redhat.com> References: <6090086a-e8bb-9449-ed71-ce99e1ca0ef5@redhat.com> Message-ID: On Thu, 25 Oct 2018 at 09:37, Andrew Haley wrote: > > On 10/22/2018 11:25 PM, Stephen Colebourne wrote: > > The IANA time-zone database [1] provides details of how time-zones > > change over time. The latest release - 2018f - cannot be processed > > successfully by the current JDK parser [2]. A workaround exists > > however unlike previous cases of tzdb incompatibility, this time it > > makes sense for the JDK parser and API to be changed. > > I don't think so. This patch is in the development version of tzdata: > > mm.icann.org/pipermail/tz/attachments/20181018/a1734c98/0001-Avoid-25-00-in-rearguard-format.patch Perhaps I'm not making myself clear enough. We can cope with *this* change either by using rearguard or changing the parser. However, the tzdb author is determined to push ahead with whatever data changes he sees fit (calls for more tzdb backwards compatibility are rejected). At some point, he will add an out of bounds change here that can't be represented in rearguard or in Java. We need to make a change here to protect ourselves from that, and to fix what is in many ways a bug in the Java API - caused by a misunderstanding of their file format. Stephen From thomas.stuefe at gmail.com Thu Oct 25 10:33:17 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 25 Oct 2018 12:33:17 +0200 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> Message-ID: Hi all, the more I mull over this, the more I would prefer to do the jump for real and attempt switch the default to posix_spawn() for Linux. We have theoretically established that both glibc down to 2.4 and muslc since always did "the right thing". We still have time in the 12 time line to test this thoroughly. What do you think? Thanks, Thomas On Wed, Oct 24, 2018 at 10:59 PM Thomas St?fe wrote: > > Hi Roger, > > On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: >> >> Hi Thomas, >> >> Sorry, I had the incantation for multiple tests wrong. >> Separate test configurations need to be in separate /* */ comment blocks. >> BTW, it creates separate .jtr files for each block. >> >> diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java >> --- a/test/jdk/java/lang/ProcessBuilder/Basic.java >> +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java >> @@ -33,8 +33,10 @@ >> * @modules java.base/java.lang:open >> * @run main/othervm/timeout=300 Basic >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >> - * >> + */ >> +/* >> * @test >> + * @modules java.base/java.lang:open >> * @requires (os.family == "linux") >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> * @author Martin Buchholz >> >> >> As for the build configuration being out of scope... >> >> I don't want to see part of the work done and then the rest forgotten or >> worse yet someone comes along in the future and incorrectly believes that >> posix_spawn is ready for production and starts filing bugs or getting bit by something. >> There's a lot more testing to do before it could be come the default >> and perhaps a significant warning should be attached to the code so it does not get forgotten. > > > I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? > > We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. > > We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. > > Do you have an idea how to proceed? > > Thanks, Thomas > >> >> Regards, Roger >> >> >> On 10/24/18 1:53 PM, Thomas St?fe wrote: >> >> Hi Roger, >> >> On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: >> >> Hi Thomas, >> >> Thanks for adding the test. >> >> There's a feature of jtreg that was exposed a couple of month ago that >> can be used to deal with running the test too many times. >> >> There can be multiple @test blocks with different @requires. >> >> * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires >> (os.family == "linux") * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> >> >> Does not seem to work, sorry: >> >> 24 /* >> 25 * @test >> 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 >> 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 >> 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 >> 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 >> 30 * 8067796 >> 31 * @key intermittent >> 32 * @summary Basic tests for Process and Environment Variable code >> 33 * @modules java.base/java.lang:open >> 34 * @run main/othervm/timeout=300 Basic >> 35 * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=fork Basic >> 36 * @test >> 37 * @requires (os.family == "liinux") >> 38 * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> 39 * @author Martin Buchholz >> 40 */ >> >> If I have @requires (os.family == "linux") all three variants are executed - ok. >> >> Then I wanted to have a negative test, so I misnamed linux as "liinux" >> and would have expected the first @test block to fire, the second to >> be ignored. But in fact: >> >> thomas at mainframe /shared/projects/openjdk/jtreg $ >> ../jtreg-prebuilt/jtreg/bin/jtreg -jdk >> ../jdk-jdk/output-slowdebug/images/jdk/ >> ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java >> Test results: no tests selected >> >> So to me it looks like as if the @requires tag is valid for both @test >> blocks, not only the one it appears in. >> >> I'll run this through our build system too. >> >> To fully test out using posix_spawn in many more different scenarios the >> build system should be augmented to be able to use it as the default for >> an entire build/CI/CD/test runs. >> >> Sure! But I think this is out of scope for this patch. >> >> Thanks, Thomas >> >> Thanks, Roger >> >> On 10/24/2018 10:35 AM, Thomas St?fe wrote: >> >> Hi all, >> >> version 2 of Davids patch, with test changes: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ >> >> Executed the test on my local Ubuntu box, works fine. Submit job runs. >> >> About the test: I added a new line: >> >> * @run main/othervm/timeout=300 Basic >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >> + * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> >> The way I understand those tests work is that the first line causes >> the test to be run with the default launch mechanism, the second line >> with jdk.lang.Process.launchMechanism=fork explicitly. The third line, >> added by me, will now explicitly test with posix_spawn. I did not >> limit the platforms, since posix_spawn should now be available on all >> platforms, so it should work on all platforms. But then, on all other >> platforms it has already been the default. >> >> This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism >> gets ignored, so we just executed the same test twice (now three >> times)? And now we execute the posix_spawn variant twice on all >> platforms where this is the default, so line 1 and 3 are the same? You >> see I am not a jtreg expert :) Can I specify a @run directive for only >> one platform? In that case I would limit the explicit posix_spawn test >> to Linux. >> >> Note however that if we really abondon vfork in the future and make >> posix_spawn the default, this test becomes simpler too. >> >> Best, Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: >> >> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: >> >> Review: >> >> - copyright dates need updating on the C-sources >> >> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || >> defined(_AIX) || defined(__linux__)" to be removed completely from >> unix-specific source files. The ifdef now covers all OpenJDK Unix >> platforms. >> >> Here's a version with these changes. >> >> -- >> - DML >> >> From kevin.rushforth at oracle.com Thu Oct 25 13:09:09 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Oct 2018 06:09:09 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: Andy added the a comment [1] to the JEP with the command line options. I'll format it and add it to the JEP itself soon, but until then you can see it in the comments to help you review it. The tests will come shortly (Andy can comment on the state of this). They will be a mix of automated tests and (especially for the installers) manual tests. The module with the API is meant to be a small runtime module that would be jlinked in with the application (whereas the tool itself typically wouldn't be). The working name is jdk.packager.services (inherited from javapacakger). An alternative name we had considered was jdk.packager.runtime? Or maybe jdk.packager.support? Do you have any suggestions? The exported package is named jdk.packager.services.singleton, since the singleton app feature is the only one that currently needs runtime support. The intention would be to add other packages as new features that require runtime support are added in the future (e.g., daemon services or JRE argument support). We haven't given any thought to alternative names, other than if we change the module name to something like jdk.packager.runtime, we would likely want to use that to inform the name of the package. Do you have any recommendations? Perhaps we can discuss the JNLPConverter demo in a separate thread, since I see Erik raised a similar question? Andy can reply to anything I missed or to clarify further. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758?focusedCommentId=14217780&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14217780 On 10/24/2018 7:22 AM, Alan Bateman wrote: > On 23/10/2018 16:49, Andy Herrick wrote: >> This patch implements the Java Packager Tool (jpackager) as described >> in JEP 343: Packaging Tool >> >> >> jpackager is a simple packaging tool, based on the JavaFX >> |javapackager| tool, that: >> >> ?* Supports native packaging formats to give the end user a natural >> ?? installation experience. These formats include |msi| and |exe| on >> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >> ?* Allows launch-time parameters to be specified at packaging time. >> ?* Can be invoked directly, from the command line, or programmatically, >> ?? via the |ToolProvider| API. >> >> Webrev: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >> > cc'ing build-dev as it's important to get it reviewed there. > > What is the plan for tests to go with this tool? I see there is one > test in the webrev to do some argument validation but I don't see > anything else right now. > > What is the status of the JNLPConverter tool? I see it is included as > a "demo" but maybe it would be better to host somewhere else as this > is for developers migrating Java Web Start applications. > > Would it be possible to update the JEP with all the CLI options? That > would be useful for review and also useful for those invoking it with > the ToolProvider API. > > If I read the webrev correctly then it adds two modules, one with the > jpackager tool and the other with an API. It would be useful to get a > bit more information on the split. Also I think the name of the API > module and the package that it exports needs discussion to make sure > that the right names are chosen. > > -Alan From Roger.Riggs at oracle.com Thu Oct 25 13:24:23 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 25 Oct 2018 09:24:23 -0400 Subject: RFR 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator In-Reply-To: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> References: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> Message-ID: <69d9d51f-d050-91ce-9960-4e717badbdf2@oracle.com> Looks good Lance Thanks On 10/24/2018 01:19 PM, Lance Andersen wrote: > Hi all, > > This change removes the finalize methods from java.util.zip.ZipFIle/Inflator/Deflator. These methods were deprecated and marked for removal in JDK 9 > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212129/webrev.00/ > > The relevant JCK tests for zip and jar continue to run clean as do the JDK tier1 - tier3 tests > > The CSR has also been finalized > > Best, > Lance > > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Alan.Bateman at oracle.com Thu Oct 25 13:32:53 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Oct 2018 14:32:53 +0100 Subject: RFR 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator In-Reply-To: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> References: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> Message-ID: <97abc0f0-964f-0974-0837-1dc06b5c68a5@oracle.com> On 24/10/2018 18:19, Lance Andersen wrote: > Hi all, > > This change removes the finalize methods from java.util.zip.ZipFIle/Inflator/Deflator. These methods were deprecated and marked for removal in JDK 9 > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212129/webrev.00/ > > The relevant JCK tests for zip and jar continue to run clean as do the JDK tier1 - tier3 tests > > The CSR has also been finalized > Looks good. A minor nit is that the odd formatting at L200 of Deflater can be fixed as you are changing it. -Alan From lance.andersen at oracle.com Thu Oct 25 13:42:16 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 25 Oct 2018 09:42:16 -0400 Subject: RFR 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator In-Reply-To: <97abc0f0-964f-0974-0837-1dc06b5c68a5@oracle.com> References: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> <97abc0f0-964f-0974-0837-1dc06b5c68a5@oracle.com> Message-ID: <341A5836-3F3A-456F-B060-BB83CCDDA0D5@oracle.com> > On Oct 25, 2018, at 9:32 AM, Alan Bateman wrote: > > > > On 24/10/2018 18:19, Lance Andersen wrote: >> Hi all, >> >> This change removes the finalize methods from java.util.zip.ZipFIle/Inflator/Deflator. These methods were deprecated and marked for removal in JDK 9 >> >> The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212129/webrev.00/ >> >> The relevant JCK tests for zip and jar continue to run clean as do the JDK tier1 - tier3 tests >> >> The CSR has also been finalized >> > Looks good. A minor nit is that the odd formatting at L200 of Deflater can be fixed as you are changing it. Will fix, thank you > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Thu Oct 25 14:15:52 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 25 Oct 2018 10:15:52 -0400 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> Message-ID: <78433376-a509-f430-e65b-f895b3e39555@oracle.com> Hi, The FIS skipping past of end of file is puzzling. If the? 'were beyond EOF' was considering the possibility that the file was being extended concurrently with the skip operation then it would not be random, just a normal writer/reader race.? The return value from skip would be accurate and still usable for skipNBytes. If the spec for skipNBytes describes its behavior in terms of the normal behaviors of skip(n) and read(n) then it will not making promises it can't keep regardless of the subclass behavior. FIS also says it can do negative seeks which seems in conflict with InputStream. The FIS.skip(-n) behavior raises the question about whether InputStream.skipNBytes should allow -n? Roger p.s. There are 200+ subclasses of InputStream in the JDK itself so trying to figure out which ones should have performant versions of skipNBytes would be quite a bit of extra work. On 10/24/2018 08:14 PM, Brian Burkhalter wrote: > Hi Sergey, > > That is rather ugly. Thanks for pointing it out. The previous version which merely repeatedly read and discarded a buffer of bytes did not have this problem, but it also did not take advantage of any performance improvement to be obtained by subclass overriding of skip(). > > It does introduce some randomness into the situation. For example if some FileInputStream with a backing file of length L were used in two different scenarios the results could differ. > > A) skip(L-4) then skipNBytes(8) > B) skip(L) then skipNBytes(4) > > In case A, skipNBytes(8) could conceivably succeed while in case B, skipNBytes(4) could fail, which is inconsistent given that the final positions in stream terms are theoretically identical. > > Unclear what to do here ... > > Thanks, > > Brian > >> On Oct 24, 2018, at 4:41 PM, Sergey Bylokhov wrote: >> >> It looks like the new version will not throw EOFException if the "skip(n)" method will skip more bytes than requested, it is possible for example in FileInputStream.skip(long n); >> >> "

    This method may skip more bytes than what are remaining in the >> * backing file. This produces no exception and the number of bytes skipped >> * may include some number of bytes that were beyond the EOF of the >> * backing file. Attempting to read from the stream after skipping past >> * the end will result in -1 indicating the end of the file." From naoto.sato at oracle.com Thu Oct 25 15:17:36 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 25 Oct 2018 08:17:36 -0700 Subject: Time-zone database issues In-Reply-To: References: Message-ID: Thanks, Stephen. I filed an issue for your suggestion: https://bugs.openjdk.java.net/browse/JDK-8212970 I will need to look into the issue, but so far as I understand, will it be fine to modify the offending transition date to the next day for 2018f's immediate issue? Naoto On 10/22/18 3:25 PM, Stephen Colebourne wrote: > The IANA time-zone database [1] provides details of how time-zones > change over time. The latest release - 2018f - cannot be processed > successfully by the current JDK parser [2]. A workaround exists > however unlike previous cases of tzdb incompatibility, this time it > makes sense for the JDK parser and API to be changed. > > Problem > ----------- > The JDK parser and API make the assumption that a time-zone change can > occur at any LocalTime or midnight-end-of-day, ie. from 00:00 to > 24:00. Unfortunately, the tzdb source files allow (and now include) > rules outside those valid values, in this case a value of 25:00. > Specifically, the rule that causes problems says that clocks change at > 25:00 on the first Saturday on or after the 8th of September. > > In the current problematic case, the rule can be rewritten to say that > clocks change at 01:00 on the first Sunday on or after the 9th of > September. However, there are cases where it is difficult to > impossible to rewrite the rule (such as 25:00 on the last Saturday in > a month, difficult because it goes into the next month). > > Proposed solution > ------------------------ > > Fixing the parser to handle values like 25:00 would be relatively > easy. However, these rules are also exposed in the public API of > java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has > methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need > to be deprecated and replaced by a new method `getLocalTimeDuration()` > (or some other name) that returns an instance of `Duration`. > > A user of ThreeTen-Backport [4] has provided a branch to do this, so I > know the change to be possible. However, since I have looked at the > code I cannot implement the change in OpenJDK (compromised IP). It > needs a cleanroom implementation by someone else. > > Is there agreement on the need for change? Is anyone (Oracle or > otherwise) willing to volunteer do the work? > > thanks > Stephen > > > [1] https://www.iana.org/time-zones > [2] https://bugs.openjdk.java.net/browse/JDK-8212684 > [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time/zone/ZoneOffsetTransitionRule.html > [4] https://www.threeten.org/threetenbp/ > From mandy.chung at oracle.com Thu Oct 25 15:47:54 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Oct 2018 08:47:54 -0700 Subject: Review Request JDK-8212948: Remove unused jdk.internal.misc.VMNotification interface In-Reply-To: <5385be2f-76fd-d051-f7d1-51631bbe4146@oracle.com> References: <5385be2f-76fd-d051-f7d1-51631bbe4146@oracle.com> Message-ID: <4f202d00-5f5c-093a-70f8-ef753852d7c2@oracle.com> On 10/24/18 11:12 PM, Alan Bateman wrote: > On 24/10/2018 23:17, Mandy Chung wrote: >> Remove a leftover file from JDK-8159590 that removed >> jdk.internal.misc.VM.registerVMNotification method taking >> VMNotification parameter. >> >> $ hg remove >> src/java.base/share/classes/jdk/internal/misc/VMNotification.java > Looks okay to me. I assume you've checked that there aren't any tests > using it. Yes, I checked and don't find any. Mandy From rob.mckenna at oracle.com Thu Oct 25 16:34:35 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 25 Oct 2018 17:34:35 +0100 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider Message-ID: <20181025163435.GB4374@vimes> This recently received CSR approval, so it seems like a good time to pick the codereview up again: http://cr.openjdk.java.net/~robm/8160768/webrev.08/ Referencing: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html 1) I'm copying the behaviour from LdapCtxFactory.getInitialContext(Hashtable) where an empty String is the default value used when the provider url is null. I don't think HostnameChecker (by way of SNIHostname) will accept either empty or null values when doing the comparison. Somewhat oddly however, LdapCtx.extendedOperation(ExtendedRequest) appears to pass the String "null" to StartTlsResponseImpl.setConnection(Connection, String), which attempts to substitute null values with the Connections host so there may be a bug here. I'm happy to allow null returns here if necessary. Sean, can you comment on the distinction between null & "" as far as hostname verification is concerned? 2) In the latest iteration lookupEndpoints() returns an Optional. Currently neither getEndpoints() nor getDomainName() can be null. (they can be an empty list and/or an empty String however) 3) Corrected. 4) See https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 -Rob From david.lloyd at redhat.com Thu Oct 25 19:20:24 2018 From: david.lloyd at redhat.com (David Lloyd) Date: Thu, 25 Oct 2018 14:20:24 -0500 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> Message-ID: I'm in favor, for whatever that's worth. On Thu, Oct 25, 2018 at 5:33 AM Thomas St?fe wrote: > > Hi all, > > the more I mull over this, the more I would prefer to do the jump for > real and attempt switch the default to posix_spawn() for Linux. > > We have theoretically established that both glibc down to 2.4 and > muslc since always did "the right thing". > > We still have time in the 12 time line to test this thoroughly. > > What do you think? > > Thanks, Thomas > > On Wed, Oct 24, 2018 at 10:59 PM Thomas St?fe wrote: > > > > Hi Roger, > > > > On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: > >> > >> Hi Thomas, > >> > >> Sorry, I had the incantation for multiple tests wrong. > >> Separate test configurations need to be in separate /* */ comment blocks. > >> BTW, it creates separate .jtr files for each block. > >> > >> diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java > >> --- a/test/jdk/java/lang/ProcessBuilder/Basic.java > >> +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java > >> @@ -33,8 +33,10 @@ > >> * @modules java.base/java.lang:open > >> * @run main/othervm/timeout=300 Basic > >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > >> - * > >> + */ > >> +/* > >> * @test > >> + * @modules java.base/java.lang:open > >> * @requires (os.family == "linux") > >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic > >> * @author Martin Buchholz > >> > >> > >> As for the build configuration being out of scope... > >> > >> I don't want to see part of the work done and then the rest forgotten or > >> worse yet someone comes along in the future and incorrectly believes that > >> posix_spawn is ready for production and starts filing bugs or getting bit by something. > >> There's a lot more testing to do before it could be come the default > >> and perhaps a significant warning should be attached to the code so it does not get forgotten. > > > > > > I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? > > > > We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. > > > > We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. > > > > Do you have an idea how to proceed? > > > > Thanks, Thomas > > > >> > >> Regards, Roger > >> > >> > >> On 10/24/18 1:53 PM, Thomas St?fe wrote: > >> > >> Hi Roger, > >> > >> On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: > >> > >> Hi Thomas, > >> > >> Thanks for adding the test. > >> > >> There's a feature of jtreg that was exposed a couple of month ago that > >> can be used to deal with running the test too many times. > >> > >> There can be multiple @test blocks with different @requires. > >> > >> * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 > >> -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires > >> (os.family == "linux") * @run main/othervm/timeout=300 > >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic > >> > >> > >> Does not seem to work, sorry: > >> > >> 24 /* > >> 25 * @test > >> 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 > >> 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 > >> 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 > >> 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 > >> 30 * 8067796 > >> 31 * @key intermittent > >> 32 * @summary Basic tests for Process and Environment Variable code > >> 33 * @modules java.base/java.lang:open > >> 34 * @run main/othervm/timeout=300 Basic > >> 35 * @run main/othervm/timeout=300 > >> -Djdk.lang.Process.launchMechanism=fork Basic > >> 36 * @test > >> 37 * @requires (os.family == "liinux") > >> 38 * @run main/othervm/timeout=300 > >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic > >> 39 * @author Martin Buchholz > >> 40 */ > >> > >> If I have @requires (os.family == "linux") all three variants are executed - ok. > >> > >> Then I wanted to have a negative test, so I misnamed linux as "liinux" > >> and would have expected the first @test block to fire, the second to > >> be ignored. But in fact: > >> > >> thomas at mainframe /shared/projects/openjdk/jtreg $ > >> ../jtreg-prebuilt/jtreg/bin/jtreg -jdk > >> ../jdk-jdk/output-slowdebug/images/jdk/ > >> ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java > >> Test results: no tests selected > >> > >> So to me it looks like as if the @requires tag is valid for both @test > >> blocks, not only the one it appears in. > >> > >> I'll run this through our build system too. > >> > >> To fully test out using posix_spawn in many more different scenarios the > >> build system should be augmented to be able to use it as the default for > >> an entire build/CI/CD/test runs. > >> > >> Sure! But I think this is out of scope for this patch. > >> > >> Thanks, Thomas > >> > >> Thanks, Roger > >> > >> On 10/24/2018 10:35 AM, Thomas St?fe wrote: > >> > >> Hi all, > >> > >> version 2 of Davids patch, with test changes: > >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ > >> > >> Executed the test on my local Ubuntu box, works fine. Submit job runs. > >> > >> About the test: I added a new line: > >> > >> * @run main/othervm/timeout=300 Basic > >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > >> + * @run main/othervm/timeout=300 > >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic > >> > >> The way I understand those tests work is that the first line causes > >> the test to be run with the default launch mechanism, the second line > >> with jdk.lang.Process.launchMechanism=fork explicitly. The third line, > >> added by me, will now explicitly test with posix_spawn. I did not > >> limit the platforms, since posix_spawn should now be available on all > >> platforms, so it should work on all platforms. But then, on all other > >> platforms it has already been the default. > >> > >> This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism > >> gets ignored, so we just executed the same test twice (now three > >> times)? And now we execute the posix_spawn variant twice on all > >> platforms where this is the default, so line 1 and 3 are the same? You > >> see I am not a jtreg expert :) Can I specify a @run directive for only > >> one platform? In that case I would limit the explicit posix_spawn test > >> to Linux. > >> > >> Note however that if we really abondon vfork in the future and make > >> posix_spawn the default, this test becomes simpler too. > >> > >> Best, Thomas > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > >> > >> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > >> > >> Review: > >> > >> - copyright dates need updating on the C-sources > >> > >> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > >> defined(_AIX) || defined(__linux__)" to be removed completely from > >> unix-specific source files. The ifdef now covers all OpenJDK Unix > >> platforms. > >> > >> Here's a version with these changes. > >> > >> -- > >> - DML > >> > >> -- - DML From xueming.shen at oracle.com Thu Oct 25 19:53:57 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 25 Oct 2018 12:53:57 -0700 Subject: RFR 8212129: Remove finalize methods from java.util.zip.ZipFIle/Inflator/Deflator In-Reply-To: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> References: <5CD5FBE9-6B94-4A7F-8839-381B884271AE@oracle.com> Message-ID: <5BD21F55.90507@oracle.com> +1 A potential "enhancement" for future consideration is whether or not worth to combine DeflaterZFStreamRef/InflaterZFStream back to one class, maybe with a "instanceof" before calling Deflater/Inflater.end(addr). -Sherman On 10/24/18, 10:19 AM, Lance Andersen wrote: > Hi all, > > This change removes the finalize methods from java.util.zip.ZipFIle/Inflator/Deflator. These methods were deprecated and marked for removal in JDK 9 > > The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212129/webrev.00/ > > The relevant JCK tests for zip and jar continue to run clean as do the JDK tier1 - tier3 tests > > The CSR has also been finalized > > Best, > Lance > > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Roger.Riggs at oracle.com Thu Oct 25 20:44:45 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 25 Oct 2018 16:44:45 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> Message-ID: <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> Hi Thomas, In an abundance of caution, I was thinking that it would be a change right at the beginning of a new release so it gets the most exercise and users in early access, etc. And before that it needs to be put into more regular usage and some more unusual environments. The default is currently selected by virtual of being first in the argument list; that doesn't lend itself to being configurable with either configure or make arguments. Roger On 10/25/2018 06:33 AM, Thomas St?fe wrote: > Hi all, > > the more I mull over this, the more I would prefer to do the jump for > real and attempt switch the default to posix_spawn() for Linux. > > We have theoretically established that both glibc down to 2.4 and > muslc since always did "the right thing". > > We still have time in the 12 time line to test this thoroughly. > > What do you think? > > Thanks, Thomas > > On Wed, Oct 24, 2018 at 10:59 PM Thomas St?fe wrote: >> Hi Roger, >> >> On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: >>> Hi Thomas, >>> >>> Sorry, I had the incantation for multiple tests wrong. >>> Separate test configurations need to be in separate /* */ comment blocks. >>> BTW, it creates separate .jtr files for each block. >>> >>> diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java >>> --- a/test/jdk/java/lang/ProcessBuilder/Basic.java >>> +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java >>> @@ -33,8 +33,10 @@ >>> * @modules java.base/java.lang:open >>> * @run main/othervm/timeout=300 Basic >>> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >>> - * >>> + */ >>> +/* >>> * @test >>> + * @modules java.base/java.lang:open >>> * @requires (os.family == "linux") >>> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic >>> * @author Martin Buchholz >>> >>> >>> As for the build configuration being out of scope... >>> >>> I don't want to see part of the work done and then the rest forgotten or >>> worse yet someone comes along in the future and incorrectly believes that >>> posix_spawn is ready for production and starts filing bugs or getting bit by something. >>> There's a lot more testing to do before it could be come the default >>> and perhaps a significant warning should be attached to the code so it does not get forgotten. >> I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? >> >> We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. >> >> We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. >> >> Do you have an idea how to proceed? >> >> Thanks, Thomas >> >>> Regards, Roger >>> >>> >>> On 10/24/18 1:53 PM, Thomas St?fe wrote: >>> >>> Hi Roger, >>> >>> On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: >>> >>> Hi Thomas, >>> >>> Thanks for adding the test. >>> >>> There's a feature of jtreg that was exposed a couple of month ago that >>> can be used to deal with running the test too many times. >>> >>> There can be multiple @test blocks with different @requires. >>> >>> * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 >>> -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires >>> (os.family == "linux") * @run main/othervm/timeout=300 >>> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >>> >>> >>> Does not seem to work, sorry: >>> >>> 24 /* >>> 25 * @test >>> 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 >>> 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 >>> 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 >>> 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 >>> 30 * 8067796 >>> 31 * @key intermittent >>> 32 * @summary Basic tests for Process and Environment Variable code >>> 33 * @modules java.base/java.lang:open >>> 34 * @run main/othervm/timeout=300 Basic >>> 35 * @run main/othervm/timeout=300 >>> -Djdk.lang.Process.launchMechanism=fork Basic >>> 36 * @test >>> 37 * @requires (os.family == "liinux") >>> 38 * @run main/othervm/timeout=300 >>> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >>> 39 * @author Martin Buchholz >>> 40 */ >>> >>> If I have @requires (os.family == "linux") all three variants are executed - ok. >>> >>> Then I wanted to have a negative test, so I misnamed linux as "liinux" >>> and would have expected the first @test block to fire, the second to >>> be ignored. But in fact: >>> >>> thomas at mainframe /shared/projects/openjdk/jtreg $ >>> ../jtreg-prebuilt/jtreg/bin/jtreg -jdk >>> ../jdk-jdk/output-slowdebug/images/jdk/ >>> ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java >>> Test results: no tests selected >>> >>> So to me it looks like as if the @requires tag is valid for both @test >>> blocks, not only the one it appears in. >>> >>> I'll run this through our build system too. >>> >>> To fully test out using posix_spawn in many more different scenarios the >>> build system should be augmented to be able to use it as the default for >>> an entire build/CI/CD/test runs. >>> >>> Sure! But I think this is out of scope for this patch. >>> >>> Thanks, Thomas >>> >>> Thanks, Roger >>> >>> On 10/24/2018 10:35 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> version 2 of Davids patch, with test changes: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ >>> >>> Executed the test on my local Ubuntu box, works fine. Submit job runs. >>> >>> About the test: I added a new line: >>> >>> * @run main/othervm/timeout=300 Basic >>> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >>> + * @run main/othervm/timeout=300 >>> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >>> >>> The way I understand those tests work is that the first line causes >>> the test to be run with the default launch mechanism, the second line >>> with jdk.lang.Process.launchMechanism=fork explicitly. The third line, >>> added by me, will now explicitly test with posix_spawn. I did not >>> limit the platforms, since posix_spawn should now be available on all >>> platforms, so it should work on all platforms. But then, on all other >>> platforms it has already been the default. >>> >>> This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism >>> gets ignored, so we just executed the same test twice (now three >>> times)? And now we execute the posix_spawn variant twice on all >>> platforms where this is the default, so line 1 and 3 are the same? You >>> see I am not a jtreg expert :) Can I specify a @run directive for only >>> one platform? In that case I would limit the explicit posix_spawn test >>> to Linux. >>> >>> Note however that if we really abondon vfork in the future and make >>> posix_spawn the default, this test becomes simpler too. >>> >>> Best, Thomas >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: >>> >>> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: >>> >>> Review: >>> >>> - copyright dates need updating on the C-sources >>> >>> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || >>> defined(_AIX) || defined(__linux__)" to be removed completely from >>> unix-specific source files. The ifdef now covers all OpenJDK Unix >>> platforms. >>> >>> Here's a version with these changes. >>> >>> -- >>> - DML >>> >>> From rob.mckenna at oracle.com Thu Oct 25 20:53:54 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 25 Oct 2018 21:53:54 +0100 Subject: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com> References: <20180903214804.GA2868@vimes> <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com> <20180905010526.GA4025@vimes> <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com> Message-ID: <20181025205354.GD4374@vimes> Thanks Daniel: http://cr.openjdk.java.net/~robm/8139965/webrev.03/ I'm planning to follow up on the test side of things with a separate bug. I think the technique used in some of the recent SQE LDAP tests might be applicable. -Rob On 05/09/18 09:53, Daniel Fuchs wrote: > Hi Rob, > > That looks better but I believe that: > > 1. closed should be volatile since it's read from outside > synchronized block > > 2. it seems there might be a race where the last response > received could be dropped, if the connection is closed > just after it's been pulled from the queue. > > So I would suggest exchanging: > > 115 if (isClosed()) { > 116 return null; > 117 } > 118 > 119 return result; > > with: > > return result == EOF ? null : result; > > best regards, > > -- daniel > > On 05/09/2018 02:05, Rob McKenna wrote: > > Thanks for the reviews folks. > > > > I believe the following captures your recommended changes: > > > > http://cr.openjdk.java.net/~robm/8139965/webrev.02/ > > > > W.r.t. testing I think this area has been difficult to test > > traditionally. I'll have a dig through the existing testbase (and I'll > > get back to you) to see if there's anything similar but afaik most tests > > simply mimic a bindable dummy ldap server. > > > > Vyom, are you aware of any more rigorous tests / ldap test frameworks? > > > > -Rob > > > > On 04/09/18 10:22, Daniel Fuchs wrote: > > > Hi Rob, > > > > > > I concur with Chris. > > > completed needs to be volatile and close() needs to > > > set a flag and use offer like cancel(). > > > > > > The condition for testing for closed then becomes > > > that the flag is set and the queue is empty or has EOF > > > as its head. > > > > > > Is there any way this could be tested by a regression > > > test? > > > > > > best regards, > > > > > > -- daniel > > > > > > On 04/09/2018 10:00, Chris Hegarty wrote: > > > > Rob, > > > > > > > > > On 3 Sep 2018, at 22:48, Rob McKenna wrote: > > > > > > > > > > Hi folks, > > > > > > > > > > I'd like to get a re-review of this change: > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8139965 > > > > > > > > This issue is closed as `will not fix`. I presume you will re-open it before pushing. > > > > > > > > > http://cr.openjdk.java.net/~robm/8139965/webrev/ > > > > > > > > > > > > 43 private boolean completed; > > > > Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted ) > > > > > > > > LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it? > > > > > > > > Please check the indentation of LdapRequest.java L103 ( in > > > > the new file ). It appears, in the webrev, that the trailing `}` is > > > > not lined up. > > > > > > > > The indentation doesn?t look right here either. > > > > 624 if (nparent) { > > > > 625 LdapRequest ldr = pendingRequests; > > > > 626 while (ldr != null) { > > > > 627 ldr.close(); > > > > 628 ldr = ldr.next; > > > > 629 } > > > > 630 } > > > > 631 } > > > > > > > > -Chris > > > > > > > > From joe.darcy at oracle.com Thu Oct 25 21:47:51 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Oct 2018 14:47:51 -0700 Subject: JDK 12 RFR of JDK-6304578: (reflect) toGenericString fails to print bounds of type variables on generic methods In-Reply-To: References: <644c9465-3ea9-cc1b-689a-cbeca90463dc@oracle.com> Message-ID: <2e31be3b-202f-14b1-b33d-fd9fe4d03fd6@oracle.com> Hi Peter, Coming back to this review after my Code One activities this year have run their course... On 10/17/2018 3:07 PM, Peter Levart wrote: > Hi Joe, > > On 10/17/2018 09:16 PM, joe darcy wrote: >> PS In response to some off-list feedback, an updated webrev uses a >> stream-ier implementation: >> >> http://cr.openjdk.java.net/~darcy/6304578.1/ > > I suggest further niceing: > > - if you make typeVarBounds() static, you could use it in Stream.map() > as a method reference. > - in Class.java line 285, you could also use Type::getTypeName method > reference > - in Class.java line 269, wouldn't the output be nicer if the > delimiter in joining collector was ", " instead of "," (with a space > after comma)? > > The same for Executable. > Revised webrev generally taking those suggestions up at: ??? http://cr.openjdk.java.net/~darcy/6304578.2/ Diff of relevant parts of prior version below (screening out unrelated changes to Class made in the interim). The behavior with respect to using a comma as a separator is part of the spec of these methods and I don't want to alter that as part of this change. Thanks, -Joe diff -r 6304578.1/raw_files/new/? 6304578.2/raw_files/new/ diff -r 6304578.1/raw_files/new/src/java.base/share/classes/java/lang/Class.java 6304578.2/raw_files/new/src/java.base/share/classes/java/lang/Class.java 268c268 typeVarBounds(t)). --- > sb.append(Stream.of(typeparms).map(Class::typeVarBounds). 279c279 typeVar) { --- >???? static String typeVarBounds(TypeVariable typeVar) { 285c285 e.getTypeName()). --- >???????? Stream.of(bounds).map(Type::getTypeName). 3413c3413,3414 ???????? StringBuilder sb = new StringBuilder(); >???? sb.append(getName() + "." + name + "("); 3415,3420c3416,3420 c = argTypes[i]; ???????? Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). >???????? collect(Collectors.joining(",")); >???? } >???? sb.append(")"); >???????? return sb.toString(); diff -r 6304578.1/raw_files/new/src/java.base/share/classes/java/lang/reflect/Executable.java 6304578.2/raw_files/new/src/java.base/share/classes/java/lang/reflect/Executable.java 116c116 p.getTypeName()). --- > sb.append(Stream.of(parameterTypes).map(Type::getTypeName). 122c122 e.getTypeName()). --- > sb.append(Stream.of(exceptionTypes).map(Type::getTypeName). 137c137 typeVar) { --- >???? static String typeVarBounds(TypeVariable typeVar) { 143c143 e.getTypeName()). --- >???????? Stream.of(bounds).map(Type::getTypeName). 156c156 typeVarBounds(t)). --- > sb.append(Stream.of(typeparms).map(Executable::typeVarBounds). 176,180c176,177 sb.append(Stream.of(exceptionTypes).map(Type::getTypeName). >?????????????? collect(Collectors.joining(",", " throws ", ""))); From joe.darcy at oracle.com Fri Oct 26 02:02:45 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Oct 2018 19:02:45 -0700 Subject: JDK 12 RFR of JDK-8212081: AnnotatedType.toString implementation don't print annotations on embedded types In-Reply-To: References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> <5c9fab13-f06c-0cba-d3f4-8ee250f94de6@oracle.com> Message-ID: <1cfca04b-8005-0479-6f7c-b93ac8f25258@oracle.com> PS Re-refined implementation at ??? http://cr.openjdk.java.net/~darcy/8212081.1/ The implementation now elides "extends java.lang.Object" in "? extends java.lang.Object" if Object is not annotated and there are no other bounds. The tests were updated to cover this situation too. Thanks, -Joe On 10/16/2018 7:26 PM, Werner Dietl wrote: > Hi Joe, > > thanks for fixing this! I like the improved testing approach. > Changes look good to me, but I'm not a reviewer. > > Best, > cu, WMD. > On Mon, Oct 15, 2018 at 2:11 AM joe darcy wrote: >> Follow-up fix developed; details below. >> >> On 10/11/2018 12:12 PM, joe darcy wrote: >>> Hi Werner, >>> >>> On 10/10/2018 1:23 PM, Werner Dietl wrote: >>>> Hi Joe, all, >>>> >>>> the logic looks good to me. >>>> >>>> In the tests I'm wondering whether to include an annotated wildcard >>>> bound. There is: >>>> >>>> 307 public @AnnotType(11) Set<@AnnotType(13) ? extends Number> >>>> fooNumberSet2() {return null;} >>>> >>>> but nothing like >>>> >>>> Set fooNumberSet2() {return null;} >>>> >>>> I wouldn't expect problems for this, but a test would exercise some of >>>> the code that gets added. >>> You were correct to probe at the bounds on the wildcard components; >>> the code that was reviewed and pushed does not print annotations on >>> the bounds. >>> >>> I'll work on an update to handle this and similar cases where there >>> are embedded types that could have annotations. >>> >> Please review the fix for >> >> JDK-8212081 : AnnotatedType.toString implementation don't print >> annotations on embedded types >> http://cr.openjdk.java.net/~darcy/8212081.1/ >> >> A few notes on the test, the main structural change is that information >> about the expected properties of the toString form of the AnnotatedType >> of a method's return type is stored in a *declaration annotation* on the >> method. The presence of the expected number of type annotations on the >> full string of the AnnotatedType can thus be directly tested. >> >> Thanks, >> >> -Joe From orionllmain at gmail.com Fri Oct 26 06:55:25 2018 From: orionllmain at gmail.com (Zheka Kozlov) Date: Fri, 26 Oct 2018 13:55:25 +0700 Subject: Exceptions in Iterator.forEachRemaining() Message-ID: Hi everyone. I noticed that different Iterator implementations behave differently when an Exception is thrown inside a Consumer passed to forEachRemaining(): private static void test(List list) { Iterator iterator = list.iterator(); try { iterator.forEachRemaining(i -> { if (i == 3) { throw new RuntimeException(); } else { System.out.print(i); } }); } catch (RuntimeException ex) { } iterator.forEachRemaining(System.out::print); } public static void main(String... args) throws Throwable { test(List.of(1, 2, 3, 4, 5)); // Prints 1245 System.out.println(); test(Arrays.asList(1, 2, 3, 4, 5)); // Prints 1245 System.out.println(); test(new LinkedList<>(List.of(1, 2, 3, 4, 5))); // Prints 12345 (BAD) System.out.println(); test(new ArrayList<>(List.of(1, 2, 3, 4, 5))); // Prints 1212345 (BAD) } Is this a bug? I think yes because an overridden forEachRemaining() should behave the same as the default implementation: while (hasNext()) { action.accept(next()); } So, in this case, List.of() and Arrays.asList() are correct while LinkedList and ArrayList are not. From ramanand.patil at oracle.com Fri Oct 26 07:52:19 2018 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 26 Oct 2018 00:52:19 -0700 (PDT) Subject: Time-zone database issues In-Reply-To: References: Message-ID: <8024eebb-13c8-423b-b17d-0da872052976@default> Hi Naoto, Thank you for filing the bug. As far as tzdata2018f release is concerned I am going ahead with the integration, with the help of the patch provided here- https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 in rearguard format. [ https://bugs.openjdk.java.net/browse/JDK-8213016 ] Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Thursday, October 25, 2018 8:48 PM > To: Stephen Colebourne ; core-libs-dev dev at openjdk.java.net> > Subject: Re: Time-zone database issues > > Thanks, Stephen. > > I filed an issue for your suggestion: > > https://bugs.openjdk.java.net/browse/JDK-8212970 > > I will need to look into the issue, but so far as I understand, will it be fine to > modify the offending transition date to the next day for 2018f's immediate > issue? > > Naoto > > On 10/22/18 3:25 PM, Stephen Colebourne wrote: > > The IANA time-zone database [1] provides details of how time-zones > > change over time. The latest release - 2018f - cannot be processed > > successfully by the current JDK parser [2]. A workaround exists > > however unlike previous cases of tzdb incompatibility, this time it > > makes sense for the JDK parser and API to be changed. > > > > Problem > > ----------- > > The JDK parser and API make the assumption that a time-zone change can > > occur at any LocalTime or midnight-end-of-day, ie. from 00:00 to > > 24:00. Unfortunately, the tzdb source files allow (and now include) > > rules outside those valid values, in this case a value of 25:00. > > Specifically, the rule that causes problems says that clocks change at > > 25:00 on the first Saturday on or after the 8th of September. > > > > In the current problematic case, the rule can be rewritten to say that > > clocks change at 01:00 on the first Sunday on or after the 9th of > > September. However, there are cases where it is difficult to > > impossible to rewrite the rule (such as 25:00 on the last Saturday in > > a month, difficult because it goes into the next month). > > > > Proposed solution > > ------------------------ > > > > Fixing the parser to handle values like 25:00 would be relatively > > easy. However, these rules are also exposed in the public API of > > java.time.zone.ZoneOffsetTransitionRule [3]. Currently this class has > > methods `getLocalTime()` and `isMidnightEndOfDay()`. These would need > > to be deprecated and replaced by a new method `getLocalTimeDuration()` > > (or some other name) that returns an instance of `Duration`. > > > > A user of ThreeTen-Backport [4] has provided a branch to do this, so I > > know the change to be possible. However, since I have looked at the > > code I cannot implement the change in OpenJDK (compromised IP). It > > needs a cleanroom implementation by someone else. > > > > Is there agreement on the need for change? Is anyone (Oracle or > > otherwise) willing to volunteer do the work? > > > > thanks > > Stephen > > > > > > [1] https://www.iana.org/time-zones > > [2] https://bugs.openjdk.java.net/browse/JDK-8212684 > > [3] > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/time > > /zone/ZoneOffsetTransitionRule.html > > [4] https://www.threeten.org/threetenbp/ > > From daniel.fuchs at oracle.com Fri Oct 26 08:54:32 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 26 Oct 2018 09:54:32 +0100 Subject: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <20181025205354.GD4374@vimes> References: <20180903214804.GA2868@vimes> <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com> <20180905010526.GA4025@vimes> <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com> <20181025205354.GD4374@vimes> Message-ID: <705c3223-f775-4883-342f-222ab2a946d8@oracle.com> Hi Rob, Now I'm concerned about this method: 71 synchronized boolean addReplyBer(BerDecoder ber) { 72 // check the closed boolean value here as we don't want anything 73 // to be added to the queue after close() has been called. 74 if (cancelled || closed) { 75 return false; 76 } 77 78 // Add a new reply to the queue of unprocessed replies. 79 try { 80 replies.put(ber); 81 } catch (InterruptedException e) { 82 // ignore 83 } 84 85 // peek at the BER buffer to check if it is a SearchResultDone PDU 86 try { 87 ber.parseSeq(null); 88 ber.parseInt(); 89 completed = (ber.peekByte() == LdapClient.LDAP_REP_RESULT); 90 } catch (IOException e) { 91 // ignore 92 } 93 ber.reset(); 94 return pauseAfterReceipt; 95 } getReplyBer() is not synchronized, so AFAICS there is a chance that line 93 executes after another thread as got hold of the `ber` object. Is that an issue? Should the `ber` object be added to the reply queue only after it's been reset? best regards, -- daniel On 25/10/2018 21:53, Rob McKenna wrote: > Thanks Daniel: > > http://cr.openjdk.java.net/~robm/8139965/webrev.03/ > > I'm planning to follow up on the test side of things with a separate > bug. I think the technique used in some of the recent SQE LDAP tests > might be applicable. > > -Rob > > On 05/09/18 09:53, Daniel Fuchs wrote: >> Hi Rob, >> >> That looks better but I believe that: >> >> 1. closed should be volatile since it's read from outside >> synchronized block >> >> 2. it seems there might be a race where the last response >> received could be dropped, if the connection is closed >> just after it's been pulled from the queue. >> >> So I would suggest exchanging: >> >> 115 if (isClosed()) { >> 116 return null; >> 117 } >> 118 >> 119 return result; >> >> with: >> >> return result == EOF ? null : result; >> >> best regards, >> >> -- daniel >> >> On 05/09/2018 02:05, Rob McKenna wrote: >>> Thanks for the reviews folks. >>> >>> I believe the following captures your recommended changes: >>> >>> http://cr.openjdk.java.net/~robm/8139965/webrev.02/ >>> >>> W.r.t. testing I think this area has been difficult to test >>> traditionally. I'll have a dig through the existing testbase (and I'll >>> get back to you) to see if there's anything similar but afaik most tests >>> simply mimic a bindable dummy ldap server. >>> >>> Vyom, are you aware of any more rigorous tests / ldap test frameworks? >>> >>> -Rob >>> >>> On 04/09/18 10:22, Daniel Fuchs wrote: >>>> Hi Rob, >>>> >>>> I concur with Chris. >>>> completed needs to be volatile and close() needs to >>>> set a flag and use offer like cancel(). >>>> >>>> The condition for testing for closed then becomes >>>> that the flag is set and the queue is empty or has EOF >>>> as its head. >>>> >>>> Is there any way this could be tested by a regression >>>> test? >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 04/09/2018 10:00, Chris Hegarty wrote: >>>>> Rob, >>>>> >>>>>> On 3 Sep 2018, at 22:48, Rob McKenna wrote: >>>>>> >>>>>> Hi folks, >>>>>> >>>>>> I'd like to get a re-review of this change: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8139965 >>>>> >>>>> This issue is closed as `will not fix`. I presume you will re-open it before pushing. >>>>> >>>>>> http://cr.openjdk.java.net/~robm/8139965/webrev/ >>>>> >>>>> >>>>> 43 private boolean completed; >>>>> Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted ) >>>>> >>>>> LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it? >>>>> >>>>> Please check the indentation of LdapRequest.java L103 ( in >>>>> the new file ). It appears, in the webrev, that the trailing `}` is >>>>> not lined up. >>>>> >>>>> The indentation doesn?t look right here either. >>>>> 624 if (nparent) { >>>>> 625 LdapRequest ldr = pendingRequests; >>>>> 626 while (ldr != null) { >>>>> 627 ldr.close(); >>>>> 628 ldr = ldr.next; >>>>> 629 } >>>>> 630 } >>>>> 631 } >>>>> >>>>> -Chris >>>>> >>>> >> From scolebourne at joda.org Fri Oct 26 09:41:49 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 26 Oct 2018 10:41:49 +0100 Subject: Time-zone database issues In-Reply-To: <8024eebb-13c8-423b-b17d-0da872052976@default> References: <8024eebb-13c8-423b-b17d-0da872052976@default> Message-ID: On Fri, 26 Oct 2018 at 08:52, Ramanand Patil wrote: > Hi Naoto, > Thank you for filing the bug. As far as tzdata2018f release is concerned I am going ahead with the integration, with the help of the patch provided here- https://mm.icann.org/pipermail/tz/2018-October/027032.html Which avoids 25:00 in rearguard format. > [ https://bugs.openjdk.java.net/browse/JDK-8213016 ] Yes the right course of action for now is to use the patch that avoids 25:00. Thanks Naoto for raising JDK-8212970 to cover the longer term change. Stephen From takiguc at linux.vnet.ibm.com Fri Oct 26 13:34:44 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 26 Oct 2018 22:34:44 +0900 Subject: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset Message-ID: <42481f6da1e503fecbe621593ed93e43@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/ I'd like to obtain a sponsor for this issue. IBM964 charset and IBM29626C charset are required for default charset on AIX zh_TW and ja_JP locale. OpenJDK already has IBM964, but it could not be configured for default charset. IBM29626C is new one. (IBM33722 extends IBM29626C class) I knew IBM charsets would need to move to somewhere. The discussion was started by "Adding new IBM extended charsets". [1] But it's related default charset issue. Please put them inside of OpenJDK. About IBM964, Bhaktavatsal started the discussion [2]. Sherman said that [3] the new model (open/make/data/charetmapping), instead of hard-coding the map into the source code. This fix only has small sized hard-coded mapping, IBM964/IBM29626C/IBM33722 refer other charsets conversion table which are using the new model. And class file is smaller then before. Still I used SimpleEUCEncoder class because it's stable. I think we may re-write it by IBM charsets renewal. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html From martinrb at google.com Fri Oct 26 14:22:35 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 26 Oct 2018 07:22:35 -0700 Subject: Exceptions in Iterator.forEachRemaining() In-Reply-To: References: Message-ID: Mostly my fault, and even more inconsistent than you say. I filed https://bugs.openjdk.java.net/browse/JDK-8213038 (but don't use an iterator after a call to forEachRemaining!) On Thu, Oct 25, 2018 at 11:55 PM, Zheka Kozlov wrote: > Hi everyone. > > I noticed that different Iterator implementations behave differently when > an Exception is thrown inside a Consumer passed to forEachRemaining(): > > private static void test(List list) { > Iterator iterator = list.iterator(); > try { > iterator.forEachRemaining(i -> { > if (i == 3) { > throw new RuntimeException(); > } else { > System.out.print(i); > } > }); > } catch (RuntimeException ex) { > } > iterator.forEachRemaining(System.out::print); > } > > public static void main(String... args) throws Throwable { > test(List.of(1, 2, 3, 4, 5)); // Prints 1245 > System.out.println(); > test(Arrays.asList(1, 2, 3, 4, 5)); // Prints 1245 > System.out.println(); > test(new LinkedList<>(List.of(1, 2, 3, 4, 5))); // Prints 12345 (BAD) > System.out.println(); > test(new ArrayList<>(List.of(1, 2, 3, 4, 5))); // Prints 1212345 (BAD) > } > > Is this a bug? I think yes because an overridden forEachRemaining() should > behave the same as the default implementation: > > while (hasNext()) { > action.accept(next()); > } > > So, in this case, List.of() and Arrays.asList() are correct while > LinkedList and ArrayList are not. > From Alan.Bateman at oracle.com Fri Oct 26 14:34:26 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Oct 2018 15:34:26 +0100 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: <20181025163435.GB4374@vimes> References: <20181025163435.GB4374@vimes> Message-ID: On 25/10/2018 17:34, Rob McKenna wrote: > This recently received CSR approval, so it seems like a good time to pick > the codereview up again: > > http://cr.openjdk.java.net/~robm/8160768/webrev.08/ > I went through a number of iterations with Rob on the API/javadoc so I think the API parts in webrev.08 are good. I have not had time to go through the implementation and test changes so hopefully that someone else has cycles to help on that. -Alan From rob.mckenna at oracle.com Fri Oct 26 14:55:19 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 26 Oct 2018 15:55:19 +0100 Subject: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <705c3223-f775-4883-342f-222ab2a946d8@oracle.com> References: <20180903214804.GA2868@vimes> <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com> <20180905010526.GA4025@vimes> <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com> <20181025205354.GD4374@vimes> <705c3223-f775-4883-342f-222ab2a946d8@oracle.com> Message-ID: <20181026145519.GA3689@vimes> Thanks again Daniel, http://cr.openjdk.java.net/~robm/8139965/webrev.04/ -Rob On 26/10/18 09:54, Daniel Fuchs wrote: > Hi Rob, > > Now I'm concerned about this method: > > 71 synchronized boolean addReplyBer(BerDecoder ber) { > 72 // check the closed boolean value here as we don't want > anything > 73 // to be added to the queue after close() has been called. > 74 if (cancelled || closed) { > 75 return false; > 76 } > 77 > 78 // Add a new reply to the queue of unprocessed replies. > 79 try { > 80 replies.put(ber); > 81 } catch (InterruptedException e) { > 82 // ignore > 83 } > 84 > 85 // peek at the BER buffer to check if it is a SearchResultDone > PDU > 86 try { > 87 ber.parseSeq(null); > 88 ber.parseInt(); > 89 completed = (ber.peekByte() == LdapClient.LDAP_REP_RESULT); > 90 } catch (IOException e) { > 91 // ignore > 92 } > 93 ber.reset(); > 94 return pauseAfterReceipt; > 95 } > > getReplyBer() is not synchronized, so AFAICS there is a > chance that line 93 executes after another thread as got > hold of the `ber` object. > > Is that an issue? Should the `ber` object be added to > the reply queue only after it's been reset? > > best regards, > > -- daniel > > On 25/10/2018 21:53, Rob McKenna wrote: > > Thanks Daniel: > > > > http://cr.openjdk.java.net/~robm/8139965/webrev.03/ > > > > I'm planning to follow up on the test side of things with a separate > > bug. I think the technique used in some of the recent SQE LDAP tests > > might be applicable. > > > > -Rob > > > > On 05/09/18 09:53, Daniel Fuchs wrote: > > > Hi Rob, > > > > > > That looks better but I believe that: > > > > > > 1. closed should be volatile since it's read from outside > > > synchronized block > > > > > > 2. it seems there might be a race where the last response > > > received could be dropped, if the connection is closed > > > just after it's been pulled from the queue. > > > > > > So I would suggest exchanging: > > > > > > 115 if (isClosed()) { > > > 116 return null; > > > 117 } > > > 118 > > > 119 return result; > > > > > > with: > > > > > > return result == EOF ? null : result; > > > > > > best regards, > > > > > > -- daniel > > > > > > On 05/09/2018 02:05, Rob McKenna wrote: > > > > Thanks for the reviews folks. > > > > > > > > I believe the following captures your recommended changes: > > > > > > > > http://cr.openjdk.java.net/~robm/8139965/webrev.02/ > > > > > > > > W.r.t. testing I think this area has been difficult to test > > > > traditionally. I'll have a dig through the existing testbase (and I'll > > > > get back to you) to see if there's anything similar but afaik most tests > > > > simply mimic a bindable dummy ldap server. > > > > > > > > Vyom, are you aware of any more rigorous tests / ldap test frameworks? > > > > > > > > -Rob > > > > > > > > On 04/09/18 10:22, Daniel Fuchs wrote: > > > > > Hi Rob, > > > > > > > > > > I concur with Chris. > > > > > completed needs to be volatile and close() needs to > > > > > set a flag and use offer like cancel(). > > > > > > > > > > The condition for testing for closed then becomes > > > > > that the flag is set and the queue is empty or has EOF > > > > > as its head. > > > > > > > > > > Is there any way this could be tested by a regression > > > > > test? > > > > > > > > > > best regards, > > > > > > > > > > -- daniel > > > > > > > > > > On 04/09/2018 10:00, Chris Hegarty wrote: > > > > > > Rob, > > > > > > > > > > > > > On 3 Sep 2018, at 22:48, Rob McKenna wrote: > > > > > > > > > > > > > > Hi folks, > > > > > > > > > > > > > > I'd like to get a re-review of this change: > > > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8139965 > > > > > > > > > > > > This issue is closed as `will not fix`. I presume you will re-open it before pushing. > > > > > > > > > > > > > http://cr.openjdk.java.net/~robm/8139965/webrev/ > > > > > > > > > > > > > > > > > > 43 private boolean completed; > > > > > > Won?t `completed` need to be volatile now? ( since the removal of synchronized from hasSearchCompleted ) > > > > > > > > > > > > LdapRequest.close puts EOF into the queue, but that is a potentially blocking operation ( while holding the lock ). If the queue is at capacity, then it will block forever. This model will only work if `getReplyBer` is always guaranteed to be running concurrently. Is it? > > > > > > > > > > > > Please check the indentation of LdapRequest.java L103 ( in > > > > > > the new file ). It appears, in the webrev, that the trailing `}` is > > > > > > not lined up. > > > > > > > > > > > > The indentation doesn?t look right here either. > > > > > > 624 if (nparent) { > > > > > > 625 LdapRequest ldr = pendingRequests; > > > > > > 626 while (ldr != null) { > > > > > > 627 ldr.close(); > > > > > > 628 ldr = ldr.next; > > > > > > 629 } > > > > > > 630 } > > > > > > 631 } > > > > > > > > > > > > -Chris > > > > > > > > > > > > > > > From rob.mckenna at oracle.com Fri Oct 26 15:01:58 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 26 Oct 2018 16:01:58 +0100 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: References: <20181025163435.GB4374@vimes> Message-ID: <20181026150158.GB3689@vimes> Yes, thanks a lot Alan. Vyom and Martin both had some very helpful feedback so I'm hoping to hear from both! -Rob On 26/10/18 15:34, Alan Bateman wrote: > On 25/10/2018 17:34, Rob McKenna wrote: > > This recently received CSR approval, so it seems like a good time to pick > > the codereview up again: > > > > http://cr.openjdk.java.net/~robm/8160768/webrev.08/ > > > I went through a number of iterations with Rob on the API/javadoc so I think > the API parts in webrev.08 are good. I have not had time to go through the > implementation and test changes so hopefully that someone else has cycles to > help on that. > > -Alan > From christoph.langer at sap.com Fri Oct 26 15:12:45 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Oct 2018 15:12:45 +0000 Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions Message-ID: Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL ownership and permissions of the files" [1]. With the original proposal I was also addressing the java.util.zip API and the jar tool. However, I've decided to split this endeavor into 2 parts. While I still want to follow up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. Both places don't have dependencies to each other and since zipfs does not change an external API, I guess the bar here is lower. Maybe it is even a candidate for down-porting to jdk11u in the future. After my fix, zipfs will support the PosixFileAttributeView. Posix file attributes can't be fully supported since owner and group are not handled in zip files. So methods supposed to get these attributes will return an UnsupportedOperationException. But the posix permissions will now be correctly handled, that is stored into and read from the zip file. @Sherman: Following suggestions from your review, I removed the test with the binary zip file. I initially thought it is a good idea to test on a well-known file. However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file and reading it again so I guess test coverage is quite complete here. Furthermore, I made some public declarations in ZipUtils package private which should suffice. I also tried to address your performance concerns with permsToFlags and permsFromFlags. In permsToFlags I will now simply iterate to the set of permissions and add the flags to the return value. It's probably more performant than the streaming approach and doesn't look much worse in the code. In permsFromFlags I added a cache of permission sets which should avoid constant calls to the streaming. However, as the return value needs to be mutable, I have to clone the cached permissions. Maybe it would have the same or even better performance if we iteratively fill a new set of permissions each time permsToFlags gets called. What do you think? Do we need a CSR for this patch? Thanks & Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html From daniel.fuchs at oracle.com Fri Oct 26 15:14:49 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 26 Oct 2018 16:14:49 +0100 Subject: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <20181026145519.GA3689@vimes> References: <20180903214804.GA2868@vimes> <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com> <20180905010526.GA4025@vimes> <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com> <20181025205354.GD4374@vimes> <705c3223-f775-4883-342f-222ab2a946d8@oracle.com> <20181026145519.GA3689@vimes> Message-ID: <5137116f-ec7c-3152-1599-1231470c5e14@oracle.com> Hi Rob, Looks better to me know. Though I admit that: 53 this.replies = new LinkedBlockingQueue<>(8 * replyQueueCapacity / 10); is still a bit mystifying... Why not use the full replyQueueCapacity provided? That doesn't look strictly equivalent to the highWatermark logic that you have removed. On 25/10/2018 21:53, Rob McKenna wrote: > I'm planning to follow up on the test side of things with a separate > bug. I think the technique used in some of the recent SQE LDAP tests > might be applicable. It will be good to have a test and try to shake the implementation a bit with some repeating jobs in our test system to get some confidence that we've not harmed anything else. I admit that my only acquaintance to the JNDI/LDAP code of the JDK has been through reviews, so I'd probably only spot the obvious. best regards, -- daniel On 26/10/2018 15:55, Rob McKenna wrote: > Thanks again Daniel, > > http://cr.openjdk.java.net/~robm/8139965/webrev.04/ > > -Rob > From t.linkowski at gmail.com Fri Oct 26 15:44:36 2018 From: t.linkowski at gmail.com (Tomasz Linkowski) Date: Fri, 26 Oct 2018 17:44:36 +0200 Subject: Proposal: Stream.iterateWhile(T seed, Function> mapper) Message-ID: Hi, Please, consider adding a new static method to the `Stream` interface (names TBD): static Stream iterateWhile( T seed, Function> mapper ); == OVERVIEW == + non-null equivalent of `Stream.iterate(seed, hasNext, next)` [1] + `mapper` like in `Optional.flatMap(mapper)` [2] + shift from two operations to one operation, like in: - `Iterator.hasNext/next` => `Spliterator.tryAdvance` - pattern matching (test/bind) + intent: "nudge towards writing clearer code" (Brian Goetz about LVTI [3]) + useful for `Optional`-based APIs + trivial implementation == JUSTIFICATION == `Stream.iterate(seed, hasNext, next)` is great for nullable-return-based APIs. Example: returning a chain of `Throwable` causes: Stream.iterate(throwable, Objects::nonNull, Throwable::getCause) For `Optional`-based APIs, using `Stream.iterate` becomes cumbersome. Example (assume `Throwable.findCause()` returns `Optional`): Stream.iterate(throwable, Objects::nonNull, t -> t.findCause().orElse(null)) Using the proposed method, the above can become much clearer: Stream.iterateWhile(throwable, Throwable::findCause) This is just one example - I can provide more if needed. == IMPLEMENTATION == Preferred implementation: iterateWhile(seed, mapper) -> Stream.iterate( seed, Objects::nonNull, t -> mapper.apply(t).orElse(null) ); Equivalent `Optional`-based implementation: iterateWhile(seed, mapper) -> Stream.iterate( Optional.ofNullable(seed), Optional::isPresent, optional -> optional.flatMap(mapper) ).map(Optional::get); Note that both implementations assume that `null` seed yields an empty `Stream`. == NAMING == Name `iterate` cannot be safely overloaded because of `Stream.iterate(UnaryOperator)` so another name needs to be used. I proposed `iterateWhile` inspired by `takeWhile` but maybe it's a wrong trail (`takeWhile` takes a `Predicate`). Other names that come to my mind: `iterateWhilePresent`, `iterateOptional`, `iterateNonNull`. [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/stream/Stream.html#iterate(T,java.util.function.Predicate,java.util.function.UnaryOperator) [2] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Optional.html#flatMap(java.util.function.Function) [3] http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-October/000826.html -- Regards, Tomasz Linkowski From mandy.chung at oracle.com Fri Oct 26 15:46:52 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Oct 2018 08:46:52 -0700 Subject: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken Message-ID: jsr166 depends on the internal Unsafe xxxObject methods and is currently broken. Since the rename is motivated by Valhalla, we agree to keep the internal Unsafe xxxObject methods as deprecated in the jdk repo. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00 Mandy From rob.mckenna at oracle.com Fri Oct 26 15:59:13 2018 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 26 Oct 2018 16:59:13 +0100 Subject: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize In-Reply-To: <5137116f-ec7c-3152-1599-1231470c5e14@oracle.com> References: <20180903214804.GA2868@vimes> <909A2AD5-65B7-48A7-952D-66E3DA6EEAC3@oracle.com> <20180905010526.GA4025@vimes> <5ec38dd9-23a1-eec4-7899-b4f0654db221@oracle.com> <20181025205354.GD4374@vimes> <705c3223-f775-4883-342f-222ab2a946d8@oracle.com> <20181026145519.GA3689@vimes> <5137116f-ec7c-3152-1599-1231470c5e14@oracle.com> Message-ID: <20181026155913.GE3689@vimes> On 26/10/18 16:14, Daniel Fuchs wrote: > Hi Rob, > > Looks better to me know. Though I admit that: > > 53 this.replies = new LinkedBlockingQueue<>(8 * > replyQueueCapacity / 10); > > is still a bit mystifying... Why not use the full > replyQueueCapacity provided? That doesn't look > strictly equivalent to the highWatermark logic that > you have removed. Pavel may be able to shed more light on this part. (as it was his suggested fix originally I believe) It looks to me like the intention is to mimic the pre-fix behaviour, which only allowed the queue to fill to 80% of its capacity before pausing. I agree though, it doesn't really make sense to keep that. I'll remove it. > > On 25/10/2018 21:53, Rob McKenna wrote: > > I'm planning to follow up on the test side of things with a separate > > bug. I think the technique used in some of the recent SQE LDAP tests > > might be applicable. > > It will be good to have a test and try to shake the implementation > a bit with some repeating jobs in our test system to get some > confidence that we've not harmed anything else. You've convinced me to wait until we can get one together. I'll hold off on the push until that point. jdk-tier1-4 pass, but that may not be saying much unfortunately. -Rob > > I admit that my only acquaintance to the JNDI/LDAP code of the JDK > has been through reviews, so I'd probably only spot the obvious. > > best regards, > > -- daniel > > > On 26/10/2018 15:55, Rob McKenna wrote: > > Thanks again Daniel, > > > > http://cr.openjdk.java.net/~robm/8139965/webrev.04/ > > > > -Rob > > > From Alan.Bateman at oracle.com Fri Oct 26 16:11:32 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Oct 2018 17:11:32 +0100 Subject: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken In-Reply-To: References: Message-ID: <1344b606-8dc3-9654-eb72-cbdf62d0f9cc@oracle.com> On 26/10/2018 16:46, Mandy Chung wrote: > jsr166 depends on the internal Unsafe xxxObject methods and is > currently broken. Since the rename is motivated by Valhalla, we agree > to keep the internal Unsafe xxxObject methods as deprecated in the jdk > repo. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00 This looks okay to me. -Alan From Roger.Riggs at oracle.com Fri Oct 26 18:26:03 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 26 Oct 2018 14:26:03 -0400 Subject: JMathConstant submission for upcoming JDK In-Reply-To: References: Message-ID: <0a656721-2adb-9880-15d0-9e0a961889d7@oracle.com> Hi Robert, No doubt a useful list of constants for some developers. Can you elaborate on why you think these constants should be in the JDK and why they are the right constants especially as related to precision and length. I would expect for some applications these would be more precise than they need and hurt performance and for other applications they would not have enough precision. Thanks, Roger On 10/26/18 12:39 PM, robert at liguorisoftware.com wrote: > Hi Chris, > > I wrote this simple utility class you may want to use in an upcoming > version of the JDK.? Btw, I'm the author of the Java Pocket Guide. :) > > Or is there a better place I can submit simple code like this for the > JDK? > > Thanks, Robert > > import java.math.BigDecimal; > > public class JMathConstant { > > ??? private JMathConstant() { > ??? } > > ??? // ZERO, 1/2 AND ONE > ??? public static final BigDecimal ZERO?????????????????? = new > BigDecimal("0.0"); > ??? public static final BigDecimal LANDAUS??????????????? = new > BigDecimal("0.5"); > ??? public static final BigDecimal ONE??????????????????? = new > BigDecimal("1.0"); > ??? public static final BigDecimal LEGENDRE?????????????? = new > BigDecimal("1.0"); > > ??? // SILVER AND GOLD > ??? public static final BigDecimal ARCHIMEDES_RATIO?????? = new > BigDecimal("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! > 927876611 > 1959092164201989"); > ??? public static final BigDecimal UNKNOWN_NAME?????????? = new > BigDecimal("2.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! > 927876611 > 1959092164201989"); > ??? public static final BigDecimal SILVER_RATIO?????????? = new > BigDecimal("2.4142135623730950488"); > ??? public static final BigDecimal PYTHAGORAS???????????? = new > BigDecimal("1.4142135623730950488"); > ??? public static final BigDecimal GOLDEN_RATIO?????????? = new > BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890"); > ??? public static final BigDecimal INVERSE_GOLDEN_RATIO?? = new > BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890"); > > ??? // ADDITIONAL RATIO CONSTANTS > ??? public static final BigDecimal FEIGENBAUMS_RATIO_1???? = new > BigDecimal("4.66920160910299067185320382046620161"); > ??? public static final BigDecimal FEIGENBAUMS_RATIO_2???? = new > BigDecimal("2.50290787509589282228390287321821578"); > > ??? // OTHERS > ??? public static final BigDecimal MEISSEL_MERTENS??????? = new > BigDecimal("0.26149721284764278375542683860869585"); > ??? public static final BigDecimal BERNSTEINS???????????? = new > BigDecimal("0.28016949902386913303"); > ??? public static final BigDecimal GAUSS_KKUZMIN_WIRSING? = new > BigDecimal("0.30366300289873265859744812190155623"); > ??? public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new > BigDecimal("0.35323637185499598454351655043268201"); > ??? public static final BigDecimal OMEGA????????????????? = new > BigDecimal("0.56714329040978387299996866221035555"); > ??? public static final BigDecimal EULER_MASCHERONI?????? = new > BigDecimal("0.57721"); > ??? public static final BigDecimal GOLOMB_DICKMAN???????? = new > BigDecimal("0.6243299885435508709929363831083724"); > ??? public static final BigDecimal CAHEN????????????????? = new > BigDecimal("0.6434105463"); > ??? public static final BigDecimal TWO_PRIME????????????? = new > BigDecimal("0.6601618158468695739281211001455577"); > ??? public static final BigDecimal LAPLANE_LIMIT????????? = new > BigDecimal("0.66274341934918158097474209710925290"); > ??? public static final BigDecimal EMBREE_TREFETHEN?????? = new > BigDecimal("0.70258"); > ??? public static final BigDecimal LANDAU_RAMANUJAN?????? = new > BigDecimal("0.76422365358922066299069873125009232"); > ??? public static final BigDecimal ALLADI_GRINSTEAD?????? = new > BigDecimal("0.8093940205"); > ??? public static final BigDecimal BRUN?????????????????? = new > BigDecimal("0.8705883800"); > ??? public static final BigDecimal CATALANS?????????????? = new > BigDecimal("0.91596559417721901505460351493238411"); > ??? public static final BigDecimal LENGYELS?????????????? = new > BigDecimal("1.0986858055"); > ??? public static final BigDecimal VISWANATHS???????????? = new > BigDecimal("1.13198824"); > ??? public static final BigDecimal APERYS???????????????? = new > BigDecimal("1.20205690315959428539973816151144999"); > ??? public static final BigDecimal GLAISHER_KINKELIN????? = new > BigDecimal("1.2824271291"); > ??? public static final BigDecimal CONWAYS??????????????? = new > BigDecimal("1.30357726903429639125709911215255189"); > ??? public static final BigDecimal MILLS????????????????? = new > BigDecimal("1.30637788386308069046861449260260571"); > ??? public static final BigDecimal PLASTIC??????????????? = new > BigDecimal("1.32471795724474602596090885447809734"); > ??? public static final BigDecimal RAMANUJAN_SOLDNER????? = new > BigDecimal("1.45136923488338105028396848589202744"); > ??? public static final BigDecimal PORTERS??????????????? = new > BigDecimal("1.4670780794"); > ??? public static final BigDecimal BACKHOUSE????????????? = new > BigDecimal("1.45607494858268967139959535111654356"); > ??? public static final BigDecimal LIEBS_SQUARE_ICE?????? = new > BigDecimal("1.5396007178"); > ??? public static final BigDecimal ERDOS_BORWEIN????????? = new > BigDecimal("1.60669515241529176378330152319092458"); > ??? public static final BigDecimal NIVENS???????????????? = new > BigDecimal("1.70521114010536776428855145343450816"); > ??? public static final BigDecimal THEODORUS????????????? = new > BigDecimal("1.73205080756887729352744634150587236"); > ??? public static final BigDecimal BRUNS????????????????? = new > BigDecimal("1.9021605823"); > ??? public static final BigDecimal UNIVERSAL_PARABOLIC??? = new > BigDecimal("2.29558714939263807403429804918949039"); > ??? public static final BigDecimal SIERPINSKI???????????? = new > BigDecimal("2.58498175957925321706589358738317116"); > ??? public static final BigDecimal KHINCHIN?????????????? = new > BigDecimal("2.68545200106530644530971483548179569"); > ??? public static final BigDecimal NAPIERS??????????????? = new > BigDecimal("2.7182818284590452353602874713527"); > ??? public static final BigDecimal FRANSEN_ROBINSON?????? = new > BigDecimal("2.80777024202851936522150118655777293"); > ??? public static final BigDecimal LEVYS????????????????? = new > BigDecimal("3.27582291872181115978768188245384386"); > ??? public static final BigDecimal RECIPROCAL_FIBONACCI?? = new > BigDecimal("3.35988566624317755317201130291892717"); > ??? public static final BigDecimal GRAVITY??????????????? = new > BigDecimal("32.17404856"); // ft/sec^2 > > ??? public static final BigDecimal NEAR_ONE?????????????? = new > BigDecimal("0.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999"); > > > ??? public static final BigDecimal DIVIDE_BY_998001?????? = new > BigDecimal("0.000001002003004005006007008009010011012013014015016017018019020021022023024025026027028029030031032033034035036037038039040041042043044045046047048049050051052053054055056057058059060061062063064065066067068069070071072073074075076077078079080081082083084085086087088089090091092093094095096097098099100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324! > 325326327 > 32832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665! > > 765865966 > 06616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899! > > 909919929 > 93994995996997999"); > > ??? // ALTERNATE NAMES > ??? public static final BigDecimal PI = ARCHIMEDES_RATIO; > > ??? public static void main(String[] args) { > ??????? System.out.println("MEISSEL_MERTENS CONSTANT: " + > MEISSEL_MERTENS); > ??? } > } > > > Robert From ramanand.patil at oracle.com Fri Oct 26 18:30:02 2018 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Fri, 26 Oct 2018 11:30:02 -0700 (PDT) Subject: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f Message-ID: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default> Hi all, Please review the latest TZDATA integration (tzdata2018f) into JDK12. Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ All the TimeZone related tests are passed after integration. Note: The used tzdata files are from the rearguard version of the tzdata2018f release with the patch applied given by the IANA maintainers[1]. This is done to avoid the value "25:00" from the Japanese ZoneRule. But, as proposed by Stephen[2], a fix from JDK side is also required which will be tracked via a new bug [3]. [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/056167.html [3] https://bugs.openjdk.java.net/browse/JDK-8212970 Regards, Ramanand. From andrewluotechnologies at outlook.com Fri Oct 26 18:42:42 2018 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Fri, 26 Oct 2018 18:42:42 +0000 Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions In-Reply-To: References: Message-ID: I'm not a committer/reviewer but noticed something: In ZipUtils.java: private static final Map> permCache = new WeakHashMap<>(); This is static, and is concurrently modified, so will it cause issues if multiple threads are operating on ZIP filesystems (even if they are different objects/ZIP files)? Thanks, -Andrew -----Original Message----- From: core-libs-dev On Behalf Of Langer, Christoph Sent: Friday, October 26, 2018 8:13 AM To: core-libs-dev ; nio-dev ; Xueming Shen Cc: Schmelter, Ralf Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL ownership and permissions of the files" [1]. With the original proposal I was also addressing the java.util.zip API and the jar tool. However, I've decided to split this endeavor into 2 parts. While I still want to follow up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. Both places don't have dependencies to each other and since zipfs does not change an external API, I guess the bar here is lower. Maybe it is even a candidate for down-porting to jdk11u in the future. After my fix, zipfs will support the PosixFileAttributeView. Posix file attributes can't be fully supported since owner and group are not handled in zip files. So methods supposed to get these attributes will return an UnsupportedOperationException. But the posix permissions will now be correctly handled, that is stored into and read from the zip file. @Sherman: Following suggestions from your review, I removed the test with the binary zip file. I initially thought it is a good idea to test on a well-known file. However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file and reading it again so I guess test coverage is quite complete here. Furthermore, I made some public declarations in ZipUtils package private which should suffice. I also tried to address your performance concerns with permsToFlags and permsFromFlags. In permsToFlags I will now simply iterate to the set of permissions and add the flags to the return value. It's probably more performant than the streaming approach and doesn't look much worse in the code. In permsFromFlags I added a cache of permission sets which should avoid constant calls to the streaming. However, as the return value needs to be mutable, I have to clone the cached permissions. Maybe it would have the same or even better performance if we iteratively fill a new set of permissions each time permsToFlags gets called. What do you think? Do we need a CSR for this patch? Thanks & Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html From Roger.Riggs at oracle.com Fri Oct 26 19:12:00 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 26 Oct 2018 15:12:00 -0400 Subject: Fwd: Re: JMathConstant submission for upcoming JDK In-Reply-To: <0a656721-2adb-9880-15d0-9e0a961889d7@oracle.com> References: <0a656721-2adb-9880-15d0-9e0a961889d7@oracle.com> Message-ID: <1f8a4723-3bad-0f01-98f7-807371997e80@oracle.com> [Sorry for the repeat, this time to ensure Robert sees the question] Hi Robert, No doubt a useful list of constants for some developers. Can you elaborate on why you think these constants should be in the JDK and why they are the right constants especially as related to precision and length. I would expect for some applications these would be more precise than they need and hurt performance and for other applications they would not have enough precision. Thanks, Roger On 10/26/18 12:39 PM, robert at liguorisoftware.com wrote: > Hi Chris, > > I wrote this simple utility class you may want to use in an upcoming > version of the JDK.? Btw, I'm the author of the Java Pocket Guide.:) > > Or is there a better place I can submit simple code like this for the JDK? > > Thanks, Robert > > import java.math.BigDecimal; > > public class JMathConstant { > > ??? private JMathConstant() { > ??? } > > ??? // ZERO, 1/2 AND ONE > ??? public static final BigDecimal ZERO?????????????????? = new > BigDecimal("0.0"); > ??? public static final BigDecimal LANDAUS???????????????= new > BigDecimal("0.5"); > ??? public static final BigDecimal ONE??????????????????? = new > BigDecimal("1.0"); > ??? public static final BigDecimal LEGENDRE?????????????? =new > BigDecimal("1.0"); > > ??? // SILVER AND GOLD > ??? public static final BigDecimal ARCHIMEDES_RATIO?????? = new > BigDecimal("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! > 927876611 > 1959092164201989"); > ??? public static final BigDecimal UNKNOWN_NAME?????????? = new > BigDecimal("2.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! > 927876611 > 1959092164201989"); > ??? public static final BigDecimal SILVER_RATIO?????????? = new > BigDecimal("2.4142135623730950488"); > ??? public static final BigDecimal PYTHAGORAS???????????? = new > BigDecimal("1.4142135623730950488"); > ??? public static final BigDecimal GOLDEN_RATIO?????????? = new > BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890"); > ??? public static final BigDecimal INVERSE_GOLDEN_RATIO?? = new > BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890"); > > ??? // ADDITIONAL RATIO CONSTANTS > ??? public static final BigDecimal FEIGENBAUMS_RATIO_1???? = new > BigDecimal("4.66920160910299067185320382046620161"); > ??? public static final BigDecimal FEIGENBAUMS_RATIO_2???? = new > BigDecimal("2.50290787509589282228390287321821578"); > > ??? // OTHERS > ??? public static final BigDecimal MEISSEL_MERTENS??????? = new > BigDecimal("0.26149721284764278375542683860869585"); > ??? public static final BigDecimal BERNSTEINS???????????? = new > BigDecimal("0.28016949902386913303"); > ??? public static final BigDecimal GAUSS_KKUZMIN_WIRSING? = new > BigDecimal("0.30366300289873265859744812190155623"); > ??? public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new > BigDecimal("0.35323637185499598454351655043268201"); > ??? public static final BigDecimal OMEGA????????????????? = new > BigDecimal("0.56714329040978387299996866221035555"); > ??? public static final BigDecimal EULER_MASCHERONI?????? = new > BigDecimal("0.57721"); > ??? public static final BigDecimal GOLOMB_DICKMAN???????? = new > BigDecimal("0.6243299885435508709929363831083724"); > ??? public static final BigDecimal CAHEN????????????????? = new > BigDecimal("0.6434105463"); > ??? public static final BigDecimal TWO_PRIME????????????? = new > BigDecimal("0.6601618158468695739281211001455577"); > ??? public static final BigDecimal LAPLANE_LIMIT????????? = new > BigDecimal("0.66274341934918158097474209710925290"); > ??? public static final BigDecimal EMBREE_TREFETHEN?????? = new > BigDecimal("0.70258"); > ??? public static final BigDecimal LANDAU_RAMANUJAN?????? = new > BigDecimal("0.76422365358922066299069873125009232"); > ??? public static final BigDecimal ALLADI_GRINSTEAD?????? = new > BigDecimal("0.8093940205"); > ??? public static final BigDecimal BRUN?????????????????? = new > BigDecimal("0.8705883800"); > ??? public static final BigDecimal CATALANS?????????????? =new > BigDecimal("0.91596559417721901505460351493238411"); > ??? public static final BigDecimal LENGYELS?????????????? =new > BigDecimal("1.0986858055"); > ??? public static final BigDecimal VISWANATHS???????????? = new > BigDecimal("1.13198824"); > ??? public static final BigDecimal APERYS???????????????? = new > BigDecimal("1.20205690315959428539973816151144999"); > ??? public static final BigDecimal GLAISHER_KINKELIN????? = new > BigDecimal("1.2824271291"); > ??? public static final BigDecimal CONWAYS???????????????= new > BigDecimal("1.30357726903429639125709911215255189"); > ??? public static final BigDecimal MILLS????????????????? = new > BigDecimal("1.30637788386308069046861449260260571"); > ??? public static final BigDecimal PLASTIC???????????????= new > BigDecimal("1.32471795724474602596090885447809734"); > ??? public static final BigDecimal RAMANUJAN_SOLDNER????? = new > BigDecimal("1.45136923488338105028396848589202744"); > ??? public static final BigDecimal PORTERS???????????????= new > BigDecimal("1.4670780794"); > ??? public static final BigDecimal BACKHOUSE????????????? = new > BigDecimal("1.45607494858268967139959535111654356"); > ??? public static final BigDecimal LIEBS_SQUARE_ICE?????? = new > BigDecimal("1.5396007178"); > ??? public static final BigDecimal ERDOS_BORWEIN????????? = new > BigDecimal("1.60669515241529176378330152319092458"); > ??? public static final BigDecimal NIVENS???????????????? = new > BigDecimal("1.70521114010536776428855145343450816"); > ??? public static final BigDecimal THEODORUS????????????? = new > BigDecimal("1.73205080756887729352744634150587236"); > ??? public static final BigDecimal BRUNS????????????????? = new > BigDecimal("1.9021605823"); > ??? public static final BigDecimal UNIVERSAL_PARABOLIC??? = new > BigDecimal("2.29558714939263807403429804918949039"); > ??? public static final BigDecimal SIERPINSKI???????????? = new > BigDecimal("2.58498175957925321706589358738317116"); > ??? public static final BigDecimal KHINCHIN?????????????? =new > BigDecimal("2.68545200106530644530971483548179569"); > ??? public static final BigDecimal NAPIERS???????????????= new > BigDecimal("2.7182818284590452353602874713527"); > ??? public static final BigDecimal FRANSEN_ROBINSON?????? = new > BigDecimal("2.80777024202851936522150118655777293"); > ??? public static final BigDecimal LEVYS????????????????? = new > BigDecimal("3.27582291872181115978768188245384386"); > ??? public static final BigDecimal RECIPROCAL_FIBONACCI?? = new > BigDecimal("3.35988566624317755317201130291892717"); > ??? public static final BigDecimal GRAVITY???????????????= new > BigDecimal("32.17404856"); // ft/sec^2 > > ??? public static final BigDecimal NEAR_ONE?????????????? =new > BigDecimal("0.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! > > 999999999 > 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999"); > > > ??? public static final BigDecimal DIVIDE_BY_998001?????? = new > BigDecimal("0.000001002003004005006007008009010011012013014015016017018019020021022023024025026027028029030031032033034035036037038039040041042043044045046047048049050051052053054055056057058059060061062063064065066067068069070071072073074075076077078079080081082083084085086087088089090091092093094095096097098099100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324! > 325326327 > 32832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665! > > 765865966 > 06616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899! > > 909919929 > 93994995996997999"); > > ??? // ALTERNATE NAMES > ??? public static final BigDecimal PI = ARCHIMEDES_RATIO; > > ??? public static void main(String[] args) { > ??????? System.out.println("MEISSEL_MERTENS CONSTANT: " + > MEISSEL_MERTENS); > ??? } > } > > > Robert From huizhe.wang at oracle.com Fri Oct 26 19:24:30 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Oct 2018 12:24:30 -0700 Subject: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com Message-ID: <5BD369EE.7010705@oracle.com> Hi, Looks like schematron.com is gone. Tested since the issue was reported 3 days ago, each time got a database connection error. Schematron became an ISO standard later after the JAXP specification and this packageinfo page was written, so replacing the link to schematron.com with a pointer to the ISO page. There's no landing page on iso.org, the link is a direct download of the standard. Please review: diff --git a/src/java.xml/share/classes/javax/xml/validation/package-info.java b/src/java.xml/share/classes/javax/xml/validation/package-info.java --- a/src/java.xml/share/classes/javax/xml/validation/package-info.java +++ b/src/java.xml/share/classes/javax/xml/validation/package-info.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -53,13 +53,13 @@ * and an ISO (International Organization * for Standardization) standard. *

    • - *
  • Schematron - + *
  • Schematron - * a rules-based XML schema language. Whereas DTD, WXS, and RNG are designed * to express the structure of a content model, Schematron is designed to * enforce individual rules that are difficult or impossible to express * with other schema languages. Schematron is intended to supplement a * schema written in structural schema language such as the aforementioned. - * Schematron is in the process of becoming an ISO standard. + * Schematron is an ISO standard. *
    • * *

    Thanks, Joe From lance.andersen at oracle.com Fri Oct 26 19:27:29 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 26 Oct 2018 15:27:29 -0400 Subject: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com In-Reply-To: <5BD369EE.7010705@oracle.com> References: <5BD369EE.7010705@oracle.com> Message-ID: <1E32C9C4-D0D4-4FCD-82CD-7B082C33F178@oracle.com> looks OK Joe > On Oct 26, 2018, at 3:24 PM, Joe Wang wrote: > > Hi, > > Looks like schematron.com is gone. Tested since the issue was reported 3 days ago, each time got a database connection error. Schematron became an ISO standard later after the JAXP specification and this packageinfo page was written, so replacing the link to schematron.com with a pointer to the ISO page. There's no landing page on iso.org, the link is a direct download of the standard. > > Please review: > > diff --git a/src/java.xml/share/classes/javax/xml/validation/package-info.java b/src/java.xml/share/classes/javax/xml/validation/package-info.java > --- a/src/java.xml/share/classes/javax/xml/validation/package-info.java > +++ b/src/java.xml/share/classes/javax/xml/validation/package-info.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -53,13 +53,13 @@ > * and an ISO (International Organization > * for Standardization) standard. > * > - *

  • Schematron - > + *
  • Schematron - > * a rules-based XML schema language. Whereas DTD, WXS, and RNG are designed > * to express the structure of a content model, Schematron is designed to > * enforce individual rules that are difficult or impossible to express > * with other schema languages. Schematron is intended to supplement a > * schema written in structural schema language such as the aforementioned. > - * Schematron is in the process of becoming an ISO standard. > + * Schematron is an ISO standard. > *
    • > * > *

    > > > Thanks, > Joe > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From martinrb at google.com Fri Oct 26 19:38:49 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 26 Oct 2018 12:38:49 -0700 Subject: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f In-Reply-To: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default> References: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default> Message-ID: Looks good to me. On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2018f) into JDK12. > Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 > Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ > > All the TimeZone related tests are passed after integration. > > Note: > The used tzdata files are from the rearguard version of the tzdata2018f > release with the patch applied given by the IANA maintainers[1]. > This is done to avoid the value "25:00" from the Japanese ZoneRule. But, > as proposed by Stephen[2], a fix from JDK side is also required which will > be tracked via a new bug [3]. > > [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html > [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018- > October/056167.html > [3] https://bugs.openjdk.java.net/browse/JDK-8212970 > > > Regards, > Ramanand. > From javalists at cbfiddle.com Fri Oct 26 20:09:23 2018 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 26 Oct 2018 13:09:23 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation Message-ID: I noticed the following statement in the JEP: In this latter case, the tool can either create a native package from a previously created application image, or it can create a native package directly. I cannot tell from the command summary whether this option has been implemented or not. Without this feature, the ability to create a signed DMG is not very useful, except in the case where the tool creates exactly the right application image. Alan From naoto.sato at oracle.com Fri Oct 26 20:10:56 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 26 Oct 2018 13:10:56 -0700 Subject: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f In-Reply-To: References: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default> Message-ID: +1 Naoto On 10/26/18 12:38 PM, Martin Buchholz wrote: > Looks good to me. > > On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil > wrote: > >> Hi all, >> Please review the latest TZDATA integration (tzdata2018f) into JDK12. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 >> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ >> >> All the TimeZone related tests are passed after integration. >> >> Note: >> The used tzdata files are from the rearguard version of the tzdata2018f >> release with the patch applied given by the IANA maintainers[1]. >> This is done to avoid the value "25:00" from the Japanese ZoneRule. But, >> as proposed by Stephen[2], a fix from JDK side is also required which will >> be tracked via a new bug [3]. >> >> [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018- >> October/056167.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8212970 >> >> >> Regards, >> Ramanand. >> From hohensee at amazon.com Fri Oct 26 20:16:41 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 26 Oct 2018 20:16:41 +0000 Subject: JMathConstant submission for upcoming JDK In-Reply-To: <45477CFC-5C52-4EE1-9807-CD203A410D25@amazon.com> References: <45477CFC-5C52-4EE1-9807-CD203A410D25@amazon.com> Message-ID: <83FBDD21-9FBD-4D2A-9A69-D0ECA3011D92@amazon.com> Redirecting to core-libs-dev. I filed https://bugs.openjdk.java.net/browse/JDK-8213045. Paul ?On 10/26/18, 10:50 AM, "jdk-dev on behalf of Hohensee, Paul" wrote: This would go to core-libs-dev, and would be a spec change since it adds a class. The concept could be expanded to BigInteger, Long, Integer, etc. Instead of adding a class, one could add these constants directly to BigDecimal (and the others), but that would also be a spec change since it adds public members. You should file a JBS bug. If you don't have access to JBS, I'd be happy to file it for you. Thanks, Paul On 10/26/18, 9:41 AM, "jdk-dev on behalf of robert at liguorisoftware.com" wrote: Hi Chris, I wrote this simple utility class you may want to use in an upcoming version of the JDK. Btw, I'm the author of the Java Pocket Guide. :) Or is there a better place I can submit simple code like this for the JDK? Thanks, Robert import java.math.BigDecimal; public class JMathConstant { private JMathConstant() { } // ZERO, 1/2 AND ONE public static final BigDecimal ZERO = new BigDecimal("0.0"); public static final BigDecimal LANDAUS = new BigDecimal("0.5"); public static final BigDecimal ONE = new BigDecimal("1.0"); public static final BigDecimal LEGENDRE = new BigDecimal("1.0"); // SILVER AND GOLD public static final BigDecimal ARCHIMEDES_RATIO = new BigDecimal("3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019 27876611 1959092164201989"); public static final BigDecimal UNKNOWN_NAME = new BigDecimal("2.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019 27876611 1959092164201989"); public static final BigDecimal SILVER_RATIO = new BigDecimal("2.4142135623730950488"); public static final BigDecimal PYTHAGORAS = new BigDecimal("1.4142135623730950488"); public static final BigDecimal GOLDEN_RATIO = new BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890"); public static final BigDecimal INVERSE_GOLDEN_RATIO = new BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890"); // ADDITIONAL RATIO CONSTANTS public static final BigDecimal FEIGENBAUMS_RATIO_1 = new BigDecimal("4.66920160910299067185320382046620161"); public static final BigDecimal FEIGENBAUMS_RATIO_2 = new BigDecimal("2.50290787509589282228390287321821578"); // OTHERS public static final BigDecimal MEISSEL_MERTENS = new BigDecimal("0.26149721284764278375542683860869585"); public static final BigDecimal BERNSTEINS = new BigDecimal("0.28016949902386913303"); public static final BigDecimal GAUSS_KKUZMIN_WIRSING = new BigDecimal("0.30366300289873265859744812190155623"); public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new BigDecimal("0.35323637185499598454351655043268201"); public static final BigDecimal OMEGA = new BigDecimal("0.56714329040978387299996866221035555"); public static final BigDecimal EULER_MASCHERONI = new BigDecimal("0.57721"); public static final BigDecimal GOLOMB_DICKMAN = new BigDecimal("0.6243299885435508709929363831083724"); public static final BigDecimal CAHEN = new BigDecimal("0.6434105463"); public static final BigDecimal TWO_PRIME = new BigDecimal("0.6601618158468695739281211001455577"); public static final BigDecimal LAPLANE_LIMIT = new BigDecimal("0.66274341934918158097474209710925290"); public static final BigDecimal EMBREE_TREFETHEN = new BigDecimal("0.70258"); public static final BigDecimal LANDAU_RAMANUJAN = new BigDecimal("0.76422365358922066299069873125009232"); public static final BigDecimal ALLADI_GRINSTEAD = new BigDecimal("0.8093940205"); public static final BigDecimal BRUN = new BigDecimal("0.8705883800"); public static final BigDecimal CATALANS = new BigDecimal("0.91596559417721901505460351493238411"); public static final BigDecimal LENGYELS = new BigDecimal("1.0986858055"); public static final BigDecimal VISWANATHS = new BigDecimal("1.13198824"); public static final BigDecimal APERYS = new BigDecimal("1.20205690315959428539973816151144999"); public static final BigDecimal GLAISHER_KINKELIN = new BigDecimal("1.2824271291"); public static final BigDecimal CONWAYS = new BigDecimal("1.30357726903429639125709911215255189"); public static final BigDecimal MILLS = new BigDecimal("1.30637788386308069046861449260260571"); public static final BigDecimal PLASTIC = new BigDecimal("1.32471795724474602596090885447809734"); public static final BigDecimal RAMANUJAN_SOLDNER = new BigDecimal("1.45136923488338105028396848589202744"); public static final BigDecimal PORTERS = new BigDecimal("1.4670780794"); public static final BigDecimal BACKHOUSE = new BigDecimal("1.45607494858268967139959535111654356"); public static final BigDecimal LIEBS_SQUARE_ICE = new BigDecimal("1.5396007178"); public static final BigDecimal ERDOS_BORWEIN = new BigDecimal("1.60669515241529176378330152319092458"); public static final BigDecimal NIVENS = new BigDecimal("1.70521114010536776428855145343450816"); public static final BigDecimal THEODORUS = new BigDecimal("1.73205080756887729352744634150587236"); public static final BigDecimal BRUNS = new BigDecimal("1.9021605823"); public static final BigDecimal UNIVERSAL_PARABOLIC = new BigDecimal("2.29558714939263807403429804918949039"); public static final BigDecimal SIERPINSKI = new BigDecimal("2.58498175957925321706589358738317116"); public static final BigDecimal KHINCHIN = new BigDecimal("2.68545200106530644530971483548179569"); public static final BigDecimal NAPIERS = new BigDecimal("2.7182818284590452353602874713527"); public static final BigDecimal FRANSEN_ROBINSON = new BigDecimal("2.80777024202851936522150118655777293"); public static final BigDecimal LEVYS = new BigDecimal("3.27582291872181115978768188245384386"); public static final BigDecimal RECIPROCAL_FIBONACCI = new BigDecimal("3.35988566624317755317201130291892717"); public static final BigDecimal GRAVITY = new BigDecimal("32.17404856"); // ft/sec^2 public static final BigDecimal NEAR_ONE = new BigDecimal("0.9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 99999999 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999"); public static final BigDecimal DIVIDE_BY_998001 = new BigDecimal("0.0000010020030040050060070080090100110120130140150160170180190200210220230240250260270280290300310320330340350360370380390400410420430440450460470480490500510520530540550560570580590600610620630640650660670680690700710720730740750760770780790800810820830840850860870880890900910920930940950960970980991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243 25326327 328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657 65865966 066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999 09919929 93994995996997999"); // ALTERNATE NAMES public static final BigDecimal PI = ARCHIMEDES_RATIO; public static void main(String[] args) { System.out.println("MEISSEL_MERTENS CONSTANT: " + MEISSEL_MERTENS); } } Robert From christoph.langer at sap.com Fri Oct 26 20:39:00 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 26 Oct 2018 20:39:00 +0000 Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions In-Reply-To: References: Message-ID: <0a484475700d445d889992f229e4a689@sap.com> Hi Andrew, you might have a point here. I'll revisit that. Thanks Christoph > -----Original Message----- > From: Andrew Luo > Sent: Freitag, 26. Oktober 2018 20:43 > To: Langer, Christoph ; core-libs-dev dev at openjdk.java.net>; nio-dev ; Xueming > Shen > Cc: Schmelter, Ralf > Subject: RE: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File > Permissions > > I'm not a committer/reviewer but noticed something: > > In ZipUtils.java: > > private static final Map> permCache = > new WeakHashMap<>(); > > This is static, and is concurrently modified, so will it cause issues if multiple > threads are operating on ZIP filesystems (even if they are different > objects/ZIP files)? > > Thanks, > > -Andrew > > -----Original Message----- > From: core-libs-dev On Behalf > Of Langer, Christoph > Sent: Friday, October 26, 2018 8:13 AM > To: core-libs-dev ; nio-dev dev at openjdk.java.net>; Xueming Shen > Cc: Schmelter, Ralf > Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions > > Hi, > > please review this enhancement of jdk.nio.zipfs to support Posix file > permissions. > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 > > I had already posted this change as part of a larger fix for "6194856: Zip Files > lose ALL ownership and permissions of the files" [1]. With the original > proposal I was also addressing the java.util.zip API and the jar tool. However, > I've decided to split this endeavor into 2 parts. While I still want to follow up > on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. > Both places don't have dependencies to each other and since zipfs does not > change an external API, I guess the bar here is lower. Maybe it is even a > candidate for down-porting to jdk11u in the future. > > After my fix, zipfs will support the PosixFileAttributeView. Posix file > attributes can't be fully supported since owner and group are not handled in > zip files. So methods supposed to get these attributes will return an > UnsupportedOperationException. But the posix permissions will now be > correctly handled, that is stored into and read from the zip file. > > @Sherman: > Following suggestions from your review, I removed the test with the binary > zip file. I initially thought it is a good idea to test on a well-known file. > However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip > file and reading it again so I guess test coverage is quite complete here. > Furthermore, I made some public declarations in ZipUtils package private > which should suffice. > I also tried to address your performance concerns with permsToFlags and > permsFromFlags. In permsToFlags I will now simply iterate to the set of > permissions and add the flags to the return value. It's probably more > performant than the streaming approach and doesn't look much worse in the > code. In permsFromFlags I added a cache of permission sets which should > avoid constant calls to the streaming. However, as the return value needs to > be mutable, I have to clone the cached permissions. Maybe it would have > the same or even better performance if we iteratively fill a new set of > permissions each time permsToFlags gets called. What do you think? > > Do we need a CSR for this patch? > > Thanks & Best regards > Christoph > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018- > October/055971.html From brian.burkhalter at oracle.com Fri Oct 26 20:42:56 2018 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Oct 2018 13:42:56 -0700 Subject: 6516099: InputStream.skipFully(int k) to skip exactly k bytes In-Reply-To: <78433376-a509-f430-e65b-f895b3e39555@oracle.com> References: <3f3e2acc-2c8e-04ea-3297-ec9d75cb6450@oracle.com> <7B97B3BE-747A-4528-8A9F-170CAF65CF8A@oracle.com> <8abacff0-fc21-dc9d-2c2b-02f6af4ce1a1@oracle.com> <456A66CA-A06F-4C5E-9666-A0219CBD98C8@oracle.com> <53D15DC9-27DB-45A8-B383-0D189A3C7941@oracle.com> <9EF8A08D-D9C2-4D5D-835A-3E7673621F61@oracle.com> <78433376-a509-f430-e65b-f895b3e39555@oracle.com> Message-ID: Hi Roger, > On Oct 25, 2018, at 7:15 AM, Roger Riggs wrote: > > The FIS skipping past of end of file is puzzling. Quite so. > If the 'were beyond EOF' was considering the possibility that the file was being > extended concurrently with the skip operation then it would not be random, > just a normal writer/reader race. The return value from skip would be accurate > and still usable for skipNBytes. > > If the spec for skipNBytes describes its behavior in terms of the normal behaviors > of skip(n) and read(n) then it will not making promises it can't keep regardless of the subclass behavior. That sounds like a good idea. > FIS also says it can do negative seeks which seems in conflict with InputStream. > The FIS.skip(-n) behavior raises the question about whether InputStream.skipNBytes should > allow -n? Actually I think the specification [1] is inconsistent. On the one hand it states "If n is negative, the method will try to skip backwards.? and on the other ?Throws: IOException - if n is negative ?.?. It?s the throws clause that appears inaccurate, at least on macOS. Output of program below [2] is Position 0 Skipped 1024 / 1024 Position 1024 Skipped -512 / -512 Position 512 This is not actually in conflict with InputStream [3] which states "If n is negative, the skip method for class InputStream always returns 0, and no bytes are skipped. Subclasses may handle the negative value differently.? Ugly stuff. Thanks, Brian [1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/FileInputStream.html#skip(long) [2] FISTest import java.io.FileInputStream; import java.nio.channels.FileChannel; public class FISTest { public static void main(String[] args) throws Exception { FileInputStream fis = new FileInputStream(args[0]); FileChannel fc = fis.getChannel(); System.out.format("Position %d%n", fc.position()); System.out.format("Skipped %d / %d%n", fis.skip(1024), 1024); System.out.format("Position %d%n", fc.position()); System.out.format("Skipped %d / %d%n", fis.skip(-512), -512); System.out.format("Position %d%n", fc.position()); fis.close(); } } [3] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/io/InputStream.html#skip(long) From huizhe.wang at oracle.com Fri Oct 26 20:49:35 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Oct 2018 13:49:35 -0700 Subject: RFR(JDK 12/java.xml) 8212866: Broken link to schematron.com In-Reply-To: <1E32C9C4-D0D4-4FCD-82CD-7B082C33F178@oracle.com> References: <5BD369EE.7010705@oracle.com> <1E32C9C4-D0D4-4FCD-82CD-7B082C33F178@oracle.com> Message-ID: <5BD37DDF.9050403@oracle.com> Thanks Lance! On 10/26/18, 12:27 PM, Lance Andersen wrote: > looks OK Joe > >> On Oct 26, 2018, at 3:24 PM, Joe Wang > > wrote: >> >> Hi, >> >> Looks like schematron.com is gone. Tested >> since the issue was reported 3 days ago, each time got a database >> connection error. Schematron became an ISO standard later after the >> JAXP specification and this packageinfo page was written, so >> replacing the link to schematron.com with a >> pointer to the ISO page. There's no landing page on iso.org >> , the link is a direct download of the standard. >> >> Please review: >> >> diff --git >> a/src/java.xml/share/classes/javax/xml/validation/package-info.java >> b/src/java.xml/share/classes/javax/xml/validation/package-info.java >> --- a/src/java.xml/share/classes/javax/xml/validation/package-info.java >> +++ b/src/java.xml/share/classes/javax/xml/validation/package-info.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2015, 2017, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2015, 2018, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -53,13 +53,13 @@ >> * and an ISO (International >> Organization >> * for Standardization) standard. >> * >> - *

  • > href="http://www.schematron.com/">Schematron - >> + *
  • > href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c055982_ISO_IEC_19757-3_2016.zip">Schematron >> - >> * a rules-based XML schema language. Whereas DTD, WXS, and >> RNG are designed >> * to express the structure of a content model, Schematron is >> designed to >> * enforce individual rules that are difficult or impossible >> to express >> * with other schema languages. Schematron is intended to >> supplement a >> * schema written in structural schema language such as the >> aforementioned. >> - * Schematron is in the process of becoming an ISO standard. >> + * Schematron is > href="http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html">an >> ISO standard. >> *
    • >> * >> *

    >> >> >> Thanks, >> Joe >> >> >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From joe.darcy at oracle.com Fri Oct 26 20:55:51 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 26 Oct 2018 13:55:51 -0700 Subject: Fwd: Re: JMathConstant submission for upcoming JDK In-Reply-To: <1f8a4723-3bad-0f01-98f7-807371997e80@oracle.com> References: <0a656721-2adb-9880-15d0-9e0a961889d7@oracle.com> <1f8a4723-3bad-0f01-98f7-807371997e80@oracle.com> Message-ID: <9d20e081-290a-2a75-9f8b-38fc5c96078f@oracle.com> Hello, I would not support a class with this purpose of this scale to be added to the JDK. BigDecimal has had constants for zero, one, and ten since JDK 5.0 shipped in 2004. I consider myself to have a reasonable math background for a non-mathematician and I don't know what field many of these constants are from. In other words, many of the constants are for more specialized use as opposed to being generally usable. In terms of how the constants are structured, for a BigDecimal-based API I would expect a method that took a MathContext to determine how many digits are needed and under what rounding mode as opposed to a field with a fixed precision (unless the constant is some exactly representable number). For example, it would be a "small matter or programming" to provide methods like ??? BigDecimal pi(MathContext mc) ??? BigDecimal tau(MathContext mc) ??? BigDecimal euler(MathContext mc) that returned suitably rounded approximation of those transcendental values. A value like GRAVITY is a poor fit for BigDecimal; first it depends on the units (SI vs Imperial units) and is subject to adjustment with further scientific investigation. Cheers, -Joe On 10/26/2018 12:12 PM, Roger Riggs wrote: > [Sorry for the repeat, this time to ensure Robert sees the question] > > Hi Robert, > > No doubt a useful list of constants for some developers. > > Can you elaborate on why you think these constants should be in the JDK > and why they are the right constants especially as related to > precision and length. > I would expect for some applications these would be more precise than > they > need and hurt performance and for other applications they would not > have enough > precision. > > Thanks, Roger > > On 10/26/18 12:39 PM, robert at liguorisoftware.com wrote: >> Hi Chris, >> >> I wrote this simple utility class you may want to use in an upcoming >> version of the JDK.? Btw, I'm the author of the Java Pocket Guide.:) >> >> Or is there a better place I can submit simple code like this for the >> JDK? >> >> Thanks, Robert >> >> import java.math.BigDecimal; >> >> public class JMathConstant { >> >> ??? private JMathConstant() { >> ??? } >> >> ??? // ZERO, 1/2 AND ONE >> ??? public static final BigDecimal ZERO?????????????????? = new >> BigDecimal("0.0"); >> ??? public static final BigDecimal LANDAUS???????????????= new >> BigDecimal("0.5"); >> ??? public static final BigDecimal ONE??????????????????? = new >> BigDecimal("1.0"); >> ??? public static final BigDecimal LEGENDRE?????????????? =new >> BigDecimal("1.0"); >> >> ??? // SILVER AND GOLD >> ??? public static final BigDecimal ARCHIMEDES_RATIO?????? = new >> BigDecimal("3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! >> >> 927876611 >> 1959092164201989"); >> ??? public static final BigDecimal UNKNOWN_NAME?????????? = new >> BigDecimal("2.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360011330530548820466521384146951941511609433057270365759591953092186117381932611793105118548074462379962749567351885752724891227938183011949129833673362440656643086021394946395224737190702179860943702770539217176293176752384674818467669405132000568127145263560827785771342757789609173637178721468440901224953430146549585371050792279689258923542019956112129021960864034418159813629774771309960518707211349999998372978049951059731732816096318595024459455346908302642522308253344685035261931188171010003137838752886587533208381420617177669147303598253490428755468731159562863882353787593751957781857780532171226806613001! >> >> 927876611 >> 1959092164201989"); >> ??? public static final BigDecimal SILVER_RATIO?????????? = new >> BigDecimal("2.4142135623730950488"); >> ??? public static final BigDecimal PYTHAGORAS???????????? = new >> BigDecimal("1.4142135623730950488"); >> ??? public static final BigDecimal GOLDEN_RATIO?????????? = new >> BigDecimal("1.61803398874989484820458683436563811772030917980576286213544862270526046281890"); >> >> ??? public static final BigDecimal INVERSE_GOLDEN_RATIO?? = new >> BigDecimal("0.61803398874989484820458683436563811772030917980576286213544862270526046281890"); >> >> >> ??? // ADDITIONAL RATIO CONSTANTS >> ??? public static final BigDecimal FEIGENBAUMS_RATIO_1???? = new >> BigDecimal("4.66920160910299067185320382046620161"); >> ??? public static final BigDecimal FEIGENBAUMS_RATIO_2???? = new >> BigDecimal("2.50290787509589282228390287321821578"); >> >> ??? // OTHERS >> ??? public static final BigDecimal MEISSEL_MERTENS??????? = new >> BigDecimal("0.26149721284764278375542683860869585"); >> ??? public static final BigDecimal BERNSTEINS???????????? = new >> BigDecimal("0.28016949902386913303"); >> ??? public static final BigDecimal GAUSS_KKUZMIN_WIRSING? = new >> BigDecimal("0.30366300289873265859744812190155623"); >> ??? public static final BigDecimal HAFNER_SARNAK_MCCURLEY = new >> BigDecimal("0.35323637185499598454351655043268201"); >> ??? public static final BigDecimal OMEGA????????????????? = new >> BigDecimal("0.56714329040978387299996866221035555"); >> ??? public static final BigDecimal EULER_MASCHERONI?????? = new >> BigDecimal("0.57721"); >> ??? public static final BigDecimal GOLOMB_DICKMAN???????? = new >> BigDecimal("0.6243299885435508709929363831083724"); >> ??? public static final BigDecimal CAHEN????????????????? = new >> BigDecimal("0.6434105463"); >> ??? public static final BigDecimal TWO_PRIME????????????? = new >> BigDecimal("0.6601618158468695739281211001455577"); >> ??? public static final BigDecimal LAPLANE_LIMIT????????? = new >> BigDecimal("0.66274341934918158097474209710925290"); >> ??? public static final BigDecimal EMBREE_TREFETHEN?????? = new >> BigDecimal("0.70258"); >> ??? public static final BigDecimal LANDAU_RAMANUJAN?????? = new >> BigDecimal("0.76422365358922066299069873125009232"); >> ??? public static final BigDecimal ALLADI_GRINSTEAD?????? = new >> BigDecimal("0.8093940205"); >> ??? public static final BigDecimal BRUN?????????????????? = new >> BigDecimal("0.8705883800"); >> ??? public static final BigDecimal CATALANS?????????????? =new >> BigDecimal("0.91596559417721901505460351493238411"); >> ??? public static final BigDecimal LENGYELS?????????????? =new >> BigDecimal("1.0986858055"); >> ??? public static final BigDecimal VISWANATHS???????????? = new >> BigDecimal("1.13198824"); >> ??? public static final BigDecimal APERYS???????????????? = new >> BigDecimal("1.20205690315959428539973816151144999"); >> ??? public static final BigDecimal GLAISHER_KINKELIN????? = new >> BigDecimal("1.2824271291"); >> ??? public static final BigDecimal CONWAYS???????????????= new >> BigDecimal("1.30357726903429639125709911215255189"); >> ??? public static final BigDecimal MILLS????????????????? = new >> BigDecimal("1.30637788386308069046861449260260571"); >> ??? public static final BigDecimal PLASTIC???????????????= new >> BigDecimal("1.32471795724474602596090885447809734"); >> ??? public static final BigDecimal RAMANUJAN_SOLDNER????? = new >> BigDecimal("1.45136923488338105028396848589202744"); >> ??? public static final BigDecimal PORTERS???????????????= new >> BigDecimal("1.4670780794"); >> ??? public static final BigDecimal BACKHOUSE????????????? = new >> BigDecimal("1.45607494858268967139959535111654356"); >> ??? public static final BigDecimal LIEBS_SQUARE_ICE?????? = new >> BigDecimal("1.5396007178"); >> ??? public static final BigDecimal ERDOS_BORWEIN????????? = new >> BigDecimal("1.60669515241529176378330152319092458"); >> ??? public static final BigDecimal NIVENS???????????????? = new >> BigDecimal("1.70521114010536776428855145343450816"); >> ??? public static final BigDecimal THEODORUS????????????? = new >> BigDecimal("1.73205080756887729352744634150587236"); >> ??? public static final BigDecimal BRUNS????????????????? = new >> BigDecimal("1.9021605823"); >> ??? public static final BigDecimal UNIVERSAL_PARABOLIC??? = new >> BigDecimal("2.29558714939263807403429804918949039"); >> ??? public static final BigDecimal SIERPINSKI???????????? = new >> BigDecimal("2.58498175957925321706589358738317116"); >> ??? public static final BigDecimal KHINCHIN?????????????? =new >> BigDecimal("2.68545200106530644530971483548179569"); >> ??? public static final BigDecimal NAPIERS???????????????= new >> BigDecimal("2.7182818284590452353602874713527"); >> ??? public static final BigDecimal FRANSEN_ROBINSON?????? = new >> BigDecimal("2.80777024202851936522150118655777293"); >> ??? public static final BigDecimal LEVYS????????????????? = new >> BigDecimal("3.27582291872181115978768188245384386"); >> ??? public static final BigDecimal RECIPROCAL_FIBONACCI?? = new >> BigDecimal("3.35988566624317755317201130291892717"); >> ??? public static final BigDecimal GRAVITY???????????????= new >> BigDecimal("32.17404856"); // ft/sec^2 >> >> ??? public static final BigDecimal NEAR_ONE?????????????? =new >> BigDecimal("0.999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999! >> >> 999999999 >> 9999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999"); >> >> >> ??? public static final BigDecimal DIVIDE_BY_998001?????? = new >> BigDecimal("0.000001002003004005006007008009010011012013014015016017018019020021022023024025026027028029030031032033034035036037038039040041042043044045046047048049050051052053054055056057058059060061062063064065066067068069070071072073074075076077078079080081082083084085086087088089090091092093094095096097098099100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324! >> >> 325326327 >> 32832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665! >> >> 765865966 >> 06616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899! >> >> 909919929 >> 93994995996997999"); >> >> ??? // ALTERNATE NAMES >> ??? public static final BigDecimal PI = ARCHIMEDES_RATIO; >> >> ??? public static void main(String[] args) { >> ??????? System.out.println("MEISSEL_MERTENS CONSTANT: " + >> MEISSEL_MERTENS); >> ??? } >> } >> >> >> Robert > > From naoto.sato at oracle.com Fri Oct 26 21:00:12 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 26 Oct 2018 14:00:12 -0700 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra Message-ID: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8212941 The proposed fix and CSR (not approved yet) are located at: http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942 This change is intended to loosen the spec of JapaneseEra so that later era additions won't require unnecessary spec changes. This is particularly important for the maintenance releases. Naoto From martinrb at google.com Fri Oct 26 21:09:41 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 26 Oct 2018 14:09:41 -0700 Subject: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken In-Reply-To: References: Message-ID: Thanks for doing this - I tested the patch and it'll work for us. On Fri, Oct 26, 2018 at 8:46 AM, Mandy Chung wrote: > jsr166 depends on the internal Unsafe xxxObject methods and is currently > broken. Since the rename is motivated by Valhalla, we agree to keep the > internal Unsafe xxxObject methods as deprecated in the jdk repo. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00 > > Mandy > From mandy.chung at oracle.com Fri Oct 26 21:28:07 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Oct 2018 14:28:07 -0700 Subject: Request Review: JDK-8213043: Add internal Unsafe xxxObject methods as jsr166 is broken In-Reply-To: References: Message-ID: <2fd10eea-3e8d-70ab-1d2c-978bce786fa1@oracle.com> Great!? I have pushed this changeset. Mandy On 10/26/18 2:09 PM, Martin Buchholz wrote: > Thanks for doing this - I tested the patch and it'll work for us. > > On Fri, Oct 26, 2018 at 8:46 AM, Mandy Chung > wrote: > > jsr166 depends on the internal Unsafe xxxObject methods and is > currently broken. Since the rename is motivated by Valhalla, we > agree to keep the internal Unsafe xxxObject methods as deprecated > in the jdk repo. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8213043/webrev.00 > > > Mandy > > From joe.darcy at oracle.com Fri Oct 26 22:00:14 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 26 Oct 2018 15:00:14 -0700 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> Message-ID: <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> Hi Naoto, I'd like to see a bit some discussion up front about the expected evolution of this class. For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive integers associated with them, etc. " Once a formal name is added for the new era, will that value be serial equivalent to the current new era value being used in the class? Basically, is the name or the int value the basis of the serial identity of a JapaneseEra object? Thanks, -Joe On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8212941 > > The proposed fix and CSR (not approved yet) are located at: > > http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ > https://bugs.openjdk.java.net/browse/JDK-8212942 > > This change is intended to loosen the spec of JapaneseEra so that > later era additions won't require unnecessary spec changes. This is > particularly important for the maintenance releases. > > Naoto From jonathan.gibbons at oracle.com Fri Oct 26 22:10:20 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 26 Oct 2018 15:10:20 -0700 Subject: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module Message-ID: <4910e616-72a2-1565-113a-5780610734de@oracle.com> Please review a couple of very small changes to fix some HTML issues in the generated docs. The first change removes an empty paragraph; the second avoids causing nested tags. JBS: https://bugs.openjdk.java.net/browse/JDK-8213056 -- Jon Changes inline here: $ hg diff diff -r 3a767a000aab src/java.base/share/classes/java/lang/String.java --- a/src/java.base/share/classes/java/lang/String.java Fri Oct 26 13:59:02 2018 -0700 +++ b/src/java.base/share/classes/java/lang/String.java Fri Oct 26 15:06:33 2018 -0700 @@ -2821,7 +2821,6 @@ ????? *

    ????? * If {@code n == 0} then the line remains unchanged. However, line ????? * terminators are still normalized. -???? *

    ????? * ????? * @param n? number of leading ????? *?????????? {@link Character#isWhitespace(int) white space characters} diff -r 3a767a000aab src/java.base/share/classes/java/lang/module/package-info.java --- a/src/java.base/share/classes/java/lang/module/package-info.java Fri Oct 26 13:59:02 2018 -0700 +++ b/src/java.base/share/classes/java/lang/module/package-info.java Fri Oct 26 15:06:33 2018 -0700 @@ -34,7 +34,7 @@ ? * will cause a {@code NullPointerException}, unless otherwise specified.

    ? * ? * - *

    {@index "Module Resolution"}

    + *

    {@index "Module Resolution"}

    ? * ? *

    Resolution is the process of computing how modules depend on each other. ? * The process occurs at compile time and run time.

    From joe.darcy at oracle.com Fri Oct 26 22:11:51 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 26 Oct 2018 15:11:51 -0700 Subject: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module In-Reply-To: <4910e616-72a2-1565-113a-5780610734de@oracle.com> References: <4910e616-72a2-1565-113a-5780610734de@oracle.com> Message-ID: <55446e05-d877-cadf-7c20-6c8664b2059c@oracle.com> +1 -Joe On 10/26/2018 3:10 PM, Jonathan Gibbons wrote: > Please review a couple of very small changes to fix some HTML issues > in the generated docs. > > The first change removes an empty paragraph; the second avoids causing > nested tags. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213056 > > -- Jon > > > > Changes inline here: > > $ hg diff > diff -r 3a767a000aab src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java Fri Oct 26 > 13:59:02 2018 -0700 > +++ b/src/java.base/share/classes/java/lang/String.java Fri Oct 26 > 15:06:33 2018 -0700 > @@ -2821,7 +2821,6 @@ > ????? *

    > ????? * If {@code n == 0} then the line remains unchanged. However, line > ????? * terminators are still normalized. > -???? *

    > ????? * > ????? * @param n? number of leading > ????? *?????????? {@link Character#isWhitespace(int) white space > characters} > diff -r 3a767a000aab > src/java.base/share/classes/java/lang/module/package-info.java > --- a/src/java.base/share/classes/java/lang/module/package-info.java > Fri Oct 26 13:59:02 2018 -0700 > +++ b/src/java.base/share/classes/java/lang/module/package-info.java > Fri Oct 26 15:06:33 2018 -0700 > @@ -34,7 +34,7 @@ > ? * will cause a {@code NullPointerException}, unless otherwise > specified.

    > ? * > ? * > - *

    {@index "Module Resolution"}

    > + *

    {@index "Module Resolution"}

    > ? * > ? *

    Resolution is the process of computing how modules depend on > each other. > ? * The process occurs at compile time and run time.

    > From mandy.chung at oracle.com Fri Oct 26 22:23:52 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Oct 2018 15:23:52 -0700 Subject: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module In-Reply-To: <4910e616-72a2-1565-113a-5780610734de@oracle.com> References: <4910e616-72a2-1565-113a-5780610734de@oracle.com> Message-ID: Looks good. Mandy On 10/26/18 3:10 PM, Jonathan Gibbons wrote: > Please review a couple of very small changes to fix some HTML issues > in the generated docs. > > The first change removes an empty paragraph; the second avoids causing > nested tags. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8213056 > > -- Jon > > > > Changes inline here: > > $ hg diff > diff -r 3a767a000aab src/java.base/share/classes/java/lang/String.java > --- a/src/java.base/share/classes/java/lang/String.java Fri Oct 26 > 13:59:02 2018 -0700 > +++ b/src/java.base/share/classes/java/lang/String.java Fri Oct 26 > 15:06:33 2018 -0700 > @@ -2821,7 +2821,6 @@ > ????? *

    > ????? * If {@code n == 0} then the line remains unchanged. However, line > ????? * terminators are still normalized. > -???? *

    > ????? * > ????? * @param n? number of leading > ????? *?????????? {@link Character#isWhitespace(int) white space > characters} > diff -r 3a767a000aab > src/java.base/share/classes/java/lang/module/package-info.java > --- a/src/java.base/share/classes/java/lang/module/package-info.java > Fri Oct 26 13:59:02 2018 -0700 > +++ b/src/java.base/share/classes/java/lang/module/package-info.java > Fri Oct 26 15:06:33 2018 -0700 > @@ -34,7 +34,7 @@ > ? * will cause a {@code NullPointerException}, unless otherwise > specified.

    > ? * > ? * > - *

    {@index "Module Resolution"}

    > + *

    {@index "Module Resolution"}

    > ? * > ? *

    Resolution is the process of computing how modules depend on > each other. > ? * The process occurs at compile time and run time.

    > From naoto.sato at oracle.com Fri Oct 26 22:47:02 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 26 Oct 2018 15:47:02 -0700 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> Message-ID: Hi Joe, On 10/26/18 3:00 PM, joe darcy wrote: > Hi Naoto, > > I'd like to see a bit some discussion up front about the expected > evolution of this class. > > For example, "once an era is defined, subsequent versions of the API > will add a constant for it. etc. Eras are expected to have consecutive > integers associated with them, etc. " Thanks. Those will clarify the intention of the change more. Will incorporate them. > > Once a formal name is added for the new era, will that value be serial > equivalent to the current new era value being used in the class? > Basically, is the name or the int value the basis of the serial identity > of a JapaneseEra object? Yes to the former question. The "NewEra" era should be equivalent to what's coming after the name is decided. Thus the int value should be the sole identity for the designated era. This will ensure the maintenance releases which cannot backport public singleton instances work without spec change. Naoto > > Thanks, > > -Joe > > > On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8212941 >> >> The proposed fix and CSR (not approved yet) are located at: >> >> http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ >> https://bugs.openjdk.java.net/browse/JDK-8212942 >> >> This change is intended to loosen the spec of JapaneseEra so that >> later era additions won't require unnecessary spec changes. This is >> particularly important for the maintenance releases. >> >> Naoto > From Alan.Bateman at oracle.com Sat Oct 27 07:07:37 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Oct 2018 08:07:37 +0100 Subject: RFR: XXS JDK-8213056,,Nested anchor tags in java.lang.module In-Reply-To: <4910e616-72a2-1565-113a-5780610734de@oracle.com> References: <4910e616-72a2-1565-113a-5780610734de@oracle.com> Message-ID: <1246e2e3-1b1d-963a-f91e-c35b27a6c4dd@oracle.com> On 26/10/2018 23:10, Jonathan Gibbons wrote: > Please review a couple of very small changes to fix some HTML issues > in the generated docs. > > The first change removes an empty paragraph; the second avoids causing > nested tags. Looks good (I had to read the bug to understand how this nested anchor arises as it's not obvious at first). -Alan From thomas.stuefe at gmail.com Sat Oct 27 15:58:46 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 27 Oct 2018 17:58:46 +0200 Subject: RFR(xxs): 8213017: jspawnhelper: need to handle pipe write failure when sending return code Message-ID: May I please have reviews for this trivial patch? On Linux, I get compiler warnings when building the jspawnhelper. It complains about not checking the return code to write when communicating an error code back to be parent. I decided to just fix it since this is indeed a bug. But there is no real way to produce error output since stdout/err are redirected. So I decided to just exit with a clear error code instead. bug: https://bugs.openjdk.java.net/browse/JDK-8213017 cr: http://cr.openjdk.java.net/~stuefe/webrevs/8213017-jspawnhelper-write-return- code/webrev_0/webrev/ Thanks, Thomas From martinrb at google.com Sun Oct 28 23:18:10 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 28 Oct 2018 16:18:10 -0700 Subject: Time-zone database issues In-Reply-To: References: <8024eebb-13c8-423b-b17d-0da872052976@default> Message-ID: Aligning the openjdk API with the tzdb format is a good thing to do long term. However, updating old jdk versions is sufficiently difficult (and some people will want to keep jdk6 and jdk9 tzdata up to date for years) that I'm already resigned to using rearguard format "forever". It's a simple strategy that works well, even if we eventually need to make additional modifications to the rearguarding script. Maybe I should care more deeply about getting the exact hour of a timezone transition in 1951 right?! From ying.z.zhou at oracle.com Mon Oct 29 06:55:37 2018 From: ying.z.zhou at oracle.com (Ying Zhou) Date: Mon, 29 Oct 2018 14:55:37 +0800 Subject: [12]RFR of JDK-8210409:Refactor java.util.TimeZone:i18n shell tests to plain java tests Message-ID: <48e78d51-dfd6-229f-5ee9-f020d6e11d20@oracle.com> Hello, test/jdk/java/util/TimeZone/OldIDMappingTest.sh test/jdk/java/util/TimeZone/Bug8066652.sh test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheck.sh Please review this patch to refactor above shell script tests to java. Bug: https://bugs.openjdk.java.net/browse/JDK-8210409 Webrev: http://cr.openjdk.java.net/~dzhou/8210409/webrev.00/ Thanks, Daisy From ramanand.patil at oracle.com Mon Oct 29 08:13:03 2018 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 29 Oct 2018 01:13:03 -0700 (PDT) Subject: RFR: 8213016: (tz) Upgrade time-zone data to tzdata2018f In-Reply-To: References: <72882885-c3fc-40d2-b293-5bdb361fa4ba@default> Message-ID: <305200cf-33ec-47dc-9882-0020f518199a@default> Thank you Martin and Naoto for your reviews. Unfortunately, I have to discard this review and start a new review for tzdata2018g, since 2018g is already released now. Regards, Ramanand. > -----Original Message----- > From: Naoto Sato > Sent: Saturday, October 27, 2018 1:41 AM > To: Martin Buchholz ; Ramanand Patil > > Cc: core-libs-dev ; i18n-dev dev at openjdk.java.net> > Subject: Re: RFR: 8213016: (tz) Upgrade time-zone data to > tzdata2018f > > +1 > > Naoto > > On 10/26/18 12:38 PM, Martin Buchholz wrote: > > Looks good to me. > > > > On Fri, Oct 26, 2018 at 11:30 AM, Ramanand Patil > > > > wrote: > > > >> Hi all, > >> Please review the latest TZDATA integration (tzdata2018f) into JDK12. > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213016 > >> Webrev: http://cr.openjdk.java.net/~rpatil/8213016/webrev.00/ > >> > >> All the TimeZone related tests are passed after integration. > >> > >> Note: > >> The used tzdata files are from the rearguard version of the > >> tzdata2018f release with the patch applied given by the IANA > maintainers[1]. > >> This is done to avoid the value "25:00" from the Japanese ZoneRule. > >> But, as proposed by Stephen[2], a fix from JDK side is also required > >> which will be tracked via a new bug [3]. > >> > >> [1] https://mm.icann.org/pipermail/tz/2018-October/027032.html > >> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018- > >> October/056167.html > >> [3] https://bugs.openjdk.java.net/browse/JDK-8212970 > >> > >> > >> Regards, > >> Ramanand. > >> From Alan.Bateman at oracle.com Mon Oct 29 08:30:45 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Oct 2018 08:30:45 +0000 Subject: RFR(xxs): 8213017: jspawnhelper: need to handle pipe write failure when sending return code In-Reply-To: References: Message-ID: <60a7c449-0357-6f9d-863b-25b9eaca5721@oracle.com> On 27/10/2018 16:58, Thomas St?fe wrote: > May I please have reviews for this trivial patch? > > On Linux, I get compiler warnings when building the jspawnhelper. It > complains about not checking the return code to write when > communicating an error code back to be parent. > > I decided to just fix it since this is indeed a bug. But there is no > real way to produce error output since stdout/err are redirected. So I > decided to just exit with a clear error code instead. > > bug: https://bugs.openjdk.java.net/browse/JDK-8213017 > cr: http://cr.openjdk.java.net/~stuefe/webrevs/8213017-jspawnhelper-write-return- > code/webrev_0/webrev/ > I think this is okay to keep the compiler happy. -Alan. From joel.borggren.franck at gmail.com Mon Oct 29 08:52:05 2018 From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=) Date: Mon, 29 Oct 2018 09:52:05 +0100 Subject: JDK 12 RFR of JDK-8212081: AnnotatedType.toString implementation don't print annotations on embedded types In-Reply-To: <1cfca04b-8005-0479-6f7c-b93ac8f25258@oracle.com> References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> <5c9fab13-f06c-0cba-d3f4-8ee250f94de6@oracle.com> <1cfca04b-8005-0479-6f7c-b93ac8f25258@oracle.com> Message-ID: Hi Joe, I suspect you pasted the wrong link, link to updated impl ends in 8212081.2 right? Anyhow, the .2 version looks good. Ship it! Cheers /Joel /Joel On Fri, 26 Oct 2018 at 04:03, joe darcy wrote: > PS Re-refined implementation at > > http://cr.openjdk.java.net/~darcy/8212081.1/ > > The implementation now elides "extends java.lang.Object" in "? extends > java.lang.Object" if Object is not annotated and there are no other bounds. > > The tests were updated to cover this situation too. > > Thanks, > > -Joe > > > On 10/16/2018 7:26 PM, Werner Dietl wrote: > > Hi Joe, > > > > thanks for fixing this! I like the improved testing approach. > > Changes look good to me, but I'm not a reviewer. > > > > Best, > > cu, WMD. > > On Mon, Oct 15, 2018 at 2:11 AM joe darcy wrote: > >> Follow-up fix developed; details below. > >> > >> On 10/11/2018 12:12 PM, joe darcy wrote: > >>> Hi Werner, > >>> > >>> On 10/10/2018 1:23 PM, Werner Dietl wrote: > >>>> Hi Joe, all, > >>>> > >>>> the logic looks good to me. > >>>> > >>>> In the tests I'm wondering whether to include an annotated wildcard > >>>> bound. There is: > >>>> > >>>> 307 public @AnnotType(11) Set<@AnnotType(13) ? extends Number> > >>>> fooNumberSet2() {return null;} > >>>> > >>>> but nothing like > >>>> > >>>> Set fooNumberSet2() {return null;} > >>>> > >>>> I wouldn't expect problems for this, but a test would exercise some of > >>>> the code that gets added. > >>> You were correct to probe at the bounds on the wildcard components; > >>> the code that was reviewed and pushed does not print annotations on > >>> the bounds. > >>> > >>> I'll work on an update to handle this and similar cases where there > >>> are embedded types that could have annotations. > >>> > >> Please review the fix for > >> > >> JDK-8212081 : AnnotatedType.toString implementation don't print > >> annotations on embedded types > >> http://cr.openjdk.java.net/~darcy/8212081.1/ > >> > >> A few notes on the test, the main structural change is that information > >> about the expected properties of the toString form of the AnnotatedType > >> of a method's return type is stored in a *declaration annotation* on the > >> method. The presence of the expected number of type annotations on the > >> full string of the AnnotatedType can thus be directly tested. > >> > >> Thanks, > >> > >> -Joe > > From christoph.langer at sap.com Mon Oct 29 09:26:56 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Oct 2018 09:26:56 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) Message-ID: <5030914b571a449bba7a98152fdc0850@sap.com> Hi, here's an update of my webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.1/ I added synchronization to the updating of permCache in ZipUtils.java to avoid concurrent modifications. As per request from Alan, I'm adding security-dev to get a review from security perspective. Thanks Christoph From: Langer, Christoph Sent: Freitag, 26. Oktober 2018 17:13 To: core-libs-dev ; nio-dev ; 'Xueming Shen' Cc: Schmelter, Ralf ; 'Volker Simonis' Subject: RFR 8213031: Enhance jdk.nio.zipfs to support Posix File Permissions Hi, please review this enhancement of jdk.nio.zipfs to support Posix file permissions. Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8213031.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213031 I had already posted this change as part of a larger fix for "6194856: Zip Files lose ALL ownership and permissions of the files" [1]. With the original proposal I was also addressing the java.util.zip API and the jar tool. However, I've decided to split this endeavor into 2 parts. While I still want to follow up on java.util.zip and jar, I'd like to bring the enhancement to jdk.zipfs in first. Both places don't have dependencies to each other and since zipfs does not change an external API, I guess the bar here is lower. Maybe it is even a candidate for down-porting to jdk11u in the future. After my fix, zipfs will support the PosixFileAttributeView. Posix file attributes can't be fully supported since owner and group are not handled in zip files. So methods supposed to get these attributes will return an UnsupportedOperationException. But the posix permissions will now be correctly handled, that is stored into and read from the zip file. @Sherman: Following suggestions from your review, I removed the test with the binary zip file. I initially thought it is a good idea to test on a well-known file. However, testWriteAndReadArchiveWithPosixPerms tests both, writing a zip file and reading it again so I guess test coverage is quite complete here. Furthermore, I made some public declarations in ZipUtils package private which should suffice. I also tried to address your performance concerns with permsToFlags and permsFromFlags. In permsToFlags I will now simply iterate to the set of permissions and add the flags to the return value. It's probably more performant than the streaming approach and doesn't look much worse in the code. In permsFromFlags I added a cache of permission sets which should avoid constant calls to the streaming. However, as the return value needs to be mutable, I have to clone the cached permissions. Maybe it would have the same or even better performance if we iteratively fill a new set of permissions each time permsToFlags gets called. What do you think? Do we need a CSR for this patch? Thanks & Best regards Christoph [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055971.html From thomas.stuefe at gmail.com Mon Oct 29 11:27:43 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 29 Oct 2018 12:27:43 +0100 Subject: RFR(xxs): 8213017: jspawnhelper: need to handle pipe write failure when sending return code In-Reply-To: <60a7c449-0357-6f9d-863b-25b9eaca5721@oracle.com> References: <60a7c449-0357-6f9d-863b-25b9eaca5721@oracle.com> Message-ID: Thank you Alan. On Mon, Oct 29, 2018 at 9:30 AM Alan Bateman wrote: > > On 27/10/2018 16:58, Thomas St?fe wrote: > > May I please have reviews for this trivial patch? > > > > On Linux, I get compiler warnings when building the jspawnhelper. It > > complains about not checking the return code to write when > > communicating an error code back to be parent. > > > > I decided to just fix it since this is indeed a bug. But there is no > > real way to produce error output since stdout/err are redirected. So I > > decided to just exit with a clear error code instead. > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8213017 > > cr: http://cr.openjdk.java.net/~stuefe/webrevs/8213017-jspawnhelper-write-return- > > code/webrev_0/webrev/ > > > I think this is okay to keep the compiler happy. > > -Alan. From Alan.Bateman at oracle.com Mon Oct 29 12:06:00 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Oct 2018 12:06:00 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) In-Reply-To: <5030914b571a449bba7a98152fdc0850@sap.com> References: <5030914b571a449bba7a98152fdc0850@sap.com> Message-ID: On 29/10/2018 09:26, Langer, Christoph wrote: > : > > As per request from Alan, I?m adding security-dev to get a review from > security perspective. > > For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan From christoph.langer at sap.com Mon Oct 29 14:55:20 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 29 Oct 2018 14:55:20 +0000 Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) In-Reply-To: References: <5030914b571a449bba7a98152fdc0850@sap.com> Message-ID: <85c85aadb98b4b82a9ec0a6ee9cb8fa7@sap.com> Hi Alan, security guys, I've proposed a CSR for this change now: https://bugs.openjdk.java.net/browse/JDK-8213082. I also updated the webrev, simplifying jdk.nio.zipfs.ZipUtils.permsFromFlags and eliminating the WeakHashMap: http://cr.openjdk.java.net/~clanger/webrevs/8213031.2/ Since I've decoupled the changes to java.util.zip and jartool from those in jdk.zipfs, we're discussing only jdk.zipfs here. The implication of my change is that when working with files backed by the nio FileSystemProvider (java.nio.file.spi.FileSystemProvider) named "jar", which is the alias for zipfs, the files will support attributes of type java.nio.file.attribute.PosixFilePermissions ("posix:permissions"). It basically means that some methods of java.nio.file.Files that would return null or UnsupportedOperationException before would find an implementation now. Examples: https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getPosixFilePermissions(java.nio.file.Path,java.nio.file.LinkOption...) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#setPosixFilePermissions(java.nio.file.Path,java.util.Set) https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#readAttributes(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributes.html https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/Files.html#getFileAttributeView(java.nio.file.Path,java.lang.Class,java.nio.file.LinkOption...) * With class https://download.java.net/java/early_access/jdk11/docs/api/java.base/java/nio/file/attribute/PosixFileAttributeView.html Thanks in advance for reviewing. Best regards Christoph From: Alan Bateman Sent: Montag, 29. Oktober 2018 13:06 To: Langer, Christoph ; core-libs-dev ; security-dev at openjdk.java.net; Xueming Shen Cc: Volker Simonis ; Andrew Luo ; nio-dev Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions (was: Enhance jdk.nio.zipfs to support Posix File Permissions) On 29/10/2018 09:26, Langer, Christoph wrote: : As per request from Alan, I'm adding security-dev to get a review from security perspective. For security-dev then I think it would be better to write-up a summary of the overall proposal and the implications for applications/libraries that use the APIs and the jar tool. The security discussion points all relate to capture and propagation of file permissions. -Alan From claes.redestad at oracle.com Mon Oct 29 15:17:12 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 29 Oct 2018 16:17:12 +0100 Subject: RFR: 8213035: Pack MethodHandleInlineStrategy coder and length into a long Message-ID: <80c8b610-e553-d4a5-d91d-ea2b9e5ed6fb@oracle.com> Hi, by packing the coder and length values into a long, and combining the length and coder mixers, we can reduce the number of MHs generated to set up String concatenations. Theoretically we reduce the number of MHs created by up to a third, and real time improvements in startup tests exercising ISC typically hover around 10%. This optimization reverts JDK-8212597[1], so expressions that benefited from that of course sees a smaller or no added benefit. http://cr.openjdk.java.net/~redestad/8213035/jdk.00/ https://bugs.openjdk.java.net/browse/JDK-8213035 I've attached a simple microbenchmark and performance results from running on x64 in the bug: - Significant reduction in work needed to bootstrap a slew of concatenations, both on the initial bootstrap and when repeating similar concatenation shapes. - For C2 the peak performance is more or less the same, with very small differences due slight differences in the generated code (both tiny improvements and tiny regressions). - For C1 we see some regressions on some micros, at worst 1.2x - For interpreter we see improvements around 1.1x on several micros Testing: tier1-2 jdk and hs tests, sanity tested overflow conditions Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8212597 From ramanand.patil at oracle.com Mon Oct 29 15:19:07 2018 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 29 Oct 2018 08:19:07 -0700 (PDT) Subject: RFR: 8213085: (tz) Upgrade time-zone data to tzdata2018g Message-ID: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default> Hi all, Please review the latest TZDATA integration (tzdata2018g) into JDK12. Bug: https://bugs.openjdk.java.net/browse/JDK-8213085 Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. From martinrb at google.com Mon Oct 29 15:58:44 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 29 Oct 2018 08:58:44 -0700 Subject: RFR: 8213085: (tz) Upgrade time-zone data to tzdata2018g In-Reply-To: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default> References: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default> Message-ID: LGTM. On Mon, Oct 29, 2018 at 8:19 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2018g) into JDK12. > Bug: https://bugs.openjdk.java.net/browse/JDK-8213085 > Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/ > > All the TimeZone related tests are passed after integration. > > > Regards, > Ramanand. > From thomas.stuefe at gmail.com Mon Oct 29 16:04:08 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 29 Oct 2018 17:04:08 +0100 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> Message-ID: Hi Roger, On Thu, Oct 25, 2018 at 10:45 PM Roger Riggs wrote: > > Hi Thomas, > > In an abundance of caution, I was thinking that it would be a change right > at the beginning of a new release so it gets the most exercise and > users in early access, etc. > Okay, I understand that. Over the next days I will run tests with posix_spawn enabled by default on our landscape. We have many different Linuxes on different architectures and different levels of glibc, so this is a reasonable test. If I do not encounter red flags, I would consider the posix_spawn path tested well enough to ship it at least as a non-default, experimental option. Like David originally intended. Then, start of next release, we can make it default and see how that goes. Does that sound ok to you? > And before that it needs to be put into more regular usage and > some more unusual environments. The default is currently selected > by virtual of being first in the argument list; that doesn't lend itself > to being configurable with either configure or make arguments. I do not understand the last sentence: it was never my intention of adding a configure option? > > Roger > Thanks, Thomas > > On 10/25/2018 06:33 AM, Thomas St?fe wrote: > > Hi all, > > the more I mull over this, the more I would prefer to do the jump for > real and attempt switch the default to posix_spawn() for Linux. > > We have theoretically established that both glibc down to 2.4 and > muslc since always did "the right thing". > > We still have time in the 12 time line to test this thoroughly. > > What do you think? > > Thanks, Thomas > > On Wed, Oct 24, 2018 at 10:59 PM Thomas St?fe wrote: > > Hi Roger, > > On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: > > Hi Thomas, > > Sorry, I had the incantation for multiple tests wrong. > Separate test configurations need to be in separate /* */ comment blocks. > BTW, it creates separate .jtr files for each block. > > diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java > --- a/test/jdk/java/lang/ProcessBuilder/Basic.java > +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java > @@ -33,8 +33,10 @@ > * @modules java.base/java.lang:open > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > - * > + */ > +/* > * @test > + * @modules java.base/java.lang:open > * @requires (os.family == "linux") > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic > * @author Martin Buchholz > > > As for the build configuration being out of scope... > > I don't want to see part of the work done and then the rest forgotten or > worse yet someone comes along in the future and incorrectly believes that > posix_spawn is ready for production and starts filing bugs or getting bit by something. > There's a lot more testing to do before it could be come the default > and perhaps a significant warning should be attached to the code so it does not get forgotten. > > I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? > > We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. > > We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. > > Do you have an idea how to proceed? > > Thanks, Thomas > > Regards, Roger > > > On 10/24/18 1:53 PM, Thomas St?fe wrote: > > Hi Roger, > > On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: > > Hi Thomas, > > Thanks for adding the test. > > There's a feature of jtreg that was exposed a couple of month ago that > can be used to deal with running the test too many times. > > There can be multiple @test blocks with different @requires. > > * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires > (os.family == "linux") * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > > Does not seem to work, sorry: > > 24 /* > 25 * @test > 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 > 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 > 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 > 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 > 30 * 8067796 > 31 * @key intermittent > 32 * @summary Basic tests for Process and Environment Variable code > 33 * @modules java.base/java.lang:open > 34 * @run main/othervm/timeout=300 Basic > 35 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic > 36 * @test > 37 * @requires (os.family == "liinux") > 38 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > 39 * @author Martin Buchholz > 40 */ > > If I have @requires (os.family == "linux") all three variants are executed - ok. > > Then I wanted to have a negative test, so I misnamed linux as "liinux" > and would have expected the first @test block to fire, the second to > be ignored. But in fact: > > thomas at mainframe /shared/projects/openjdk/jtreg $ > ../jtreg-prebuilt/jtreg/bin/jtreg -jdk > ../jdk-jdk/output-slowdebug/images/jdk/ > ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java > Test results: no tests selected > > So to me it looks like as if the @requires tag is valid for both @test > blocks, not only the one it appears in. > > I'll run this through our build system too. > > To fully test out using posix_spawn in many more different scenarios the > build system should be augmented to be able to use it as the default for > an entire build/CI/CD/test runs. > > Sure! But I think this is out of scope for this patch. > > Thanks, Thomas > > Thanks, Roger > > On 10/24/2018 10:35 AM, Thomas St?fe wrote: > > Hi all, > > version 2 of Davids patch, with test changes: > > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ > > Executed the test on my local Ubuntu box, works fine. Submit job runs. > > About the test: I added a new line: > > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > + * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > The way I understand those tests work is that the first line causes > the test to be run with the default launch mechanism, the second line > with jdk.lang.Process.launchMechanism=fork explicitly. The third line, > added by me, will now explicitly test with posix_spawn. I did not > limit the platforms, since posix_spawn should now be available on all > platforms, so it should work on all platforms. But then, on all other > platforms it has already been the default. > > This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism > gets ignored, so we just executed the same test twice (now three > times)? And now we execute the posix_spawn variant twice on all > platforms where this is the default, so line 1 and 3 are the same? You > see I am not a jtreg expert :) Can I specify a @run directive for only > one platform? In that case I would limit the explicit posix_spawn test > to Linux. > > Note however that if we really abondon vfork in the future and make > posix_spawn the default, this test becomes simpler too. > > Best, Thomas > > > > > > > > > > > > > On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > > On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > > Review: > > - copyright dates need updating on the C-sources > > - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > defined(_AIX) || defined(__linux__)" to be removed completely from > unix-specific source files. The ifdef now covers all OpenJDK Unix > platforms. > > Here's a version with these changes. > > -- > - DML > > > From constantine.plotnikov at gmail.com Fri Oct 26 09:13:11 2018 From: constantine.plotnikov at gmail.com (Constantine Plotnikov) Date: Fri, 26 Oct 2018 12:13:11 +0300 Subject: Proposal Extending API for Streams (or other potentially long builder or chain calls) Message-ID: Hello All! This email was previously filled as a feature request for JDK, I was forwarded here to write it as an email. Currently, if one needs to skip some stage or provide a group of reused stages one to have to do the following: Stream s = collection.stream() .map(a -> doIt(a, bb)) .filter(a -> !a.list().isEmpty()); s = useSecuriytFilter(s, session) return s.collect(Collector.toList()); Or like: return useSecuriytFilter(collection.stream() .map(a -> doIt(a, bb)) .filter(a -> !a.list().isEmpty()) , session); .collect(Collector.toList()); In both cases, readability is of code is not high, as fluent sequence of actions is interrupted. It is suggested to add "process" method to stream like the following signature: default R process(Function, R> body) { return body.apply(this); } Then custom processing could be applied like the following: return collection.stream() .map(a -> doIt(a, bb)) .filter(a -> !a.list().isEmpty() .process( s -> useSecuriytFilter(s, session)) .collect(Collector.toList()); While semantics is the same, the code structure looks much better. Note this proposed change is not about less typing, but about making local processing looking more local, rather than affecting entire processing pipeline visually. The detailed description for motivation is here: https://dzone.com/articles/making-java-fluent-api-more-flexible Some other libraries with processing chain usage pattern like date-time classes in java.util.time could benefit from this too as common blocks of date arithmetic could be reused in more clean way. A possibly better alternative to this functionality is the support for extension methods like in Groovy, Kotlin, or C#, so users will be able to create such methods when needed themselves, not waiting for library designers. I think extension methods are good innovation enablers, as they allow users of JDK or some library to try new API ideas in the practice first, and than to discuss their experience with component authors. Best Regards, Konstantin Plotnikov From michael.osipov at siemens.com Mon Oct 29 11:24:17 2018 From: michael.osipov at siemens.com (Osipov, Michael) Date: Mon, 29 Oct 2018 11:24:17 +0000 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: <20181025163435.GB4374@vimes> References: <20181025163435.GB4374@vimes> Message-ID: <68644224DA0DE64CA5A49838ED219A042EB9A04E@DEFTHW99EJ5MSX.ww902.siemens.net> Thanks Rob, looks fine to me now. Looking forward for a JDK 8 + JDK 11 backport and a testable package for Windows. Michael > -----Original Message----- > From: Rob McKenna > Sent: Thursday, October 25, 2018 6:35 PM > To: core-libs-dev at openjdk.java.net > Cc: Osipov, Michael (GS IT PD LD PLM) ; > sean.mullan at oracle.com > Subject: [RFR] 8160768: Add capability to custom resolve host/domain names > within the default JDNI LDAP provider > > This recently received CSR approval, so it seems like a good time to pick > the codereview up again: > > http://cr.openjdk.java.net/~robm/8160768/webrev.08/ > > Referencing: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html > > 1) I'm copying the behaviour from > LdapCtxFactory.getInitialContext(Hashtable) where an empty String is > the default value used when the provider url is null. > > I don't think HostnameChecker (by way of SNIHostname) will accept either > empty or null values when doing the comparison. > > Somewhat oddly however, LdapCtx.extendedOperation(ExtendedRequest) > appears to pass the String "null" to > StartTlsResponseImpl.setConnection(Connection, String), which attempts > to substitute null values with the Connections host so there may be a bug > here. > > I'm happy to allow null returns here if necessary. Sean, can you > comment on the distinction between null & "" as far as hostname > verification is concerned? > > 2) In the latest iteration lookupEndpoints() returns an > Optional. Currently neither getEndpoints() nor > getDomainName() can be null. (they can be an empty list and/or an empty > String however) > > 3) Corrected. > > 4) See https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 > > -Rob From robert at liguorisoftware.com Sun Oct 28 18:26:21 2018 From: robert at liguorisoftware.com (robert at liguorisoftware.com) Date: Sun, 28 Oct 2018 11:26:21 -0700 Subject: Fwd: Re: JMathConstant submission for upcoming JDK In-Reply-To: <9d20e081-290a-2a75-9f8b-38fc5c96078f@oracle.com> References: <0a656721-2adb-9880-15d0-9e0a961889d7@oracle.com> <1f8a4723-3bad-0f01-98f7-807371997e80@oracle.com> <9d20e081-290a-2a75-9f8b-38fc5c96078f@oracle.com> Message-ID: Here are the measurement systems, as I see them. public enum MeasurementSystem { INTERNATIONAL_SYSTEM_OF_UNITS, METRIC, UNITED_STATES_CUSTOMARY, BRITISH_IMPERIAL } From naoto.sato at oracle.com Mon Oct 29 17:10:55 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 29 Oct 2018 10:10:55 -0700 Subject: RFR: 8213085: (tz) Upgrade time-zone data to tzdata2018g In-Reply-To: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default> References: <0dc83f90-0821-4c40-a6bc-15f86bc768ee@default> Message-ID: Looks good. Thanks for catching up with it quickly. Naoto On 10/29/18 8:19 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2018g) into JDK12. > Bug: https://bugs.openjdk.java.net/browse/JDK-8213085 > Webrev: http://cr.openjdk.java.net/~rpatil/8213085/webrev.00/ > > All the TimeZone related tests are passed after integration. > > > Regards, > Ramanand. > From naoto.sato at oracle.com Mon Oct 29 17:12:40 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 29 Oct 2018 10:12:40 -0700 Subject: [12]RFR of JDK-8210409:Refactor java.util.TimeZone:i18n shell tests to plain java tests In-Reply-To: <48e78d51-dfd6-229f-5ee9-f020d6e11d20@oracle.com> References: <48e78d51-dfd6-229f-5ee9-f020d6e11d20@oracle.com> Message-ID: <291fdd4d-f7b4-3cdb-67ec-65448da763e3@oracle.com> Looks good. Naoto On 10/28/18 11:55 PM, Ying Zhou wrote: > Hello, > > test/jdk/java/util/TimeZone/OldIDMappingTest.sh > test/jdk/java/util/TimeZone/Bug8066652.sh > test/jdk/java/util/TimeZone/TimeZoneDatePermissionCheck.sh > > Please review this patch to refactor above shell script tests to java. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210409 > > Webrev: http://cr.openjdk.java.net/~dzhou/8210409/webrev.00/ > > > Thanks, > > Daisy > > From forax at univ-mlv.fr Mon Oct 29 17:31:42 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 29 Oct 2018 18:31:42 +0100 (CET) Subject: Proposal Extending API for Streams (or other potentially long builder or chain calls) In-Reply-To: References: Message-ID: <624337569.165343.1540834302562.JavaMail.zimbra@u-pem.fr> Jim Laskey ask for a similar feature on String, calling it "transform", so i don't know if it's a good idea or not to add this API, but at least the name should be the same. see http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055532.html cheers, R?mi ----- Mail original ----- > De: "Constantine Plotnikov" > ?: "core-libs-dev" > Envoy?: Vendredi 26 Octobre 2018 11:13:11 > Objet: Proposal Extending API for Streams (or other potentially long builder or chain calls) > Hello All! > > This email was previously filled as a feature request for JDK, I was > forwarded here to write it as an email. > > Currently, if one needs to skip some stage or provide a group of reused > stages one to have to do the following: > > Stream s = collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty()); > s = useSecuriytFilter(s, session) > return s.collect(Collector.toList()); > > Or like: > > return useSecuriytFilter(collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty()) > , session); > .collect(Collector.toList()); > > In both cases, readability is of code is not high, as fluent sequence of > actions is interrupted. > > It is suggested to add "process" method to stream like the following > signature: > > default R process(Function, R> body) { > return body.apply(this); > } > > Then custom processing could be applied like the following: > > return collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty() > .process( s -> useSecuriytFilter(s, session)) > .collect(Collector.toList()); > > While semantics is the same, the code structure looks much better. Note > this proposed change is not about less typing, but about making local > processing looking more local, rather than affecting entire processing > pipeline visually. > > The detailed description for motivation is here: > > https://dzone.com/articles/making-java-fluent-api-more-flexible > > Some other libraries with processing chain usage pattern like date-time > classes in java.util.time could benefit from this too as common blocks of > date arithmetic could be reused in more clean way. > > A possibly better alternative to this functionality is the support for > extension methods like in Groovy, Kotlin, or C#, so users will be able to > create such methods when needed themselves, not waiting for library > designers. I think extension methods are good innovation enablers, as they > allow users of JDK or some library to try new API ideas in the practice > first, and than to discuss their experience with component authors. > > Best Regards, > Konstantin Plotnikov From vladimir.x.ivanov at oracle.com Mon Oct 29 17:37:26 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 29 Oct 2018 10:37:26 -0700 Subject: RFR: 8213035: Pack MethodHandleInlineStrategy coder and length into a long In-Reply-To: <80c8b610-e553-d4a5-d91d-ea2b9e5ed6fb@oracle.com> References: <80c8b610-e553-d4a5-d91d-ea2b9e5ed6fb@oracle.com> Message-ID: <76bf2445-74b4-5c15-e970-abb260e74e64@oracle.com> Looks good. Best regards, Vladimir Ivanov On 29/10/2018 08:17, Claes Redestad wrote: > Hi, > > by packing the coder and length values into a long, and combining the > length and coder mixers, we can reduce the number of MHs generated to > set up String concatenations. > > Theoretically we reduce the number of MHs created by up to a third, and > real time improvements in startup tests exercising ISC typically hover > around 10%. This optimization reverts JDK-8212597[1], so expressions > that benefited from that of course sees a smaller or no added benefit. > > http://cr.openjdk.java.net/~redestad/8213035/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8213035 > > I've attached a simple microbenchmark and performance results from > running on x64 in the bug: > - Significant reduction in work needed to bootstrap a slew of > concatenations, both on the initial bootstrap and when repeating similar > concatenation shapes. > - For C2 the peak performance is more or less the same, with very small > differences due slight differences in the generated code (both tiny > improvements and tiny regressions). > - For C1 we see some regressions on some micros, at worst 1.2x > - For interpreter we see improvements around 1.1x on several micros > > Testing: tier1-2 jdk and hs tests, sanity tested overflow conditions > > Thanks! > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8212597 From ivan.gerasimov at oracle.com Mon Oct 29 17:46:44 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 29 Oct 2018 10:46:44 -0700 Subject: Proposal Extending API for Streams (or other potentially long builder or chain calls) In-Reply-To: References: Message-ID: <11632ddd-5957-ef44-29ce-b6c86038d85a@oracle.com> Hello Constantine! It seems that a request for such method was made in JDK-8210372 . I like the method name chain(), proposed in that request. With kind regards, Ivan On 10/26/18 2:13 AM, Constantine Plotnikov wrote: > Hello All! > > This email was previously filled as a feature request for JDK, I was > forwarded here to write it as an email. > > Currently, if one needs to skip some stage or provide a group of reused > stages one to have to do the following: > > Stream s = collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty()); > s = useSecuriytFilter(s, session) > return s.collect(Collector.toList()); > > Or like: > > return useSecuriytFilter(collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty()) > , session); > .collect(Collector.toList()); > > In both cases, readability is of code is not high, as fluent sequence of > actions is interrupted. > > It is suggested to add "process" method to stream like the following > signature: > > default R process(Function, R> body) { > return body.apply(this); > } > > Then custom processing could be applied like the following: > > return collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty() > .process( s -> useSecuriytFilter(s, session)) > .collect(Collector.toList()); > > While semantics is the same, the code structure looks much better. Note > this proposed change is not about less typing, but about making local > processing looking more local, rather than affecting entire processing > pipeline visually. > > The detailed description for motivation is here: > > https://dzone.com/articles/making-java-fluent-api-more-flexible > > Some other libraries with processing chain usage pattern like date-time > classes in java.util.time could benefit from this too as common blocks of > date arithmetic could be reused in more clean way. > > A possibly better alternative to this functionality is the support for > extension methods like in Groovy, Kotlin, or C#, so users will be able to > create such methods when needed themselves, not waiting for library > designers. I think extension methods are good innovation enablers, as they > allow users of JDK or some library to try new API ideas in the practice > first, and than to discuss their experience with component authors. > > Best Regards, > Konstantin Plotnikov > -- With kind regards, Ivan Gerasimov From t.linkowski at gmail.com Mon Oct 29 18:07:45 2018 From: t.linkowski at gmail.com (Tomasz Linkowski) Date: Mon, 29 Oct 2018 19:07:45 +0100 Subject: Proposal: Stream.iterateWhile(T seed, Function> mapper) In-Reply-To: References: Message-ID: Two more things: 1) The example I provided might have been too simple to be convincing. Note that the proposed method is particularly useful when the Predicate (hasNext) has some common expensive part with the UnaryOperator (next). For example: boolean hasNext(Foo foo) { Bar bar = computeBar(foo); // expensive return hasNextFoo(bar); } Foo next(Foo foo) { Bar bar = computeBar(foo); // expensive return computeNextFoo(bar); } which can instead become: Optional findNext(Foo foo) { Bar bar = computeBar(foo); // expensive return hasNextFoo(bar) ? Optional.of(computeNextFoo(bar)) : Optional.empty(); } 2) I forgot about the primitive specializations - here they are: static IntStream iterateWhile(int seed, IntFunction mapper) { return Stream.iterate( OptionalInt.of(seed), OptionalInt::isPresent, optionalInt -> mapper.apply(optionalInt.getAsInt()) ).mapToInt(OptionalInt::getAsInt); } static LongStream iterateWhile(int seed, LongFunction mapper) { return Stream.iterate( OptionalLong.of(seed), OptionalLong::isPresent, optionalLong -> mapper.apply(optionalLong.getAsLong()) ).mapToLong(OptionalLong::getAsLong); } static DoubleStream iterateWhile(int seed, DoubleFunction mapper) { return Stream.iterate( OptionalDouble.of(seed), OptionalDouble::isPresent, optionalDouble -> mapper.apply(optionalDouble.getAsDouble()) ).mapToDouble(OptionalDouble::getAsDouble); } The implementations above are just examples (most likely, dedicated spliterators should be used for better performance). Note, however, that there is one caveat here, namely: - `Stream.iterateWhile` can produce an empty `Stream` (if null seed is given), - `[Primitive]Stream.iterateWhile` cannot (because the seed cannot be null). One way to provide consistency here (if desirable) would be to require the seed in `Stream.iterateWhile` to be non-null. Regards, Tomasz Linkowski On Fri, Oct 26, 2018 at 5:44 PM Tomasz Linkowski wrote: > Hi, > > Please, consider adding a new static method to the `Stream` interface > (names TBD): > > static Stream iterateWhile( > T seed, Function> > mapper > ); > > > == OVERVIEW == > > + non-null equivalent of `Stream.iterate(seed, hasNext, next)` [1] > + `mapper` like in `Optional.flatMap(mapper)` [2] > + shift from two operations to one operation, like in: > - `Iterator.hasNext/next` => `Spliterator.tryAdvance` > - pattern matching (test/bind) > + intent: "nudge towards writing clearer code" (Brian Goetz about LVTI [3]) > + useful for `Optional`-based APIs > + trivial implementation > > > == JUSTIFICATION == > > `Stream.iterate(seed, hasNext, next)` is great for nullable-return-based > APIs. Example: returning a chain of `Throwable` causes: > > Stream.iterate(throwable, Objects::nonNull, Throwable::getCause) > > For `Optional`-based APIs, using `Stream.iterate` becomes cumbersome. > Example (assume `Throwable.findCause()` returns `Optional`): > > Stream.iterate(throwable, Objects::nonNull, t -> > t.findCause().orElse(null)) > > Using the proposed method, the above can become much clearer: > > Stream.iterateWhile(throwable, Throwable::findCause) > > This is just one example - I can provide more if needed. > > > == IMPLEMENTATION == > > Preferred implementation: > > iterateWhile(seed, mapper) -> Stream.iterate( > seed, Objects::nonNull, > t -> mapper.apply(t).orElse(null) > ); > > Equivalent `Optional`-based implementation: > > iterateWhile(seed, mapper) -> Stream.iterate( > Optional.ofNullable(seed), Optional::isPresent, > optional -> optional.flatMap(mapper) > ).map(Optional::get); > > Note that both implementations assume that `null` seed yields an empty > `Stream`. > > > == NAMING == > > Name `iterate` cannot be safely overloaded because of > `Stream.iterate(UnaryOperator)` so another name needs to be used. I > proposed `iterateWhile` inspired by `takeWhile` but maybe it's a wrong > trail (`takeWhile` takes a `Predicate`). Other names that come to my mind: > `iterateWhilePresent`, `iterateOptional`, `iterateNonNull`. > > > [1] > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/stream/Stream.html#iterate(T,java.util.function.Predicate,java.util.function.UnaryOperator) > [2] > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Optional.html#flatMap(java.util.function.Function) > [3] > http://mail.openjdk.java.net/pipermail/amber-spec-experts/2018-October/000826.html > > -- > Regards, > Tomasz Linkowski > From joe.darcy at oracle.com Mon Oct 29 18:10:27 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 29 Oct 2018 11:10:27 -0700 Subject: JDK 12 RFR of JDK-8212081: AnnotatedType.toString implementation don't print annotations on embedded types In-Reply-To: References: <5b76499d-33d1-7d3e-e8ea-44230ac78ea7@oracle.com> <4bb3cc76-ffe7-383b-c414-7efe7405ef1d@oracle.com> <5c9fab13-f06c-0cba-d3f4-8ee250f94de6@oracle.com> <1cfca04b-8005-0479-6f7c-b93ac8f25258@oracle.com> Message-ID: Hi Joel, Thanks for the review :-) I'll push the 8212081.2 version with a few additional notes for future maintainers: +??? /* +???? * Note that if additional subclasses of AnnotatedTypeBaseImpl are +???? * added, the equals methods of AnnotatedTypeBaseImpl will need to +???? * be updated to properly implement the equals contract. +???? */ + ???? private static class AnnotatedTypeBaseImpl implements AnnotatedType { And inside AnnotatedWildcardTypeImpl.toString: +??????? // Note that the wildcard API is written to accommodate +??????? // multiple bounds for wildcards, but at the time of +??????? // writing only a single bound is allowed in the +??????? // language. Thanks, -Joe On 10/29/2018 1:52 AM, Joel Borggr?n-Franck wrote: > Hi Joe, > > I suspect you pasted the wrong link, link to updated impl ends in > 8212081.2 right? Anyhow, the .2 version looks good. Ship it! > > Cheers > /Joel > /Joel > From mandy.chung at oracle.com Mon Oct 29 19:16:44 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Oct 2018 12:16:44 -0700 Subject: RFR: 8213035: Pack MethodHandleInlineStrategy coder and length into a long In-Reply-To: <80c8b610-e553-d4a5-d91d-ea2b9e5ed6fb@oracle.com> References: <80c8b610-e553-d4a5-d91d-ea2b9e5ed6fb@oracle.com> Message-ID: <6bdf1297-3706-cb38-4593-74247f905b6e@oracle.com> On 10/29/18 8:17 AM, Claes Redestad wrote: > Hi, > > by packing the coder and length values into a long, and combining the > length and coder mixers, we can reduce the number of MHs generated to > set up String concatenations. > > Theoretically we reduce the number of MHs created by up to a third, > and real time improvements in startup tests exercising ISC typically > hover around 10%. This optimization reverts JDK-8212597[1], so > expressions that benefited from that of course sees a smaller or no > added benefit. > > http://cr.openjdk.java.net/~redestad/8213035/jdk.00/ > https://bugs.openjdk.java.net/browse/JDK-8213035 > This looks okay to me. Mandy From claes.redestad at oracle.com Mon Oct 29 19:36:53 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 29 Oct 2018 20:36:53 +0100 Subject: RFR: 8213035: Pack MethodHandleInlineStrategy coder and length into a long In-Reply-To: <6bdf1297-3706-cb38-4593-74247f905b6e@oracle.com> References: <80c8b610-e553-d4a5-d91d-ea2b9e5ed6fb@oracle.com> <6bdf1297-3706-cb38-4593-74247f905b6e@oracle.com> Message-ID: <49016e27-e006-a484-626b-0cfa044df2f4@oracle.com> Vladimir, Mandy, thanks for reviewing! /Claes On 2018-10-29 20:16, Mandy Chung wrote: > > On 10/29/18 8:17 AM, Claes Redestad wrote: >> Hi, >> >> by packing the coder and length values into a long, and combining the >> length and coder mixers, we can reduce the number of MHs generated to >> set up String concatenations. >> >> Theoretically we reduce the number of MHs created by up to a third, >> and real time improvements in startup tests exercising ISC typically >> hover around 10%. This optimization reverts JDK-8212597[1], so >> expressions that benefited from that of course sees a smaller or no >> added benefit. >> >> http://cr.openjdk.java.net/~redestad/8213035/jdk.00/ >> https://bugs.openjdk.java.net/browse/JDK-8213035 >> > > This looks okay to me. > > Mandy From ivan.gerasimov at oracle.com Mon Oct 29 23:03:52 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 29 Oct 2018 16:03:52 -0700 Subject: Proposal Extending API for Streams (or other potentially long builder or chain calls) In-Reply-To: References: <11632ddd-5957-ef44-29ce-b6c86038d85a@oracle.com> Message-ID: <4abb0249-d450-a93d-8e5f-0b599596b570@oracle.com> Oops. I was meaning JDK-8140283 of course. You can vote for it in JBS, if you find it useful :) With kind regards, Ivan On 10/29/18 3:06 PM, Constantine Plotnikov wrote: > Hello Ivan, > > Yes. It is practically the same request, only method name is > different. I do not particularly care how this method is called. So > I'm not only one who miss this method. In the next thread the name > "transform" is proposed to match method for String. jOO? > uses > name "transform" too. > > Kotlin names this method "let", and implemented it using an extension > method on Object, at such moments I wish Java had extension methods too. > > Best Regards, > Konstantin Plotnikov > > On Mon, Oct 29, 2018 at 8:46 PM Ivan Gerasimov > > wrote: > > Hello Constantine! > > It seems that a request for such method was made in JDK-8210372 > . > I like the method name chain(), proposed in that request. > > With kind regards, > Ivan > > > On 10/26/18 2:13 AM, Constantine Plotnikov wrote: >> Hello All! >> >> This email was previously filled as a feature request for JDK, I was >> forwarded here to write it as an email. >> >> Currently, if one needs to skip some stage or provide a group of reused >> stages one to have to do the following: >> >> Stream s = collection.stream() >> .map(a -> doIt(a, bb)) >> .filter(a -> !a.list().isEmpty()); >> s = useSecuriytFilter(s, session) >> return s.collect(Collector.toList()); >> >> Or like: >> >> return useSecuriytFilter(collection.stream() >> .map(a -> doIt(a, bb)) >> .filter(a -> !a.list().isEmpty()) >> , session); >> .collect(Collector.toList()); >> >> In both cases, readability is of code is not high, as fluent sequence of >> actions is interrupted. >> >> It is suggested to add "process" method to stream like the following >> signature: >> >> default R process(Function, R> body) { >> return body.apply(this); >> } >> >> Then custom processing could be applied like the following: >> >> return collection.stream() >> .map(a -> doIt(a, bb)) >> .filter(a -> !a.list().isEmpty() >> .process( s -> useSecuriytFilter(s, session)) >> .collect(Collector.toList()); >> >> While semantics is the same, the code structure looks much better. Note >> this proposed change is not about less typing, but about making local >> processing looking more local, rather than affecting entire processing >> pipeline visually. >> >> The detailed description for motivation is here: >> >> https://dzone.com/articles/making-java-fluent-api-more-flexible >> >> Some other libraries with processing chain usage pattern like date-time >> classes in java.util.time could benefit from this too as common blocks of >> date arithmetic could be reused in more clean way. >> >> A possibly better alternative to this functionality is the support for >> extension methods like in Groovy, Kotlin, or C#, so users will be able to >> create such methods when needed themselves, not waiting for library >> designers. I think extension methods are good innovation enablers, as they >> allow users of JDK or some library to try new API ideas in the practice >> first, and than to discuss their experience with component authors. >> >> Best Regards, >> Konstantin Plotnikov >> > > -- > With kind regards, > Ivan Gerasimov > -- With kind regards, Ivan Gerasimov From vyom.tewari at oracle.com Tue Oct 30 09:22:47 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Tue, 30 Oct 2018 14:52:47 +0530 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: <20181026150158.GB3689@vimes> References: <20181025163435.GB4374@vimes> <20181026150158.GB3689@vimes> Message-ID: Hi Rob, Overall your code looks OK to me, In LdapDnsProviderService.java please make 'service' as volatile otherwise 'getInstance()' may not work as expected. I can see you implemented DCL but it may not work if 'service' is not declare volatile. If you like, you can us the initialization 'On Demand Holder idiom' to implement the lazy initialization. Thanks, Vyom On 26/10/18 8:31 PM, Rob McKenna wrote: > Yes, thanks a lot Alan. > > Vyom and Martin both had some very helpful feedback so I'm hoping to > hear from both! > > -Rob > > On 26/10/18 15:34, Alan Bateman wrote: >> On 25/10/2018 17:34, Rob McKenna wrote: >>> This recently received CSR approval, so it seems like a good time to pick >>> the codereview up again: >>> >>> http://cr.openjdk.java.net/~robm/8160768/webrev.08/ >>> >> I went through a number of iterations with Rob on the API/javadoc so I think >> the API parts in webrev.08 are good. I have not had time to go through the >> implementation and test changes so hopefully that someone else has cycles to >> help on that. >> >> -Alan >> From volker.simonis at gmail.com Tue Oct 30 13:55:28 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 30 Oct 2018 14:55:28 +0100 Subject: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception Message-ID: Hi, can I please have a review for the following tiny change which fixes the license header on a few AIX-specific files: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ https://bugs.openjdk.java.net/browse/JDK-8213151 These files have been wrongly integrated (without the Classpath Exception in their license header) from the very beginning of the AIX port. The fix is trivial - just add the CPE to these files similar to the corresponding sibling files. Thank you and best regards, Volker From thomas.stuefe at gmail.com Tue Oct 30 14:05:53 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 30 Oct 2018 15:05:53 +0100 Subject: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception In-Reply-To: References: Message-ID: Seems fine and trivial. Regards, Thomas On Tue, Oct 30, 2018 at 2:56 PM Volker Simonis wrote: > > Hi, > > can I please have a review for the following tiny change which fixes > the license header on a few AIX-specific files: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ > https://bugs.openjdk.java.net/browse/JDK-8213151 > > These files have been wrongly integrated (without the Classpath > Exception in their license header) from the very beginning of the AIX > port. The fix is trivial - just add the CPE to these files similar to > the corresponding sibling files. > > Thank you and best regards, > Volker From andy.herrick at oracle.com Tue Oct 30 14:11:36 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 30 Oct 2018 10:11:36 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> Message-ID: <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> On 10/24/2018 10:22 AM, Alan Bateman wrote: > On 23/10/2018 16:49, Andy Herrick wrote: >> This patch implements the Java Packager Tool (jpackager) as described >> in JEP 343: Packaging Tool >> >> >> jpackager is a simple packaging tool, based on the JavaFX >> |javapackager| tool, that: >> >> ?* Supports native packaging formats to give the end user a natural >> ?? installation experience. These formats include |msi| and |exe| on >> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >> ?* Allows launch-time parameters to be specified at packaging time. >> ?* Can be invoked directly, from the command line, or programmatically, >> ?? via the |ToolProvider| API. >> >> Webrev: >> >> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >> > cc'ing build-dev as it's important to get it reviewed there. > > What is the plan for tests to go with this tool? I see there is one > test in the webrev to do some argument validation but I don't see > anything else right now. We plan to incorporate the initial feedback from this review, and include an initial set of automated tests in a refresh sometime next week. We will continue to develop and automate tests for future updates. > > What is the status of the JNLPConverter tool? I see it is included as > a "demo" but maybe it would be better to host somewhere else as this > is for developers migrating Java Web Start applications. Our current plan is to deliver it only as a demo. > > Would it be possible to update the JEP with all the CLI options? That > would be useful for review and also useful for those invoking it with > the ToolProvider API. Done. > > If I read the webrev correctly then it adds two modules, one with the > jpackager tool and the other with an API. It would be useful to get a > bit more information on the split. Also I think the name of the API > module and the package that it exports needs discussion to make sure > that the right names are chosen. Yes - though we are currently using jdk.packager.services, we are open to other suggestions as the name for these. "jdk.packager.runtime" has also been suggested. > > -Alan /Andy From daniel.fuchs at oracle.com Tue Oct 30 14:25:18 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 30 Oct 2018 14:25:18 +0000 Subject: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider In-Reply-To: <20181025163435.GB4374@vimes> References: <20181025163435.GB4374@vimes> Message-ID: <4b152645-3702-272c-b351-5a279573634d@oracle.com> Hi Rob, LdapCtxFactory.java 187 for (String u : r.getEndpoints()) { 188 try { 189 ctx = getLdapCtxFromUrl( 190 r.getDomainName(), new LdapURL(u), env); 191 } catch (NamingException e) { 192 // try the next element 193 lastException = e; 194 } 195 } is a break statement missing after line 190? If not then can you add a comment explaining why only the last context is retained (and returned?) Alternatively, if a break is indeed missing, these three lines could be moved into the for loop above: 206 // Record the URL that created the context 207 ctx.setProviderUrl(url); 208 return ctx; and maybe lines 206-207 could be moved into the getLdapCtxFromUrl() method? LdapDnsProviderService.java: Why is this class non final? If it can be made final then the protected methods should probably become package. LdapDnsProvider.java: It is strange to see new APIs with Hashtable in the method signature. I understand that our implementation will need an Hashtable at some point to call javax.naming.spi.NamingProvider, but how likely is it that a clean room implementation of a LdapDnsProvider will need to do that? Maybe we could have Map in the signature instead - and leave the burden to our implementation - somewhere in ServiceLocator, to adapt back to Hashtable where it needs to? best regards, -- daniel On 25/10/2018 17:34, Rob McKenna wrote: > This recently received CSR approval, so it seems like a good time to pick > the codereview up again: > > http://cr.openjdk.java.net/~robm/8160768/webrev.08/ > > Referencing: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html > > 1) I'm copying the behaviour from > LdapCtxFactory.getInitialContext(Hashtable) where an empty String is > the default value used when the provider url is null. > > I don't think HostnameChecker (by way of SNIHostname) will accept either > empty or null values when doing the comparison. > > Somewhat oddly however, LdapCtx.extendedOperation(ExtendedRequest) > appears to pass the String "null" to > StartTlsResponseImpl.setConnection(Connection, String), which attempts > to substitute null values with the Connections host so there may be a bug > here. > > I'm happy to allow null returns here if necessary. Sean, can you > comment on the distinction between null & "" as far as hostname > verification is concerned? > > 2) In the latest iteration lookupEndpoints() returns an > Optional. Currently neither getEndpoints() nor > getDomainName() can be null. (they can be an empty list and/or an empty > String however) > > 3) Corrected. > > 4) See https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5 > > -Rob > From Roger.Riggs at oracle.com Tue Oct 30 14:46:27 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 30 Oct 2018 10:46:27 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> Message-ID: <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> Hi Thomas, On 10/29/2018 12:04 PM, Thomas St?fe wrote: > Hi Roger, > > On Thu, Oct 25, 2018 at 10:45 PM Roger Riggs wrote: >> Hi Thomas, >> >> In an abundance of caution, I was thinking that it would be a change right >> at the beginning of a new release so it gets the most exercise and >> users in early access, etc. >> > Okay, I understand that. > > Over the next days I will run tests with posix_spawn enabled by > default on our landscape. We have many different Linuxes on different > architectures and different levels of glibc, so this is a reasonable > test. > > If I do not encounter red flags, I would consider the posix_spawn path > tested well enough to ship it at least as a non-default, experimental > option. Like David originally intended. Then, start of next release, > we can make it default and see how that goes. > > Does that sound ok to you? That's fine, until it becomes the default, it will be opt in. Is there an updated webrev with the corrected test executions? > >> And before that it needs to be put into more regular usage and >> some more unusual environments. The default is currently selected >> by virtual of being first in the argument list; that doesn't lend itself >> to being configurable with either configure or make arguments. > I do not understand the last sentence: it was never my intention of > adding a configure option? I was considering whether it would be useful to have such an option to make it easier to make it the default in a particular build. But it seems unnecessary since the tests can be done without. Thanks, Roger ... > >> On 10/25/2018 06:33 AM, Thomas St?fe wrote: >> >> Hi all, >> >> the more I mull over this, the more I would prefer to do the jump for >> real and attempt switch the default to posix_spawn() for Linux. >> >> We have theoretically established that both glibc down to 2.4 and >> muslc since always did "the right thing". >> >> We still have time in the 12 time line to test this thoroughly. >> >> What do you think? >> >> Thanks, Thomas >> >> On Wed, Oct 24, 2018 at 10:59 PM Thomas St?fe wrote: >> >> Hi Roger, >> >> On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: >> >> Hi Thomas, >> >> Sorry, I had the incantation for multiple tests wrong. >> Separate test configurations need to be in separate /* */ comment blocks. >> BTW, it creates separate .jtr files for each block. >> >> diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java >> --- a/test/jdk/java/lang/ProcessBuilder/Basic.java >> +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java >> @@ -33,8 +33,10 @@ >> * @modules java.base/java.lang:open >> * @run main/othervm/timeout=300 Basic >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >> - * >> + */ >> +/* >> * @test >> + * @modules java.base/java.lang:open >> * @requires (os.family == "linux") >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> * @author Martin Buchholz >> >> >> As for the build configuration being out of scope... >> >> I don't want to see part of the work done and then the rest forgotten or >> worse yet someone comes along in the future and incorrectly believes that >> posix_spawn is ready for production and starts filing bugs or getting bit by something. >> There's a lot more testing to do before it could be come the default >> and perhaps a significant warning should be attached to the code so it does not get forgotten. >> >> I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? >> >> We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. >> >> We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. >> >> Do you have an idea how to proceed? >> >> Thanks, Thomas >> >> Regards, Roger >> >> >> On 10/24/18 1:53 PM, Thomas St?fe wrote: >> >> Hi Roger, >> >> On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: >> >> Hi Thomas, >> >> Thanks for adding the test. >> >> There's a feature of jtreg that was exposed a couple of month ago that >> can be used to deal with running the test too many times. >> >> There can be multiple @test blocks with different @requires. >> >> * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires >> (os.family == "linux") * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> >> >> Does not seem to work, sorry: >> >> 24 /* >> 25 * @test >> 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 >> 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 >> 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 >> 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 >> 30 * 8067796 >> 31 * @key intermittent >> 32 * @summary Basic tests for Process and Environment Variable code >> 33 * @modules java.base/java.lang:open >> 34 * @run main/othervm/timeout=300 Basic >> 35 * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=fork Basic >> 36 * @test >> 37 * @requires (os.family == "liinux") >> 38 * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> 39 * @author Martin Buchholz >> 40 */ >> >> If I have @requires (os.family == "linux") all three variants are executed - ok. >> >> Then I wanted to have a negative test, so I misnamed linux as "liinux" >> and would have expected the first @test block to fire, the second to >> be ignored. But in fact: >> >> thomas at mainframe /shared/projects/openjdk/jtreg $ >> ../jtreg-prebuilt/jtreg/bin/jtreg -jdk >> ../jdk-jdk/output-slowdebug/images/jdk/ >> ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java >> Test results: no tests selected >> >> So to me it looks like as if the @requires tag is valid for both @test >> blocks, not only the one it appears in. >> >> I'll run this through our build system too. >> >> To fully test out using posix_spawn in many more different scenarios the >> build system should be augmented to be able to use it as the default for >> an entire build/CI/CD/test runs. >> >> Sure! But I think this is out of scope for this patch. >> >> Thanks, Thomas >> >> Thanks, Roger >> >> On 10/24/2018 10:35 AM, Thomas St?fe wrote: >> >> Hi all, >> >> version 2 of Davids patch, with test changes: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ >> >> Executed the test on my local Ubuntu box, works fine. Submit job runs. >> >> About the test: I added a new line: >> >> * @run main/othervm/timeout=300 Basic >> * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic >> + * @run main/othervm/timeout=300 >> -Djdk.lang.Process.launchMechanism=posix_spawn Basic >> >> The way I understand those tests work is that the first line causes >> the test to be run with the default launch mechanism, the second line >> with jdk.lang.Process.launchMechanism=fork explicitly. The third line, >> added by me, will now explicitly test with posix_spawn. I did not >> limit the platforms, since posix_spawn should now be available on all >> platforms, so it should work on all platforms. But then, on all other >> platforms it has already been the default. >> >> This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism >> gets ignored, so we just executed the same test twice (now three >> times)? And now we execute the posix_spawn variant twice on all >> platforms where this is the default, so line 1 and 3 are the same? You >> see I am not a jtreg expert :) Can I specify a @run directive for only >> one platform? In that case I would limit the explicit posix_spawn test >> to Linux. >> >> Note however that if we really abondon vfork in the future and make >> posix_spawn the default, this test becomes simpler too. >> >> Best, Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: >> >> On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: >> >> Review: >> >> - copyright dates need updating on the C-sources >> >> - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || >> defined(_AIX) || defined(__linux__)" to be removed completely from >> unix-specific source files. The ifdef now covers all OpenJDK Unix >> platforms. >> >> Here's a version with these changes. >> >> -- >> - DML >> >> >> From matthias.baesken at sap.com Tue Oct 30 15:02:05 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 30 Oct 2018 15:02:05 +0000 Subject: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception Message-ID: Hi Volker, looks good (not a Reviewer however) ! Maybe you should also adjust the Copyright year info in the files you touched . Best regards, Matthias -----Original Message----- Hi, can I please have a review for the following tiny change which fixes the license header on a few AIX-specific files: http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ https://bugs.openjdk.java.net/browse/JDK-8213151 These files have been wrongly integrated (without the Classpath Exception in their license header) from the very beginning of the AIX port. The fix is trivial - just add the CPE to these files similar to the corresponding sibling files. Thank you and best regards, Volker From Roger.Riggs at oracle.com Tue Oct 30 15:34:42 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 30 Oct 2018 11:34:42 -0400 Subject: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception In-Reply-To: References: Message-ID: Looks fine,? Reviewed. Thanks, Roger On 10/30/2018 11:02 AM, Baesken, Matthias wrote: > Hi Volker, looks good (not a Reviewer however) ! > Maybe you should also adjust the Copyright year info in the files you touched . > > Best regards, Matthias > > > -----Original Message----- > > Hi, > > can I please have a review for the following tiny change which fixes > the license header on a few AIX-specific files: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ > https://bugs.openjdk.java.net/browse/JDK-8213151 > > These files have been wrongly integrated (without the Classpath > Exception in their license header) from the very beginning of the AIX > port. The fix is trivial - just add the CPE to these files similar to > the corresponding sibling files. > > Thank you and best regards, > Volker > > From thomas.stuefe at gmail.com Tue Oct 30 15:41:56 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 30 Oct 2018 16:41:56 +0100 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> Message-ID: Hi Roger, On Tue, Oct 30, 2018 at 3:46 PM Roger Riggs wrote: > > Hi Thomas, > > On 10/29/2018 12:04 PM, Thomas St?fe wrote: > > Hi Roger, > > On Thu, Oct 25, 2018 at 10:45 PM Roger Riggs wrote: > > Hi Thomas, > > In an abundance of caution, I was thinking that it would be a change right > at the beginning of a new release so it gets the most exercise and > users in early access, etc. > > Okay, I understand that. > > Over the next days I will run tests with posix_spawn enabled by > default on our landscape. We have many different Linuxes on different > architectures and different levels of glibc, so this is a reasonable > test. > > If I do not encounter red flags, I would consider the posix_spawn path > tested well enough to ship it at least as a non-default, experimental > option. Like David originally intended. Then, start of next release, > we can make it default and see how that goes. > > Does that sound ok to you? > > > That's fine, until it becomes the default, it will be opt in. > > Is there an updated webrev with the corrected test executions? > Here you go. http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn-on-linux/webrev_0/webrev/ Tested locally, seems to work fine. I am re-running the submit tests too. > And before that it needs to be put into more regular usage and > some more unusual environments. The default is currently selected > by virtual of being first in the argument list; that doesn't lend itself > to being configurable with either configure or make arguments. > > I do not understand the last sentence: it was never my intention of > adding a configure option? > > I was considering whether it would be useful to have such an option to > make it easier to make it the default in a particular build. > But it seems unnecessary since the tests can be done without. > Okay, understood, thanks for clarifying. Thanks, Thomas > Thanks, Roger > > ... > > On 10/25/2018 06:33 AM, Thomas St?fe wrote: > > Hi all, > > the more I mull over this, the more I would prefer to do the jump for > real and attempt switch the default to posix_spawn() for Linux. > > We have theoretically established that both glibc down to 2.4 and > muslc since always did "the right thing". > > We still have time in the 12 time line to test this thoroughly. > > What do you think? > > Thanks, Thomas > > On Wed, Oct 24, 2018 at 10:59 PM Thomas St?fe wrote: > > Hi Roger, > > On Wed 24. Oct 2018 at 21:39, Roger Riggs wrote: > > Hi Thomas, > > Sorry, I had the incantation for multiple tests wrong. > Separate test configurations need to be in separate /* */ comment blocks. > BTW, it creates separate .jtr files for each block. > > diff --git a/test/jdk/java/lang/ProcessBuilder/Basic.java b/test/jdk/java/lang/ProcessBuilder/Basic.java > --- a/test/jdk/java/lang/ProcessBuilder/Basic.java > +++ b/test/jdk/java/lang/ProcessBuilder/Basic.java > @@ -33,8 +33,10 @@ > * @modules java.base/java.lang:open > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > - * > + */ > +/* > * @test > + * @modules java.base/java.lang:open > * @requires (os.family == "linux") > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=posix_spawn Basic > * @author Martin Buchholz > > > As for the build configuration being out of scope... > > I don't want to see part of the work done and then the rest forgotten or > worse yet someone comes along in the future and incorrectly believes that > posix_spawn is ready for production and starts filing bugs or getting bit by something. > There's a lot more testing to do before it could be come the default > and perhaps a significant warning should be attached to the code so it does not get forgotten. > > I agree, we ideally should not roll out half tested changes. But where does that leave us wrt this patch? > > We could just not do it, requiring anyone willing to do the extensive testing necessary to switch the default to posix-spawn to apply this change first locally. This is not an insurmountable amount of work, especially since the base is quite static, so the patch won?t bit rot easily. > > We could push the patch in its current form, plus a large source comment? But then. Users do not read comments. A warning on stderr? Would play havoc with many tests parsing stderr. > > Do you have an idea how to proceed? > > Thanks, Thomas > > Regards, Roger > > > On 10/24/18 1:53 PM, Thomas St?fe wrote: > > Hi Roger, > > On Wed, Oct 24, 2018 at 5:23 PM Roger Riggs wrote: > > Hi Thomas, > > Thanks for adding the test. > > There's a feature of jtreg that was exposed a couple of month ago that > can be used to deal with running the test too many times. > > There can be multiple @test blocks with different @requires. > > * @run main/othervm/timeout=300 Basic * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic * * @test * @requires > (os.family == "linux") * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > > Does not seem to work, sorry: > > 24 /* > 25 * @test > 26 * @bug 4199068 4738465 4937983 4930681 4926230 4931433 4932663 4986689 > 27 * 5026830 5023243 5070673 4052517 4811767 6192449 6397034 6413313 > 28 * 6464154 6523983 6206031 4960438 6631352 6631966 6850957 6850958 > 29 * 4947220 7018606 7034570 4244896 5049299 8003488 8054494 8058464 > 30 * 8067796 > 31 * @key intermittent > 32 * @summary Basic tests for Process and Environment Variable code > 33 * @modules java.base/java.lang:open > 34 * @run main/othervm/timeout=300 Basic > 35 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=fork Basic > 36 * @test > 37 * @requires (os.family == "liinux") > 38 * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > 39 * @author Martin Buchholz > 40 */ > > If I have @requires (os.family == "linux") all three variants are executed - ok. > > Then I wanted to have a negative test, so I misnamed linux as "liinux" > and would have expected the first @test block to fire, the second to > be ignored. But in fact: > > thomas at mainframe /shared/projects/openjdk/jtreg $ > ../jtreg-prebuilt/jtreg/bin/jtreg -jdk > ../jdk-jdk/output-slowdebug/images/jdk/ > ../jdk-jdk/source/test/jdk/java/lang/ProcessBuilder/Basic.java > Test results: no tests selected > > So to me it looks like as if the @requires tag is valid for both @test > blocks, not only the one it appears in. > > I'll run this through our build system too. > > To fully test out using posix_spawn in many more different scenarios the > build system should be augmented to be able to use it as the default for > an entire build/CI/CD/test runs. > > Sure! But I think this is out of scope for this patch. > > Thanks, Thomas > > Thanks, Roger > > On 10/24/2018 10:35 AM, Thomas St?fe wrote: > > Hi all, > > version 2 of Davids patch, with test changes: > > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn.patch/webrev.01/webrev/ > > Executed the test on my local Ubuntu box, works fine. Submit job runs. > > About the test: I added a new line: > > * @run main/othervm/timeout=300 Basic > * @run main/othervm/timeout=300 -Djdk.lang.Process.launchMechanism=fork Basic > + * @run main/othervm/timeout=300 > -Djdk.lang.Process.launchMechanism=posix_spawn Basic > > The way I understand those tests work is that the first line causes > the test to be run with the default launch mechanism, the second line > with jdk.lang.Process.launchMechanism=fork explicitly. The third line, > added by me, will now explicitly test with posix_spawn. I did not > limit the platforms, since posix_spawn should now be available on all > platforms, so it should work on all platforms. But then, on all other > platforms it has already been the default. > > This is still a bit iffy: On Windows, jdk.lang.Process.launchMechanism > gets ignored, so we just executed the same test twice (now three > times)? And now we execute the posix_spawn variant twice on all > platforms where this is the default, so line 1 and 3 are the same? You > see I am not a jtreg expert :) Can I specify a @run directive for only > one platform? In that case I would limit the explicit posix_spawn test > to Linux. > > Note however that if we really abondon vfork in the future and make > posix_spawn the default, this test becomes simpler too. > > Best, Thomas > > > > > > > > > > > > > On Wed, Oct 24, 2018 at 3:36 PM David Lloyd wrote: > > On Wed, Oct 24, 2018 at 1:05 AM Thomas St?fe wrote: > > Review: > > - copyright dates need updating on the C-sources > > - I opt for "#if defined(__solaris__) || defined(_ALLBSD_SOURCE) || > defined(_AIX) || defined(__linux__)" to be removed completely from > unix-specific source files. The ifdef now covers all OpenJDK Unix > platforms. > > Here's a version with these changes. > > -- > - DML > > > > From Alan.Bateman at oracle.com Tue Oct 30 16:09:25 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Oct 2018 16:09:25 +0000 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> Message-ID: <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> On 30/10/2018 14:11, Andy Herrick wrote: > : >> >> What is the status of the JNLPConverter tool? I see it is included as >> a "demo" but maybe it would be better to host somewhere else as this >> is for developers migrating Java Web Start applications. > Our current plan is to deliver it only as a demo. This looks like a migration tool rather than a demo so not clear to me that this is the right approach. Also as the tool is for migration from Java Web Start when maybe it should be a tool hosted with the Oracle JDK download rather than something to put into the JDK. > : >> >> If I read the webrev correctly then it adds two modules, one with the >> jpackager tool and the other with an API. It would be useful to get a >> bit more information on the split. Also I think the name of the API >> module and the package that it exports needs discussion to make sure >> that the right names are chosen. > Yes - though we are currently using jdk.packager.services, we are open > to other suggestions as the name for these. "jdk.packager.runtime" has > also been suggested. Alex has suggested jdk.jpackager to avoid giving the impression that it's the "JDK packager". Also several existing tool modules have the tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). Is the API to ensure that only one instance of the application is running really tied to the jpackager tool? Could it be used by applications that aren't packaged in with this tool? I'm asking in case there is a better name for this API module. -Alan From kevin.rushforth at oracle.com Tue Oct 30 16:29:55 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Oct 2018 09:29:55 -0700 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> Message-ID: inline On 10/30/2018 9:09 AM, Alan Bateman wrote: > On 30/10/2018 14:11, Andy Herrick wrote: > >> : >>> >>> If I read the webrev correctly then it adds two modules, one with >>> the jpackager tool and the other with an API. It would be useful to >>> get a bit more information on the split. Also I think the name of >>> the API module and the package that it exports needs discussion to >>> make sure that the right names are chosen. >> Yes - though we are currently using jdk.packager.services, we are >> open to other suggestions as the name for these. >> "jdk.packager.runtime" has also been suggested. > Alex has suggested jdk.jpackager to avoid giving the impression that > it's the "JDK packager". Also several existing tool modules have the > tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). Yes, I think jdk.jpackager is a fine name for this module. > Is the API to ensure that only one instance of the application is > running really tied to the jpackager tool? Could it be used by > applications that aren't packaged in with this tool? I'm asking in > case there is a better name for this API module. In its current form it is tied to jpackager. Andy might be able to comment on how tightly-coupled it is, and what it would take to generalize it, but that wasn't a goal to make it usable for apps that aren't packaged using jpackager. Other things that will likely go into this runtime support module in the future: * Service daemon support * User JVM args support -- Kevin From naoto.sato at oracle.com Tue Oct 30 16:29:03 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 30 Oct 2018 09:29:03 -0700 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> Message-ID: Updated the webrev. Please review. http://cr.openjdk.java.net/~naoto/8212941/webrev.03/ Naoto On 10/26/18 3:47 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > On 10/26/18 3:00 PM, joe darcy wrote: >> Hi Naoto, >> >> I'd like to see a bit some discussion up front about the expected >> evolution of this class. >> >> For example, "once an era is defined, subsequent versions of the API >> will add a constant for it. etc. Eras are expected to have consecutive >> integers associated with them, etc. " > > Thanks. Those will clarify the intention of the change more. Will > incorporate them. > >> >> Once a formal name is added for the new era, will that value be serial >> equivalent to the current new era value being used in the class? >> Basically, is the name or the int value the basis of the serial >> identity of a JapaneseEra object? > > Yes to the former question. The "NewEra" era should be equivalent to > what's coming after the name is decided. Thus the int value should be > the sole identity for the designated era. This will ensure the > maintenance releases which cannot backport public singleton instances > work without spec change. > > Naoto > >> >> Thanks, >> >> -Joe >> >> >> On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212941 >>> >>> The proposed fix and CSR (not approved yet) are located at: >>> >>> http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ >>> https://bugs.openjdk.java.net/browse/JDK-8212942 >>> >>> This change is intended to loosen the spec of JapaneseEra so that >>> later era additions won't require unnecessary spec changes. This is >>> particularly important for the maintenance releases. >>> >>> Naoto >> From Roger.Riggs at oracle.com Tue Oct 30 17:03:23 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 30 Oct 2018 13:03:23 -0400 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> Message-ID: Hi Naoto, Looks fine.? The wording should allow future Japanese era to be defined without the timing being tightly coupled to java specification updates. Thanks, Roger On 10/30/2018 12:29 PM, Naoto Sato wrote: > Updated the webrev. Please review. > > http://cr.openjdk.java.net/~naoto/8212941/webrev.03/ > > Naoto > > On 10/26/18 3:47 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> On 10/26/18 3:00 PM, joe darcy wrote: >>> Hi Naoto, >>> >>> I'd like to see a bit some discussion up front about the expected >>> evolution of this class. >>> >>> For example, "once an era is defined, subsequent versions of the API >>> will add a constant for it. etc. Eras are expected to have >>> consecutive integers associated with them, etc. " >> >> Thanks. Those will clarify the intention of the change more. Will >> incorporate them. >> >>> >>> Once a formal name is added for the new era, will that value be >>> serial equivalent to the current new era value being used in the >>> class? Basically, is the name or the int value the basis of the >>> serial identity of a JapaneseEra object? >> >> Yes to the former question. The "NewEra" era should be equivalent to >> what's coming after the name is decided. Thus the int value should be >> the sole identity for the designated era. This will ensure the >> maintenance releases which cannot backport public singleton instances >> work without spec change. >> >> Naoto >> >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212941 >>>> >>>> The proposed fix and CSR (not approved yet) are located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ >>>> https://bugs.openjdk.java.net/browse/JDK-8212942 >>>> >>>> This change is intended to loosen the spec of JapaneseEra so that >>>> later era additions won't require unnecessary spec changes. This is >>>> particularly important for the maintenance releases. >>>> >>>> Naoto >>> From andy.herrick at oracle.com Tue Oct 30 17:10:38 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 30 Oct 2018 13:10:38 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> <6ab02a18-cf6f-82b5-a53b-808d429a8bbb@oracle.com> Message-ID: On 10/30/2018 12:09 PM, Alan Bateman wrote: > On 30/10/2018 14:11, Andy Herrick wrote: >> : >>> >>> What is the status of the JNLPConverter tool? I see it is included >>> as a "demo" but maybe it would be better to host somewhere else as >>> this is for developers migrating Java Web Start applications. >> Our current plan is to deliver it only as a demo. > This looks like a migration tool rather than a demo so not clear to me > that this is the right approach. Also as the tool is for migration > from Java Web Start when maybe it should be a tool hosted with the > Oracle JDK download rather than something to put into the JDK. > > >> : >>> >>> If I read the webrev correctly then it adds two modules, one with >>> the jpackager tool and the other with an API. It would be useful to >>> get a bit more information on the split. Also I think the name of >>> the API module and the package that it exports needs discussion to >>> make sure that the right names are chosen. >> Yes - though we are currently using jdk.packager.services, we are >> open to other suggestions as the name for these. >> "jdk.packager.runtime" has also been suggested. > Alex has suggested jdk.jpackager to avoid giving the impression that > it's the "JDK packager". Also several existing tool modules have the > tool name in the module name (jdk.jdeps, jdk.jlink, jdk.jshell, ...). This seems reasonable, jdk.packager -> jdk.jpackager still leaves the question of jdk.packager.services -> jdk.jpackager.services (or jdk.jpackager.runtime) or something else ? > > Is the API to ensure that only one instance of the application is > running really tied to the jpackager tool? Could it be used by > applications that aren't packaged in with this tool? I'm asking in > case there is a better name for this API module. The current implementation is tied to the? jpackager tool in that newActivation (invoking a running app from a newly launched one) is implemented in the native launchers used by jpackager. This is a very interesting question none the less, as there seem to be at least two ways this could be implemented for generic Java applications: 1.) implement it in the native java launcher(s) 2.) implement it entirely in Java, with a new "transfer control" method. (Java Web Start implemented this in both the native javaws launcher, and in pure Java, but it had control in Java before an app was launched, where a normal Java app would not, so would need another transfer of control method.? An app could pass it's args to this method which would return false (if these was no other instance), or invoke newActivation() in the existing instance and return true (allowing the caller to clean up and exit). Such an API would be outside the scope of jpackager, but may impact our decision to include a singleton interface in jpackager. /Andy > > -Alan > From ilya.gazman at doubleverify.com Tue Oct 30 17:26:03 2018 From: ilya.gazman at doubleverify.com (Ilya Gazman) Date: Tue, 30 Oct 2018 13:26:03 -0400 Subject: Looking for guidness Message-ID: Hey guys, I would like to contribute to OpenJDK changes that I made to java.io. PipedInput/Output/Stream. What would be the best way for me to share my code and get your feedback? Best, Ilya Gazman -- Ilya Gazman Software Engineer 233 Spring St. New York, NY 10013 ilya.gazman at doubleverify.com -- From takiguc at linux.vnet.ibm.com Tue Oct 30 17:32:20 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 31 Oct 2018 02:32:20 +0900 Subject: RFR: 8211382 ISO2022JP and GB18030 NIO converter issues In-Reply-To: <5BB3EACB.8050202@oracle.com> References: <5BB3EACB.8050202@oracle.com> Message-ID: <8e1b3d97f14419bbef70469d19685d9f@linux.vnet.ibm.com> Hello. Additional reviewer is required. It's typo issue as Sherman explained. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-10-03 07:01, Xueming Shen wrote: > +1 > > -Sherman > > btw, since gb18030.decodeArrayLoop() is right I would assume it's just > a "typo" in decodeBufferLoop() > > On 10/2/18, 2:21 AM, Ichiroh Takiguchi wrote: >> Hello, >> IBM would like to contribute NIO converter patch to OpenJDK project. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211382 >> Change: https://cr.openjdk.java.net/~itakiguchi/8211382/webrev.00/ >> >> Issue: >> ISO2022JP decoder and GB18030 decoder (for decodeBufferLoop()) have >> code range definition issues. >> >> ISO2022JP, 0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, 0x42, is converted to >> \uFFA0 >> ISO2022JP is for Japanese, but \uFFA0 is a part of Korean Hangul >> character. >> >> GB18030, \uFFFE is converted to 0x84, 0x31, 0xA4, 0x38. >> 0x84, 0x31, 0xA4, 0x38 is converted to replacement character \uFFFD. >> >> $ java Test1 >> \uFFA0 >> \uFFFD >> >> Expected result >> $ java Test1 >> \uFFFD >> \uFFFE >> >> Testcase is as follows: >> ======================== >> $ cat Test1.java >> import java.nio.*; >> import java.nio.charset.*; >> >> public class Test1 { >> public static void main(String[] args) throws Exception { >> { >> byte[] ba = new byte[] {0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, >> 0x42,}; >> for(char ch : (new String(ba, "ISO2022JP")).toCharArray()) { >> System.out.printf("\\u%04X",(int)ch); >> } >> System.out.println(); >> } >> { >> Charset cs = Charset.forName("GB18030"); >> CharsetDecoder cd = cs.newDecoder(); >> cd.onMalformedInput(CodingErrorAction.REPLACE) >> .onUnmappableCharacter(CodingErrorAction.REPLACE); >> byte[] ba = "\uFFFE".getBytes(cs); >> ByteBuffer bb = ByteBuffer.allocateDirect(ba.length); >> bb.put(ByteBuffer.wrap(ba)); >> bb.position(0); >> CharBuffer cb = cd.decode(bb); >> for(int i=0; i> System.out.printf("\\u%04X",(int)cb.get(i)); >> } >> System.out.println(); >> } >> } >> } >> ======================== >> >> I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From chris.hegarty at oracle.com Tue Oct 30 17:33:10 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 30 Oct 2018 17:33:10 +0000 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> Message-ID: <572F6755-28CB-4BD5-BB09-7C500DB890EE@oracle.com> > On 30 Oct 2018, at 17:03, Roger Riggs wrote: > > Hi Naoto, > > Looks fine. The wording should allow future Japanese era to be defined without > the timing being tightly coupled to java specification updates. +1 Suggest: "The defined ** era?s {@link #getValue} ** is expected to have a consecutive integer associated with it.? I suspect that the wording here has deliberately chosen, but I wonder if it could be tightened a little? `values()` should return an array of eras whose values are in a contiguous range, no? If so, can this be specified? -Chris. > Thanks, Roger > > On 10/30/2018 12:29 PM, Naoto Sato wrote: >> Updated the webrev. Please review. >> >> http://cr.openjdk.java.net/~naoto/8212941/webrev.03/ From naoto.sato at oracle.com Tue Oct 30 17:45:41 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 30 Oct 2018 10:45:41 -0700 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: <572F6755-28CB-4BD5-BB09-7C500DB890EE@oracle.com> References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> <572F6755-28CB-4BD5-BB09-7C500DB890EE@oracle.com> Message-ID: <63a1a8af-6f40-e3de-35b7-3ae68ac115a8@oracle.com> Hi Chris, Thank you for the review. On 10/30/18 10:33 AM, Chris Hegarty wrote: > >> On 30 Oct 2018, at 17:03, Roger Riggs wrote: >> >> Hi Naoto, >> >> Looks fine. The wording should allow future Japanese era to be defined without >> the timing being tightly coupled to java specification updates. > > +1 > > Suggest: "The defined ** era?s {@link #getValue} ** is expected > to have a consecutive integer associated with it.? > > I suspect that the wording here has deliberately chosen, but I > wonder if it could be tightened a little? > > `values()` should return an array of eras whose values are in a > contiguous range, no? If so, can this be specified? Yes, both of those are valid points. I have already pushed the change, as the CSR has been approved, I will consider modifying the wording according to your suggestion in the future. Naoto > > -Chris. > > >> Thanks, Roger >> >> On 10/30/2018 12:29 PM, Naoto Sato wrote: >>> Updated the webrev. Please review. >>> >>> http://cr.openjdk.java.net/~naoto/8212941/webrev.03/ > From pavel.rappo at oracle.com Tue Oct 30 17:58:50 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 30 Oct 2018 17:58:50 +0000 Subject: Looking for guidness In-Reply-To: References: Message-ID: <9B86120E-DF39-4E6E-926B-0CDFFC350180@oracle.com> General info on contributing can be found here: https://openjdk.java.net/contribute/ > On 30 Oct 2018, at 17:26, Ilya Gazman wrote: > > Hey guys, > > I would like to contribute to OpenJDK changes that I made to java.io. > PipedInput/Output/Stream. > > What would be the best way for me to share my code and get your feedback? > > Best, > Ilya Gazman > -- > Ilya Gazman > > Software Engineer > > > 233 Spring St. > > New York, NY 10013 > ilya.gazman at doubleverify.com > > -- > > > > > > > > > > > From ilya.gazman at doubleverify.com Tue Oct 30 18:14:10 2018 From: ilya.gazman at doubleverify.com (Ilya Gazman) Date: Tue, 30 Oct 2018 14:14:10 -0400 Subject: Looking for guidness In-Reply-To: <9B86120E-DF39-4E6E-926B-0CDFFC350180@oracle.com> References: <9B86120E-DF39-4E6E-926B-0CDFFC350180@oracle.com> Message-ID: Thank you, I will start by signing the OCA. Meanwhile, will it be possible for me to share my code and have a discussion on it? I saw that you are working with "Mercurial's hg" export command, but I am not sure how to clone the code to generate it. Can you please help me with that, or suggest another way that I can share my code with you. On Tue, Oct 30, 2018 at 1:58 PM Pavel Rappo wrote: > General info on contributing can be found here: > > https://openjdk.java.net/contribute/ > > > On 30 Oct 2018, at 17:26, Ilya Gazman > wrote: > > > > Hey guys, > > > > I would like to contribute to OpenJDK changes that I made to java.io. > > PipedInput/Output/Stream. > > > > What would be the best way for me to share my code and get your feedback? > > > > Best, > > Ilya Gazman > > -- > > Ilya Gazman > > > > Software Engineer > > > > > > 233 Spring St. > > > > New York, NY 10013 > > ilya.gazman at doubleverify.com > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > -- Ilya Gazman Software Engineer 233 Spring St. New York, NY 10013 ilya.gazman at doubleverify.com -- From Roger.Riggs at oracle.com Tue Oct 30 18:16:42 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 30 Oct 2018 14:16:42 -0400 Subject: Looking for guidance In-Reply-To: References: <9B86120E-DF39-4E6E-926B-0CDFFC350180@oracle.com> Message-ID: Hi Ilya, A good starting step is to describe, in prose, what improvements you are proposing and how they are valuable to the broad range of developers that use the JDK.?? Comments will give you an idea how directly what you propose fits in or how it may be improved. The OCA is needed, before you share the code. Roger On 10/30/2018 02:14 PM, Ilya Gazman wrote: > Thank you, I will start by signing the OCA. > > Meanwhile, will it be possible for me to share my code and have a > discussion on it? I saw that you are working with "Mercurial's hg" export > command, but I am not sure how to clone the code to generate it. > Can you please help me with that, or suggest another way that I can share > my code with you. > > On Tue, Oct 30, 2018 at 1:58 PM Pavel Rappo wrote: > >> General info on contributing can be found here: >> >> https://openjdk.java.net/contribute/ >> >>> On 30 Oct 2018, at 17:26, Ilya Gazman >> wrote: >>> Hey guys, >>> >>> I would like to contribute to OpenJDK changes that I made to java.io. >>> PipedInput/Output/Stream. >>> >>> What would be the best way for me to share my code and get your feedback? >>> >>> Best, >>> Ilya Gazman >>> -- >>> Ilya Gazman >>> >>> Software Engineer >>> >>> >>> 233 Spring St. >>> >>> New York, NY 10013 >>> ilya.gazman at doubleverify.com >>> >>> -- >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> -- > Ilya Gazman > > Software Engineer > > > 233 Spring St. > > New York, NY 10013 > ilya.gazman at doubleverify.com > From chris.hegarty at oracle.com Tue Oct 30 19:19:08 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 30 Oct 2018 19:19:08 +0000 Subject: [12] RFR: 8212941: Loosen the range of JapaneseEra In-Reply-To: <63a1a8af-6f40-e3de-35b7-3ae68ac115a8@oracle.com> References: <2763e076-eab1-0045-abf2-2cfcbb01c80d@oracle.com> <2d952d00-3999-79ac-aa05-1b338bdef97f@oracle.com> <572F6755-28CB-4BD5-BB09-7C500DB890EE@oracle.com> <63a1a8af-6f40-e3de-35b7-3ae68ac115a8@oracle.com> Message-ID: <5079B3F2-5031-489D-8DC4-8F5989E29956@oracle.com> > On 30 Oct 2018, at 17:45, Naoto Sato wrote: >> .. >> Suggest: "The defined ** era?s {@link #getValue} ** is expected >> to have a consecutive integer associated with it.? >> I suspect that the wording here has deliberately chosen, but I >> wonder if it could be tightened a little? >> `values()` should return an array of eras whose values are in a >> contiguous range, no? If so, can this be specified? > > Yes, both of those are valid points. I have already pushed the change, as the CSR has been approved, I will consider modifying the wording according to your suggestion in the future. No problem, just some minor points to consider. -Chris. From andy.herrick at oracle.com Tue Oct 30 20:54:53 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 30 Oct 2018 16:54:53 -0400 Subject: RFR: JDK-8212780: JEP 343: Packaging Tool Implementation In-Reply-To: <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> References: <94429a94-d8bd-2aff-7a88-312f9ccdbadb@oracle.com> <70b3a114-d44c-3375-12a5-2044dec0f7f4@oracle.com> Message-ID: <3d793b6f-bd8d-3780-8a51-03e18e7f3307@oracle.com> On 10/30/2018 10:11 AM, Andy Herrick wrote: > > > On 10/24/2018 10:22 AM, Alan Bateman wrote: >> On 23/10/2018 16:49, Andy Herrick wrote: >>> This patch implements the Java Packager Tool (jpackager) as >>> described in JEP 343: Packaging Tool >>> >>> >>> jpackager is a simple packaging tool, based on the JavaFX >>> |javapackager| tool, that: >>> >>> ?* Supports native packaging formats to give the end user a natural >>> ?? installation experience. These formats include |msi| and |exe| on >>> ?? Windows, |pkg| and |dmg| on MacOS, and |deb| and |rpm| on Linux. >>> ?* Allows launch-time parameters to be specified at packaging time. >>> ?* Can be invoked directly, from the command line, or programmatically, >>> ?? via the |ToolProvider| API. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~herrick/8212780/webrev.01/ >>> >> cc'ing build-dev as it's important to get it reviewed there. >> >> What is the plan for tests to go with this tool? I see there is one >> test in the webrev to do some argument validation but I don't see >> anything else right now. > We plan to incorporate the initial feedback from this review, and > include an initial set of automated tests in a refresh sometime next > week. > We will continue to develop and automate tests for future updates. >> >> What is the status of the JNLPConverter tool? I see it is included as >> a "demo" but maybe it would be better to host somewhere else as this >> is for developers migrating Java Web Start applications. > Our current plan is to deliver it only as a demo. After further discussion, we have decided to remove the JNLPConversion tool , and find another home for it. /Andy >> >> Would it be possible to update the JEP with all the CLI options? That >> would be useful for review and also useful for those invoking it with >> the ToolProvider API. > Done. >> >> If I read the webrev correctly then it adds two modules, one with the >> jpackager tool and the other with an API. It would be useful to get a >> bit more information on the split. Also I think the name of the API >> module and the package that it exports needs discussion to make sure >> that the right names are chosen. > Yes - though we are currently using jdk.packager.services, we are open > to other suggestions as the name for these. "jdk.packager.runtime" has > also been suggested. >> >> -Alan > /Andy From markus.gronlund at oracle.com Tue Oct 30 21:52:00 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 30 Oct 2018 14:52:00 -0700 (PDT) Subject: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr In-Reply-To: <5B2FEDE2.4040106@oracle.com> References: <5B286533.6070500@oracle.com> <3bce8034-387e-6ca5-d04d-b7171a13f47b@oracle.com> <5B2A9607.9010206@oracle.com> <422e546a-4bf4-e2a4-72cf-d4bc5be5abdf@oracle.com> <5B2F83C1.2050207@oracle.com> <233f6052-644d-5bff-9acd-f77bb0affa2c@oracle.com> <5B2FEDE2.4040106@oracle.com> Message-ID: <28b2d376-eeb7-466f-96ed-996df2cf6803@default> Hi Erik, I think this looks good. Thanks Markus -----Original Message----- From: Erik Gahlin Sent: den 24 juni 2018 21:16 To: Alan Bateman ; hotspot-jfr-dev at openjdk.java.net; core-libs-dev Subject: Re: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr On 2018-06-24 19:00, Alan Bateman wrote: > On 24/06/2018 12:42, Erik Gahlin wrote: >> I have updated jdk.internal.event.Event class with comments. >> >> http://cr.openjdk.java.net/~egahlin/8203629.2/ >> >> It is basically a copy the comments in jdk.jfr.Event, but without >> reference to classes in the JFR module. >> >> The rationale for using a class instead of an interface has to do >> with the implementation of JFR. Markus brought up some reasons in his >> e-mail. >> >> I thought about mentioning JFR in the javadoc, and that the purpose >> of the class is to allow use of JFR without a compile time dependency >> on the JFR module, but decided not to, since I think the class could >> have a value on its own for JVMs that do not support JFR, but that >> want to do to something similar for the JDK. They could, for >> instance, add an implementation in the empty method bodies. > I read the mail from Markus and looked at the updated webrev. It's > good to have some javadoc, just a bit strange to have an abstract > class without any abstract methods. The design stems from jdk.jfr.Event. If methods in jdk.jfr.Event would be abstract, it would not be possible to declare them final and we want them to be final, as users are not supposed to override them. When the jdk.jfr.Event class is loaded, the final modifiers are removed, so we can generate bytecode for subclasses. This is a trick to prevent incorrect use of the API. Why not make the class non-abstract and rely on the protected constructor? We could do that, it would prevent direct instantiation, but the use of the abstract modifier also fits nicely with how the modifier is used for event hierarchies. Imagine the following hierarchy and reuse of the sql field: class SQLEvent extends jdk.jfr.Event { @Label("SQL"); String sql; } class SQLUpdateEvent extends SQLEvent { } class SQLInsertEvent extends SQLEvent { } class SelectEvent extends SQLEvent { } When users connect with JMC, or call FlightRecorder#getEventTypes(), they will get a list of all event types that have been registered in the JVM. In the above example, they would get the SQLEvent, which is not really meant to be an event that users can configure. If they declare SQLEvent abstract, it will be ignored by the JFR system. This reuse mechanism can be seen in jdk.jfr.events.AbstractJDKEvent Why not use @Registered(false) instead of the abstract modifier? We want that annotation to be inherited, so it is possible to use it for large set events in a hierarchy. The abstract modifier only operates on a particular class. If the jdk.jfr.Event class is also declared abstract, it can reuse the same mechanism. It is convenient from an implementation point of view, no special case for jdk.jfr.Event, and it may also hint to a user that this the class is not something they should instantiate. It also prevents instantiation using reflection and setAccessible(true). An interface could also prevent instantiation, but it may open for malicious implementations and it seems wrong to make into an interface when users are not really meant to implement it. It also doesn't work well with the JVM implementation. > There isn't enough in the discussion here to understand the original > rational for why jdk.jfr.Event is abstract, esp. as the constructor is > protected so it can't be directed instantiated outside of the jdk.jfr > package. Also an abstract class can extend a non-abstract class so > abstract jdk.jfr.Event could extend a non-abstract > jdk.internal.event.Event if you want to clean this up a bit. I don't > want to get in the way of the current effort but at some point I think > another set of eyes on the APIs here might help. > Thanks Alan. We can revisit the design later. Erik > BTW: My previous comment about the modifiers was mostly about > jdk.jfr.Event. > > -Alan From Roger.Riggs at oracle.com Wed Oct 31 13:45:40 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 31 Oct 2018 09:45:40 -0400 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> Message-ID: <8926843e-d351-0d63-a7c7-9aa344233e11@oracle.com> Hi Thomas, The webrev looks fine. Please remove the @author tag in the Linux (2nd) test block in Basic.java. Author tags are losing favor and there's no need to repeat it. I ran the change through our tests without errors. I'd give it another 24hours before pushing in case anyone else wants to review it. Thanks, Roger p.s. The issue to change the default is: https://bugs.openjdk.java.net/browse/JDK-8213192 On 10/30/2018 11:41 AM, Thomas St?fe wrote: > Hi Roger, > > > On Tue, Oct 30, 2018 at 3:46 PM Roger Riggs wrote: >> Hi Thomas, >> >> On 10/29/2018 12:04 PM, Thomas St?fe wrote: >> >> Hi Roger, >> >> On Thu, Oct 25, 2018 at 10:45 PM Roger Riggs wrote: >> >> Hi Thomas, >> >> In an abundance of caution, I was thinking that it would be a change right >> at the beginning of a new release so it gets the most exercise and >> users in early access, etc. >> >> Okay, I understand that. >> >> Over the next days I will run tests with posix_spawn enabled by >> default on our landscape. We have many different Linuxes on different >> architectures and different levels of glibc, so this is a reasonable >> test. >> >> If I do not encounter red flags, I would consider the posix_spawn path >> tested well enough to ship it at least as a non-default, experimental >> option. Like David originally intended. Then, start of next release, >> we can make it default and see how that goes. >> >> Does that sound ok to you? >> >> >> That's fine, until it becomes the default, it will be opt in. >> >> Is there an updated webrev with the corrected test executions? >> > Here you go. > > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn-on-linux/webrev_0/webrev/ > > Tested locally, seems to work fine. I am re-running the submit tests too. > > From roger.riggs at oracle.com Wed Oct 31 14:58:39 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 31 Oct 2018 10:58:39 -0400 Subject: RFR: 8211382 ISO2022JP and GB18030 NIO converter issues In-Reply-To: <8e1b3d97f14419bbef70469d19685d9f@linux.vnet.ibm.com> References: <5BB3EACB.8050202@oracle.com> <8e1b3d97f14419bbef70469d19685d9f@linux.vnet.ibm.com> Message-ID: +1, looks fine If you need a sponsor, I can. Regards, Roger On 10/30/18 1:32 PM, Ichiroh Takiguchi wrote: > Hello. > Additional reviewer is required. > It's typo issue as Sherman explained. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2018-10-03 07:01, Xueming Shen wrote: >> +1 >> >> -Sherman >> >> btw, since gb18030.decodeArrayLoop() is right I would assume it's just >> a "typo" in decodeBufferLoop() >> >> On 10/2/18, 2:21 AM, Ichiroh Takiguchi wrote: >>> Hello, >>> IBM would like to contribute NIO converter patch to OpenJDK project. >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8211382 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8211382/webrev.00/ >>> >>> Issue: >>> ISO2022JP decoder and GB18030 decoder (for decodeBufferLoop()) have >>> code range definition issues. >>> >>> ISO2022JP, 0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, 0x42, is converted to >>> \uFFA0 >>> ISO2022JP is for Japanese, but \uFFA0 is a part of Korean Hangul >>> character. >>> >>> GB18030, \uFFFE is converted to 0x84, 0x31, 0xA4, 0x38. >>> 0x84, 0x31, 0xA4, 0x38 is converted to replacement character \uFFFD. >>> >>> $ java Test1 >>> \uFFA0 >>> \uFFFD >>> >>> Expected result >>> $ java Test1 >>> \uFFFD >>> \uFFFE >>> >>> Testcase is as follows: >>> ======================== >>> $ cat Test1.java >>> import java.nio.*; >>> import java.nio.charset.*; >>> >>> public class Test1 { >>> ? public static void main(String[] args) throws Exception { >>> ??? { >>> ????? byte[] ba = new byte[] {0x1B, 0x28, 0x49, 0x60, 0x1B, 0x28, >>> 0x42,}; >>> ????? for(char ch : (new String(ba, "ISO2022JP")).toCharArray()) { >>> ??????? System.out.printf("\\u%04X",(int)ch); >>> ????? } >>> ????? System.out.println(); >>> ??? } >>> ??? { >>> ????? Charset cs = Charset.forName("GB18030"); >>> ????? CharsetDecoder cd = cs.newDecoder(); >>> ????? cd.onMalformedInput(CodingErrorAction.REPLACE) >>> ??????? .onUnmappableCharacter(CodingErrorAction.REPLACE); >>> ????? byte[] ba = "\uFFFE".getBytes(cs); >>> ????? ByteBuffer bb = ByteBuffer.allocateDirect(ba.length); >>> ????? bb.put(ByteBuffer.wrap(ba)); >>> ????? bb.position(0); >>> ????? CharBuffer cb = cd.decode(bb); >>> ????? for(int i=0; i>> ??????? System.out.printf("\\u%04X",(int)cb.get(i)); >>> ????? } >>> ????? System.out.println(); >>> ??? } >>> ? } >>> } >>> ======================== >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> > From volker.simonis at gmail.com Wed Oct 31 15:00:43 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 31 Oct 2018 16:00:43 +0100 Subject: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception In-Reply-To: References: Message-ID: Thanks for the quick reviews! Volker On Tue, Oct 30, 2018 at 4:35 PM Roger Riggs wrote: > > Looks fine, Reviewed. > > Thanks, Roger > > On 10/30/2018 11:02 AM, Baesken, Matthias wrote: > > Hi Volker, looks good (not a Reviewer however) ! > > Maybe you should also adjust the Copyright year info in the files you touched . > > > > Best regards, Matthias > > > > > > -----Original Message----- > > > > Hi, > > > > can I please have a review for the following tiny change which fixes > > the license header on a few AIX-specific files: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ > > https://bugs.openjdk.java.net/browse/JDK-8213151 > > > > These files have been wrongly integrated (without the Classpath > > Exception in their license header) from the very beginning of the AIX > > port. The fix is trivial - just add the CPE to these files similar to > > the corresponding sibling files. > > > > Thank you and best regards, > > Volker > > > > > From Roger.Riggs at oracle.com Wed Oct 31 15:11:36 2018 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 31 Oct 2018 11:11:36 -0400 Subject: RFR 8207690: SearchPath API for classpath and similar path strings In-Reply-To: <60355b5b-ea45-754d-239b-5798cd659c95@oracle.com> References: <60355b5b-ea45-754d-239b-5798cd659c95@oracle.com> Message-ID: <403447a9-1d3a-295e-4185-a1338b62c3c7@oracle.com> Ping... http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-October/055865.html On 10/04/2018 11:09 AM, Roger Riggs wrote: > Please review a revised API for parsing search and using paths. > Thanks for the earlier comments and suggestions. > > java.util.SearchPath is an immutable sequence of strings, typically > filesystem paths. > A search path is created from a list of strings or by? splitting a > string using File.pathSeparator. > > > Webrev: http://cr.openjdk.java.net/~rriggs/webrev-searchpath-8207690/ > > Javadoc: > http://cr.openjdk.java.net/~rriggs/searchpath-8208208/java.base/java/util/SearchPath.html > > Issue: https://bugs.openjdk.java.net/browse/JDK-8207690 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8208208 > > Thanks, Roger > From thomas.stuefe at gmail.com Wed Oct 31 15:12:59 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 31 Oct 2018 16:12:59 +0100 Subject: RFR: JDK-8212828 Allow POSIX_SPAWN to be used for ProcessImpl on Linux In-Reply-To: <8926843e-d351-0d63-a7c7-9aa344233e11@oracle.com> References: <9637c2fa-ef62-b8c4-7172-ef468d50fcec@oracle.com> <8bd132cb-829f-9592-ac5c-8eaaddacc1d5@oracle.com> <143e4553-dba0-64ee-946e-311ca710be87@oracle.com> <8435fba7-a6fa-4d27-6ad8-ffd20ce5468e@oracle.com> <8926843e-d351-0d63-a7c7-9aa344233e11@oracle.com> Message-ID: Hi Roger, thanks! I'll remove the author tag before pushing. I ran the change through jdk-submit too, without problems, though I assume they are a subset of the tests you ran. I was not yet able to run them through our tests, due to technical problems. Will do so in the next days. Thanks, Thomas On Wed, Oct 31, 2018 at 2:46 PM Roger Riggs wrote: > > Hi Thomas, > > The webrev looks fine. > > Please remove the @author tag in the Linux (2nd) test block in Basic.java. > Author tags are losing favor and there's no need to repeat it. > > I ran the change through our tests without errors. > > I'd give it another 24hours before pushing in case anyone else wants to review it. > > Thanks, Roger > > p.s. The issue to change the default is: https://bugs.openjdk.java.net/browse/JDK-8213192 > > > On 10/30/2018 11:41 AM, Thomas St?fe wrote: > > Hi Roger, > > > On Tue, Oct 30, 2018 at 3:46 PM Roger Riggs wrote: > > Hi Thomas, > > On 10/29/2018 12:04 PM, Thomas St?fe wrote: > > Hi Roger, > > On Thu, Oct 25, 2018 at 10:45 PM Roger Riggs wrote: > > Hi Thomas, > > In an abundance of caution, I was thinking that it would be a change right > at the beginning of a new release so it gets the most exercise and > users in early access, etc. > > Okay, I understand that. > > Over the next days I will run tests with posix_spawn enabled by > default on our landscape. We have many different Linuxes on different > architectures and different levels of glibc, so this is a reasonable > test. > > If I do not encounter red flags, I would consider the posix_spawn path > tested well enough to ship it at least as a non-default, experimental > option. Like David originally intended. Then, start of next release, > we can make it default and see how that goes. > > Does that sound ok to you? > > > That's fine, until it becomes the default, it will be opt in. > > Is there an updated webrev with the corrected test executions? > > Here you go. > > http://cr.openjdk.java.net/~stuefe/webrevs/JDK-8212828-posix_spawn-on-linux/webrev_0/webrev/ > > Tested locally, seems to work fine. I am re-running the submit tests too. > > From Sergey.Bylokhov at oracle.com Wed Oct 31 15:58:32 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 31 Oct 2018 08:58:32 -0700 Subject: RFR(XS): 8213151: [AIX] Some class library files are missing the Classpath exception In-Reply-To: References: Message-ID: <9cb98903-be3a-a40e-c0f7-427fd79e644e@oracle.com> +1 On 30/10/2018 07:05, Thomas St?fe wrote: > Seems fine and trivial. > > Regards, Thomas > > On Tue, Oct 30, 2018 at 2:56 PM Volker Simonis wrote: >> >> Hi, >> >> can I please have a review for the following tiny change which fixes >> the license header on a few AIX-specific files: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8213151/ >> https://bugs.openjdk.java.net/browse/JDK-8213151 >> >> These files have been wrongly integrated (without the Classpath >> Exception in their license header) from the very beginning of the AIX >> port. The fix is trivial - just add the CPE to these files similar to >> the corresponding sibling files. >> >> Thank you and best regards, >> Volker -- Best regards, Sergey. From dean.long at oracle.com Wed Oct 31 22:23:12 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 31 Oct 2018 15:23:12 -0700 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged Message-ID: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8212605 http://cr.openjdk.java.net/~dlong/8212605/webrev.1 This change implements AccessController.doPrivileged in Java.? This gives a performance improvement while also being useful to Project Loom by removing the Java --> native --> Java transition.? One reason doPrivileged has historically been in native is because of the need to guarantee the cleanup of the privileged context when doPrivileged returns.? To do that in Java, the information that AccessController.getContext needs is pushed onto the Java stack as arguments to a method that getContext will recognize during its stack walk.? This allows us to remove the native privileged stack while guaranteeing that the privileged context goes away when the method returns. Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security tests.? For the first few rounds of testing, I kept the old native privileged stack and compared the results of the old and new implementations for each getContext call, which did catch some early bugs.? The changes were also examined by internal security experts and run through additional internal security tests. The improvement on this [1] doPrivileged microbenchmark is approximate 50x. There is no attempt to optimize getContext() or security permission checks in this change, however, this is intended to be a first step towards other possible improvements, for example those proposed here [2]. dl [1] http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java [2] http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html From david.holmes at oracle.com Wed Oct 31 23:06:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Nov 2018 09:06:02 +1000 Subject: RFR(M) 8212605: Pure-Java implementation of AccessController.doPrivileged In-Reply-To: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> References: <0e3759bf-9c6f-dd75-bb27-5579e23c5348@oracle.com> Message-ID: <6523ec93-af32-da8f-704a-0322e56de00f@oracle.com> Hi Dean, Looking only at the hotspot changes. The removal of the DoPrivileged and related privileged_stack code seems okay. I have a few related comments: src/hotspot/share/classfile/systemDictionary.hpp You added the java_security_AccessController class after java_security_AccessControlContext. Did you actually verify where in the load/initialization order the AccessController class appears today, and where it appears after your change? (Note the comments at the start of WK_KLASSES_DO). Changes to the initialization order would be my biggest concern with this patch. --- I'm unclear about the change to the test: test/hotspot/jtreg/runtime/JVMDoPrivileged/DoPrivRunAbstract.jasm as it still refers to the now non-existent JVM_DoPrivileged in the summary. Does this test still make sense? Should it be moved to the Java side now it doesn't actually test anything in the VM? --- There may be further dead code to remove now: vmSymbols.hpp: codesource_permissioncollection_signature is now unreferenced and can be removed. javaClasses.*: - java_lang_System::has_security_manager - java_security_AccessControlContext::is_authorized ./share/memory/universe.hpp: static Method* protection_domain_implies_method() --- Thanks, David On 1/11/2018 8:23 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8212605 > http://cr.openjdk.java.net/~dlong/8212605/webrev.1 > > This change implements AccessController.doPrivileged in Java.? This > gives a performance improvement while also being useful to Project Loom > by removing the Java --> native --> Java transition.? One reason > doPrivileged has historically been in native is because of the need to > guarantee the cleanup of the privileged context when doPrivileged > returns.? To do that in Java, the information that > AccessController.getContext needs is pushed onto the Java stack as > arguments to a method that getContext will recognize during its stack > walk.? This allows us to remove the native privileged stack while > guaranteeing that the privileged context goes away when the method returns. > > Tested with tier1-tier3 hotspot and jdk tests and JCK api/java_security > tests.? For the first few rounds of testing, I kept the old native > privileged stack and compared the results of the old and new > implementations for each getContext call, which did catch some early > bugs.? The changes were also examined by internal security experts and > run through additional internal security tests. > > The improvement on this [1] doPrivileged microbenchmark is approximate 50x. > > There is no attempt to optimize getContext() or security permission > checks in this change, however, this is intended to be a first step > towards other possible improvements, for example those proposed here [2]. > > dl > > [1] > http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/file/fc4783360f58/src/main/java/org/openjdk/bench/java/security/DoPrivileged.java > > [2] > http://mail.openjdk.java.net/pipermail/security-dev/2017-December/016627.html > > From ilya.gazman at doubleverify.com Mon Oct 29 19:33:01 2018 From: ilya.gazman at doubleverify.com (Ilya Gazman) Date: Mon, 29 Oct 2018 15:33:01 -0400 Subject: PipedInputStream improvement Message-ID: Hey guys, I created a more efficient version of java.io.PipedStream. I would like to have a conversation with you about my implementation and how we can test and benched marked it and eventually maybe even submit it for the next Java release. My name is Ilya Gazman, I work at DoubleVerify, and I did this implementation as part of our work on our core systems. Please guide me through the process of what should I do to receive proper feedback and what are the next steps. Best, Ilya -- Ilya Gazman Software Engineer 233 Spring St. New York, NY 10013 ilya.gazman at doubleverify.com -- From constantine.plotnikov at gmail.com Mon Oct 29 22:06:48 2018 From: constantine.plotnikov at gmail.com (Constantine Plotnikov) Date: Tue, 30 Oct 2018 01:06:48 +0300 Subject: Proposal Extending API for Streams (or other potentially long builder or chain calls) In-Reply-To: <11632ddd-5957-ef44-29ce-b6c86038d85a@oracle.com> References: <11632ddd-5957-ef44-29ce-b6c86038d85a@oracle.com> Message-ID: Hello Ivan, Yes. It is practically the same request, only method name is different. I do not particularly care how this method is called. So I'm not only one who miss this method. In the next thread the name "transform" is proposed to match method for String. jOO? uses name "transform" too. Kotlin names this method "let", and implemented it using an extension method on Object, at such moments I wish Java had extension methods too. Best Regards, Konstantin Plotnikov On Mon, Oct 29, 2018 at 8:46 PM Ivan Gerasimov wrote: > Hello Constantine! > It seems that a request for such method was made in JDK-8210372 > . > I like the method name chain(), proposed in that request. > > With kind regards, > Ivan > > > On 10/26/18 2:13 AM, Constantine Plotnikov wrote: > > Hello All! > > This email was previously filled as a feature request for JDK, I was > forwarded here to write it as an email. > > Currently, if one needs to skip some stage or provide a group of reused > stages one to have to do the following: > > Stream s = collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty()); > s = useSecuriytFilter(s, session) > return s.collect(Collector.toList()); > > Or like: > > return useSecuriytFilter(collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty()) > , session); > .collect(Collector.toList()); > > In both cases, readability is of code is not high, as fluent sequence of > actions is interrupted. > > It is suggested to add "process" method to stream like the following > signature: > > default R process(Function, R> body) { > return body.apply(this); > } > > Then custom processing could be applied like the following: > > return collection.stream() > .map(a -> doIt(a, bb)) > .filter(a -> !a.list().isEmpty() > .process( s -> useSecuriytFilter(s, session)) > .collect(Collector.toList()); > > While semantics is the same, the code structure looks much better. Note > this proposed change is not about less typing, but about making local > processing looking more local, rather than affecting entire processing > pipeline visually. > > The detailed description for motivation is here: > https://dzone.com/articles/making-java-fluent-api-more-flexible > > Some other libraries with processing chain usage pattern like date-time > classes in java.util.time could benefit from this too as common blocks of > date arithmetic could be reused in more clean way. > > A possibly better alternative to this functionality is the support for > extension methods like in Groovy, Kotlin, or C#, so users will be able to > create such methods when needed themselves, not waiting for library > designers. I think extension methods are good innovation enablers, as they > allow users of JDK or some library to try new API ideas in the practice > first, and than to discuss their experience with component authors. > > Best Regards, > Konstantin Plotnikov > > > > -- > With kind regards, > Ivan Gerasimov > >