Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

2021-03-08 Thread Lance Andersen
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Looks good -

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-03-04 Thread Lance Andersen
03/03/21 9:14 pm, Lance Andersen wrote: Some other things needed to be defined and agreed upon in order to move forward * The behavior if the path does not exist * If the option is specified more than once on the command line * Clarify the behavior if any of the files exist

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-03-03 Thread Lance Andersen
>> wrote: Thank you Lance. So I think there's some level of agreement on using -C and --dir (or --directory) for the option names. Anymore opinion on the directory creation semantics and any other aspects to consider? -Jaikiran On 28/02/21 5:38 pm, Lance Andersen wrote: Hi Jaikiran,

Re: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

2021-03-02 Thread Lance Andersen
On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons wrote: > Please review some minor doc fixes, for issues found by _doccheck_.There > are two kinds of errors that are addressed. > > 1. Incorrect use of ``. In HTML, `` marks the *beginning* of a > paragraph. It is not a terminator, to mark

Re: RFR: 8261670: Add javadoc for the XML processing limits [v4]

2021-03-01 Thread Lance Andersen
On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revisio

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-28 Thread Lance Andersen
e to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting. -Jaikiran [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-27 Thread Lance Andersen
wrote: On 27/02/21 1:17 am, Lance Andersen wrote: I believe this would also warrant a CSR to be created as well as updates to the jar man page. I haven't created a CSR before, so I will need some guidance on that part. Is it usually created after all the implementation details have been d

Re: RFR: 8173970: jar tool should have a way to extract to a directory

2021-02-26 Thread Lance Andersen
pull/2752/head:pull/2752 PR: https://git.openjdk.java.net/jdk/pull/2752 [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

2021-02-26 Thread Lance Andersen
On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang wrote: >> Add the documentation for XML processing limits to module summary. The >> limits were previously documented in Java tutorial and guide. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revisi

Re: RFR: JDK-8262433: doclint: reference error in module jdk.incubator.foreign

2021-02-25 Thread Lance Andersen
On Fri, 26 Feb 2021 00:41:18 GMT, Jonathan Gibbons wrote: > Please review a simple fix to ensure that a link reference is resolved and > displayed correctly. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2739

Re: RFR: JDK-8262428: doclint warnings in java.xml module

2021-02-25 Thread Lance Andersen
On Thu, 25 Feb 2021 22:41:46 GMT, Jonathan Gibbons wrote: > Please review a small doc fix to remove some superfluous `` tags and an > erroneous `` tag, all reported by doclint.. Looks OK. Joe is in the process of updating module-info so perhaps this can be combined with his change?

Re: ZipInputStream#readAllBytes should clarify it doesn't read the whole stream?

2021-02-25 Thread Lance Andersen
ocs/api/java.base/java/util/zip/ZipInputStream.html#read(byte%5B%5D,int,int) -Jaikiran [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com<mailto:lance.ander...@oracle.com>

Re: RFR: 8262041: javax/xml/jaxp/unittest/common/prettyprint/PrettyPrintTest.java fails after JDK-8260858

2021-02-19 Thread Lance Andersen
On Fri, 19 Feb 2021 22:12:35 GMT, Joe Wang wrote: > A quick fix to the test, removing Windows carriage return in the result. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2656

Re: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter [v2]

2021-02-17 Thread Lance Andersen
On Wed, 17 Feb 2021 20:18:56 GMT, Naoto Sato wrote: >> Please review this simple doc fix. A CSR will be filed accordingly. > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Made the additional text an @apiNote Marked as review

Re: RFR: 8261728: SimpleDateFormat should link to DateTimeFormatter

2021-02-17 Thread Lance Andersen
On Wed, 17 Feb 2021 19:34:47 GMT, Naoto Sato wrote: > Please review this simple doc fix. A CSR will be filed accordingly. Hi Naoto, Looks good. Any thoughts to making the new wording stick out more perhaps via a something like "Note: Consider" and bolding "Note:" Not sure if it is @

Re: RFR: JDK-8260858: Implementation specific property xsltcIsStandalone for XSLTC Serializer

2021-02-14 Thread Lance Andersen
On Sat, 13 Feb 2021 00:16:50 GMT, Joe Wang wrote: > Adds a property similar to 'isStandalone' in JDK-8249867. > > Please note that the test received an auto-format. The material changes were > the two tests marked with bug id 8260858 and related data and methods. Marked as reviewed by lancea (

Re: RFR: 8261306: ServiceLoader documentation has malformed Unicode escape

2021-02-08 Thread Lance Andersen
On Tue, 9 Feb 2021 00:11:52 GMT, Brian Burkhalter wrote: > Please review this really small correction to the class level documentation > of `java.util.ServiceLoader`. I think this is fine. You could also probably use &num given this is HTML I believe - Marked as reviewed by lanc

Re: RFR: 8261279: sun/util/resources/cldr/TimeZoneNamesTest.java timed out

2021-02-08 Thread Lance Andersen
On Mon, 8 Feb 2021 21:42:36 GMT, Naoto Sato wrote: > Please review this simple test case fix. By sampling locales to test, it > reduces the possibility of the time out. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2465

Re: RFR: 8261209: isStandalone property: remove dependency on pretty-print

2021-02-06 Thread Lance Andersen
On Sat, 6 Feb 2021 00:38:15 GMT, Joe Wang wrote: > A quick fix to remove isStandalone's dependency on pretty-print. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2442

Re: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v4]

2021-02-02 Thread Lance Andersen
On Tue, 2 Feb 2021 10:40:01 GMT, Claes Redestad wrote: >> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is >> only used from ZipFile.initCEN right after the checkEncoding today, so >> verifying this is equivalent is straightforward. >> - Factor out the logic to calculat

Re: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation [v3]

2021-01-31 Thread Lance Andersen
On Sat, 30 Jan 2021 18:30:59 GMT, Claes Redestad wrote: >> - Merge checkEncoding into the byte[]-based normalizedHash. The latter is >> only used from ZipFile.initCEN right after the checkEncoding today, so >> verifying this is equivalent is straightforward. >> - Factor out the logic to calcula

Re: RFR: 8260617: Merge ZipFile encoding check with the initial hash calculation

2021-01-29 Thread Lance Andersen
On Fri, 29 Jan 2021 00:54:46 GMT, Claes Redestad wrote: > - Merge checkEncoding into the byte[]-based normalizedHash. The latter is > only used from ZipFile.initCEN right after the checkEncoding today, so > verifying this is equivalent is straightforward. > - Factor out the logic to calculate h

Re: RFR: 8249867: xml declaration is not followed by a newline [v3]

2021-01-29 Thread Lance Andersen
On Fri, 29 Jan 2021 17:52:33 GMT, Daniel Fuchs wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Updated the patch based on review comments. Refer to the previous reviews. > > src/java.xml/share/classes/module-info.java

Re: RFR: 8249867: xml declaration is not followed by a newline [v3]

2021-01-29 Thread Lance Andersen
On Fri, 29 Jan 2021 00:07:59 GMT, Joe Wang wrote: >> Please review a patch to add an explicit control over whether a newline >> should be added after the XML header. This is done by adding a DOM >> LSSerializer property "jdk-is-standalone" and System property >> "jdk.xml.isStandalone". >> >>

Re: RFR: 8260561: [doc] HexFormat has incorrect @since tag

2021-01-27 Thread Lance Andersen
On Wed, 27 Jan 2021 22:10:01 GMT, Roger Riggs wrote: > A doc-only change to correct the @ since tag. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2270

Re: RFR: 8259816: Typo in java.util.stream package description

2021-01-27 Thread Lance Andersen
On Wed, 27 Jan 2021 03:18:09 GMT, Stuart Marks wrote: > Fix a typo, and change an example to use Stream.toList(). Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2249

Re: RFR: 8249867: xml declaration is not followed by a newline [v2]

2021-01-27 Thread Lance Andersen
On Wed, 27 Jan 2021 06:33:01 GMT, Joe Wang wrote: >> Please review a patch to add an explicit control over whether a newline >> should be added after the XML header. This is done by adding a DOM >> LSSerializer property "jdk-is-standalone" and System property >> "jdk.xml.isStandalone". >> >>

Re: RFR: 8260010: UTF8ZipCoder not thread-safe since JDK-8243469 [v2]

2021-01-20 Thread Lance Andersen
On Wed, 20 Jan 2021 13:03:04 GMT, Claes Redestad wrote: >> This patch resolves a thread-safety issue where the singleton UTF8ZipCoder >> is erroneously using a shared CharsetDecoder when the fast-path fails. It >> needs to go via JLA.newStringUTF8NoRepl like before JDK-8243469 >> >> This shoul

Re: RFR: 8259867: Move encoding checks into ZipCoder

2021-01-19 Thread Lance Andersen
On Sat, 16 Jan 2021 17:49:38 GMT, eirbjo wrote: > ZipFile.Source.initCEN verifies that entry names are encoding into bytes > valid in the entry's encoding. It does so by calling encoding-specific > checking methods, so it also needs to determine which check method to call > for each entry. >

Re: [jdk16] RFR: 8259298: broken link in Stream::toList spec

2021-01-11 Thread Lance Andersen
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote: > Just fixing a broken link. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/106

Re: RFR: 8259528: Broken Link for [java.text.Normalizer.Form]

2021-01-11 Thread Lance Andersen
On Mon, 11 Jan 2021 16:54:53 GMT, Naoto Sato wrote: > Please review this simple doc fix. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2028

Re: RFR: 8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys

2021-01-08 Thread Lance Andersen
On Fri, 8 Jan 2021 20:34:10 GMT, Roger Riggs wrote: > Cleanup of tests test/jdk/java/net and test/jdk/sun/net that format > hexadecimal strings to use java.util.HexFormat methods. > Also in tests test/jdk/java/util/Locale/SoftKeys. Looks good Roger. Nice cleanup. - Marked as revi

Re: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

2020-12-17 Thread Lance Andersen
On Wed, 16 Dec 2020 14:42:36 GMT, Richard Fussenegger wrote: > > There is very little value in adding the exception doing so might prevent > > existing applications from continuing to function. > > I disagree on the value and am with the author of the original issue. All > these existing appl

Re: RFR: 8253497: Core Libs Terminology Refresh [v2]

2020-12-15 Thread Lance Andersen
On Tue, 15 Dec 2020 21:57:17 GMT, Brian Burkhalter wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> updates, per code review > > test/jdk/java/lang/ClassLoader/Assert.java line 65: > >> 63: >> 64: int s

Re: RFR: 8248383: Clarify java.io.Reader.read(char[], ...) behavior for full array

2020-12-10 Thread Lance Andersen
On Thu, 10 Dec 2020 17:22:06 GMT, Brian Burkhalter wrote: > Please review this small verbiage change to specify clearly the behavior of > `Reader::read(char[] cbuf)` when the length of `cbuf` is zero, and that of > `Reader::read(char[] cbuf, int off, int len)` when `len` is zero. Hi Brian, Ar

Re: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final [v2]

2020-12-04 Thread Lance Andersen
On Fri, 4 Dec 2020 17:22:29 GMT, Brian Burkhalter wrote: >> Please review this trivial change to make the `writeBuffer` array field >> final and move it to the beginning of the class where other fields are >> declared. > > Brian Burkhalter has updated the pull request incrementally with one >

Re: RFR: 8257750: writeBuffer field of java.io.DataOutputStream should be final

2020-12-04 Thread Lance Andersen
On Fri, 4 Dec 2020 16:58:56 GMT, Brian Burkhalter wrote: > Please review this trivial change to make the `writeBuffer` array field final > and move it to the beginning of the class where other fields are declared. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.

Re: RFR: 8228615: Optional.empty doc should suggest using isEmpty

2020-12-02 Thread Lance Andersen
On Thu, 3 Dec 2020 01:08:18 GMT, Stuart Marks wrote: > Some small doc changes. The changes are to `@apiNote` text, which is > non-normative, so no CSR is required. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1585

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

2020-11-29 Thread Lance Andersen
FileSystems.newFileSystem(Paths.get(ZIP_FILE_NAME), > Map.of("zipinfo-time", "False"))) { > You are right though, it would be clearer if I change it to Map.of(); Thank you for pointing that out Best Lance > Anyway, the problem is fixed.

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

2020-11-28 Thread Lance Andersen
would as well. I will look to reproduce the issue over the weekend or early next week and log a bug with what you provided in your earlier email. Best Lance > > D. > > On Fri, Nov 27, 2020 at 8:37 PM Lance Andersen <mailto:lance.ander...@oracle.com>> wrote: > Hi Dawi

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

2020-11-27 Thread Lance Andersen
>>> an unchecked exception while attribute-scanning. This simple snippet >>> is enough to demonstrate it, given a ZIP entry beyond 4GB range: >>> >>> try (FileSystem fs = >>> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {

Re: RFR: 8170432: Class java.util.UUID & @Override

2020-11-27 Thread Lance Andersen
On Thu, 26 Nov 2020 17:01:59 GMT, Richard Fussenegger wrote: > Adds `@Override` annotation to all methods in `java.util.UUID` that implement > methods from the implemented interfaces. Looks fine. It appears you need a sponsor so I can do that once you integrate - Marked as revie

Re: RFR: 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay

2020-11-25 Thread Lance Andersen
On Wed, 25 Nov 2020 20:13:48 GMT, Daniel Fuchs wrote: > Hi, > > Please find here an almost trivial fix for: > 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly > delay > > The two tests are changed from using Math.random() to using the jdk test lib > RandomFactory, wh

Re: RFR: 8256839: JavaDoc for java.time.Period.negated() method

2020-11-23 Thread Lance Andersen
On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Thanks. Looks fine and this is validated via test/jdk/java/time/tck/java/time/TCKPeriod.java, - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/139

Re: RFR: 8246739: InputStream.skipNBytes could be implemented more efficiently [v2]

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter wrote: >> Please review this modification of `java.io.InputStream.skipNBytes(long)` to >> improve its performance when `skip(long)` skips fewer than the requested >> number of bytes. In the current implementation, `skip(long)` is invoked once

Re: RFR: 8211449: Correction to the spec of implicit negative subpattern in DecimalFormat

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato wrote: > Hi, > > Please review this doc only fix to the class description of `DecimalFormat` > class. `localized minus sign` has never been (and should never be) used in > the implicit negative subpattern. Actual implementation correctly uses ascii

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 17:08:21 GMT, Alan Bateman wrote: >> Small change to retrieve the raw bytes of manifest during verifying signed >> JAR. > > Marked as reviewed by alanb (Reviewer). I can sponsor once you integrate - PR: https://git.openjdk.java.net/jdk/pull/1299

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-19 Thread Lance Andersen
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1299

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 16:36:02 GMT, Daniel Fuchs wrote: >> test/jdk/java/lang/StackWalker/Basic.java line 116: >> >>> 114: /** For TestNG */ >>> 115: public Basic() { >>> 116: depth = 0; >> >> Is the assignment really ended here? I only see: >> >> Basic test = new Basic(depth[0]

Re: RFR: 8256154: Some TestNG tests require default constructors

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary wrote: > In TestNG 7, it is a requirement that TestNG is able to create a Test object > using a default constructor. > > This simple fix addresses two such classes so that this requirement is > satisfied by inserting default construtors. Example:

Re: RFR: 8256183: InputStream.skipNBytes is missing @since 12

2020-11-19 Thread Lance Andersen
On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary wrote: > InputStream.skipNBytes is missing `@since 12` tag which was not added during > the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099). > > This small fix adds the `@since` tag to InputStream.skipNBytes Marked as rev

Re: RFR: 8253299: Manifest bytes are read twice when verifying a signed JAR

2020-11-18 Thread Lance Andersen
On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao wrote: > Small change to retrieve the raw bytes of manifest during verifying signed > JAR. The changes looks good. I am assuming that we do not need an additional test for this and if so, please add a noreg label such as noreg-trivial to the bug

Re: RFR: 8256244: java/lang/ProcessHandle/PermissionTest.java fails with TestNG 7.1

2020-11-12 Thread Lance Andersen
On Thu, 12 Nov 2020 15:48:33 GMT, Roger Riggs wrote: > TestNG 7.1 changed/corrected the way that @BeforeGroups are selected at > runtime. > The test was depending on @BeforeGroups to initialize common security policy > for a number of tests. > The tests are modified to individually setup the ne

Integrated: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence

2020-11-11 Thread Lance Andersen
On Tue, 10 Nov 2020 21:26:59 GMT, Lance Andersen wrote: > Hi, > > Please review the fix for JDK-8256018 which addresses the issue that the > update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use > Reference.reachabilityFence to ensure that direct byte buffe

Re: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence [v2]

2020-11-11 Thread Lance Andersen
> > The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the > jck:api/java_util/zip,jck:api/java_util/jar continue to run clean. > > Best > Lance Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Remove extr

RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence

2020-11-10 Thread Lance Andersen
Hi, Please review the fix for JDK-8256018 which addresses the issue that the update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly. The Mach5 jdk-tier1, jdk-tier2,

Re: RFR: JDK-8253936 Replace ... with {@code ...} for java.sql [v2]

2020-11-04 Thread Lance Andersen
On Wed, 4 Nov 2020 01:34:13 GMT, Vipin Sharma wrote: >> ... is replaced with {@code ...} in java.sql classes. >> Please review and sponsor this change. > > Vipin Sharma has updated the pull request incrementally with one additional > commit since the last revision: > > Updated copyright year

Integrated: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false

2020-11-03 Thread Lance Andersen
On Sun, 1 Nov 2020 20:09:32 GMT, Lance Andersen wrote: > Hi, > > Please review the fix for JDK-8255380 which addresses an issue when the Zip > file is > 4GB. Zip FS when processing the CEN extra data does not take into > account the fact that there is no specific order to

Integrated: 8255529: Remove unused methods from java.util.zip.ZipFile

2020-11-02 Thread Lance Andersen
On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen wrote: > Please review this fix for JDK-8255529 which removes methods that were unused > and were added back merge in July > > Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean. This pull request has now been integrated. Changes

RFR: 8255529: Remove unused methods from java.util.zip.ZipFile

2020-11-02 Thread Lance Andersen
Please review this fix for JDK-8255529 which removes methods that were unused and were added back merge in July Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean. - Commit messages: - Remove unused methods Changes: https://git.openjdk.java.net/jdk/pull/1015/files Webrev: https://we

Re: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false [v3]

2020-11-01 Thread Lance Andersen
; > Info-zip is included with Mac OS so the test uses ProcessBuilder to execute > zip on Mac OS and Linux. > > Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly. > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additio

Re: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false [v2]

2020-11-01 Thread Lance Andersen
On Sun, 1 Nov 2020 23:44:53 GMT, Claes Redestad wrote: > Given the need to generate a 4Gb file on the fly I do feel this maybe ought > to be a manual test, or maybe there's some annotation to ensure it's not run > on systems with too little disk space (and no compatible zip). OK, I can make i

Re: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false [v2]

2020-11-01 Thread Lance Andersen
On Sun, 1 Nov 2020 23:04:47 GMT, Claes Redestad wrote: > > To validate the test, requires info-zip which comes on Mac and linux. It is > > not included with windows. There are no issues if the Zip is created via > > java.util.zip or Zip FS > > Ah, gotcha. I see and understand the use of the ex

Re: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false [v2]

2020-11-01 Thread Lance Andersen
On Sun, 1 Nov 2020 22:21:25 GMT, Claes Redestad wrote: > LGTM. Some nits inline. > > I guess the test can be cause for issues in some test systems since it needs > to write out the 4Gb+ file. Is this why you've only enabled it on linux and > mac? Perhaps someone might have ideas on how to impr

Re: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false [v2]

2020-11-01 Thread Lance Andersen
; > Info-zip is included with Mac OS so the test uses ProcessBuilder to execute > zip on Mac OS and Linux. > > Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly. > > Best, > Lance Lance Andersen has updated the pull request incrementally with one additional commit since

RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false

2020-11-01 Thread Lance Andersen
Hi, Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB. Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written. Info-ZIP writes the fields in a different orde

Re: RFR: 8214561: Use {@systemProperty} for definition of "java.util.prefs.PreferencesFactory" system property

2020-10-30 Thread Lance Andersen
On Fri, 30 Oct 2020 19:47:14 GMT, Brent Christian wrote: > Using the {@systemProperty} tag for the "java.util.prefs.PreferencesFactory" > system property will allow it to be found in the main javadoc search index. > > The updated doc build looks good. Marked as reviewed by lancea (Reviewer).

Re: RFR: 8255690:   in StringBuilder.subSequence

2020-10-30 Thread Lance Andersen
On Fri, 30 Oct 2020 19:30:14 GMT, Brent Christian wrote: > There are a couple of stray " "'s in the StringBuilder.subSequence() > documentation, which should be removed. The updated doc build looks good. Looks fine Brent - Marked as reviewed by lancea (Reviewer). PR: https://git

Re: RFR: 8255533: Incorrect javadoc in DateTimeFormatterBuilder.appendPattern() for 'uu'/'yy'

2020-10-28 Thread Lance Andersen
On Wed, 28 Oct 2020 17:35:16 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix in > DateTimeFormatterBuilder.appendPattern(). It is missing the value for > `maxWidth` argument. > > Naoto Looks good - Marked as reviewed by lancea (Reviewer). PR: https://git.ope

Re: RFR: JDK-8255262: Remove use of legacy custom @spec tag

2020-10-22 Thread Lance Andersen
On Thu, 22 Oct 2020 17:16:23 GMT, Jonathan Gibbons wrote: > The change is (just) to remove legacy usages of a JDK-private custom tag. looks fine - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/814

Re: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

2020-10-21 Thread Lance Andersen
zipfs.noExtt is only set to true if: > > this.noExtt = "false".equals(env.get("zipinfo-time")); > > I can't share this particular ZIP file with you and I don't know how > it was created but it seems like that "zipinfo-time" flag could be > omitted if the length of the extra data field is exactly 5? > > Dawid Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com

Re: RFR: JDK-8253936 Replace ... with {@code ...} for java.sql

2020-10-20 Thread Lance Andersen
On Fri, 16 Oct 2020 19:38:45 GMT, Vipin Sharma wrote: > ... is replaced with {@code ...} in java.sql classes. > Please review and sponsor this change. Hi Vipin Thank you for tackling this update. There are a few required changes below. I will also be going through the generated javadoc to se

Re: RFR: JDK-8253936 Replace ... with {@code ...} for java.sql

2020-10-16 Thread Lance Andersen
t/browse/JDK-8253936 > Stats: 4698 lines in 58 files changed: 0 ins; 0 del; 4698 mod > Patch: https://git.openjdk.java.net/jdk/pull/707.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/707/head:pull/707 > > PR: https://git.openjdk.java.net/jdk/pull/707 Best La

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v7]

2020-10-14 Thread Lance Andersen
On Wed, 14 Oct 2020 14:52:29 GMT, Lance Andersen wrote: >> Volker Simonis has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > The chang

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v2]

2020-10-14 Thread Lance Andersen
On Mon, 12 Oct 2020 11:46:31 GMT, Volker Simonis wrote: >> I don't believe we discuss/reference the data descriptor for a Zip entry >> (outside of the PKWare Zip specification) so I >> am not sure we should reference it in the javadoc. >> Placing the sentence after "The default compression meth

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v7]

2020-10-14 Thread Lance Andersen
On Wed, 14 Oct 2020 10:54:30 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v6]

2020-10-13 Thread Lance Andersen
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v6]

2020-10-13 Thread Lance Andersen
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v6]

2020-10-13 Thread Lance Andersen
On Tue, 13 Oct 2020 19:07:33 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v4]

2020-10-13 Thread Lance Andersen
On Tue, 13 Oct 2020 18:46:59 GMT, Alan Bateman wrote: >> Volker Simonis has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now >> contains one commit: >> 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's >> compressed siz

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v4]

2020-10-13 Thread Lance Andersen
On Tue, 13 Oct 2020 11:40:36 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v4]

2020-10-13 Thread Lance Andersen
On Wed, 7 Oct 2020 17:04:02 GMT, Lance Andersen wrote: >> I totally agree. What about using just the last sentence (as you've >> proposed) in the spec section and add the other to >> as @implNote? O you think the last sentence will be enough? > > I think we can j

Re: RFR: 8252537: Updated @exception with @throws [v4]

2020-09-28 Thread Lance Andersen
On Sun, 27 Sep 2020 12:46:21 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks >> of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation o

Re: RFR: 8252537: Updated @exception with @throws [v3]

2020-09-24 Thread Lance Andersen
On Thu, 24 Sep 2020 18:20:15 GMT, Vipin Sharma wrote: > > Overall the changes look OK. in the java.sql set of classes, please updated > > the modified statements to also use {@code} > > Hi @LanceAndersen, it was suggested by @RogerRiggs also. I have created a > separate bug JDK-8253612 to fix

Re: RFR: 8252537: Updated @exception with @throws [v3]

2020-09-24 Thread Lance Andersen
On Sat, 19 Sep 2020 20:24:14 GMT, Vipin Sharma wrote: >> Updated @exception with @throws for core-libs, it fixes all open sub-tasks >> of JDK-8252536. >> >> Open Subtasks part of this fix are: >> 1. JDK-8252537 >> 2. JDK-8252539 >> 3. JDK-8252540 >> 4. JDK-8252541 >> >> Previous conversation o

Integrated: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary

2020-09-23 Thread Lance Andersen
On Sun, 20 Sep 2020 18:03:02 GMT, Lance Andersen wrote: > Hi all, > > Please review the fix for JDK-8252739 which addresses an issue introduced by > https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored > the offset specified by > Deflater.setDictionary

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v4]

2020-09-22 Thread Lance Andersen
On Tue, 22 Sep 2020 07:28:42 GMT, Alan Bateman wrote: > Given that the offset handling is buggy then I think the test should at least > cover the cases where the offset is 0 or > out of bounds. No problem separating out further test coverage for the other > setDictionary methods into a separate

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v5]

2020-09-22 Thread Lance Andersen
; as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add additional offset test cases in DeflaterDictionaryTests.java - Changes: - all: https://git.openj

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3]

2020-09-21 Thread Lance Andersen
On Mon, 21 Sep 2020 12:18:40 GMT, Alan Bateman wrote: > Update to Deflater.c looks good. > > DeflaterDictionaryTests looks like is a shaping up to be a good test for > setDictionary. Are there other assertions that > should be checked, e.g. setDictionary(ByteBuffer) is specified to consume all

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v4]

2020-09-21 Thread Lance Andersen
; as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: More updates to testByteBufferDirect in DeflaterDictionaryTests.java - Changes: - all: https://git.openj

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3]

2020-09-20 Thread Lance Andersen
On Sun, 20 Sep 2020 20:42:30 GMT, Uwe Schindler wrote: >> Minor updates have been made to the tests > > Ok much better for the heap buffers. Many thanks. > > The direct buffers have now contents, but I think it should copy the whole > heap array into the byte buffer. After that > set position

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v3]

2020-09-20 Thread Lance Andersen
; as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: More updates to testByteBufferDirect in DeflaterDictionaryTests.java - Changes: - all: https://git.openj

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v2]

2020-09-20 Thread Lance Andersen
On Sun, 20 Sep 2020 18:29:20 GMT, Uwe Schindler wrote: >> Lance Andersen has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Additional updates to DeflaterDictionaryTests.java > > The tests with byte buffers (

Re: RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary [v2]

2020-09-20 Thread Lance Andersen
; as well as the java/util/zip and > java/util/jar JCK tests. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Additional updates to DeflaterDictionaryTests.java - Changes: - all: https://git.openjdk.java.net/jd

RFR: 8252739: Deflater.setDictionary(byte[], int off, int len) ignores the starting offset for the dictionary

2020-09-20 Thread Lance Andersen
Hi all, Please review the fix for JDK-8252739 which addresses an issue introduced by https://bugs.openjdk.java.net/browse/JDK-8225189, where Deflater.c ignored the offset specified by Deflater.setDictionary. Mach5 jdk-tier1, jdk-tier2, jdk-tier3 runs cleanly as well as the java/util/zip and ja

Re: RFR: 8253153: Mentioning of "hour-of-minute" in java.time.temporal.TemporalField JavaDoc

2020-09-18 Thread Lance Andersen
On Fri, 18 Sep 2020 01:49:09 GMT, Naoto Sato wrote: > Hi, > > Please review this simple doc fix. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/234

Re: RFR: 8253240: No javadoc for DecimalFormatSymbols.hashCode()

2020-09-16 Thread Lance Andersen
On Wed, 16 Sep 2020 17:29:52 GMT, Naoto Sato wrote: > Hi, > > Please review the fix to the issue wrt missing hashCode() javadoc, which was > recently discussed in core-libs ml. Looks in line with the discussion on core-libs. - Marked as reviewed by lancea (Reviewer). PR: https:/

Re: RFR: 6714834: JarFile.getManifest() leaves an open InputStream as an undocumented side effect [v2]

2020-09-15 Thread Lance Andersen
On Tue, 15 Sep 2020 16:59:59 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Remove "final" > > I am fine with this as well. I will pull over the chan

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance) [v4]

2020-09-15 Thread Lance Andersen
On Tue, 15 Sep 2020 12:39:11 GMT, Jaikiran Pai wrote: >> Can I please get a review and a sponsor for this patch which fixes the issue >> reported in >> https://bugs.openjdk.java.net/browse/JDK-8244706? >> The commit here sets the `OS` header flag to `255` (which represents >> `unknown`) as note

Re: RFR: 8244706: GZIP "OS" header flag hard-coded to 0 instead of 255 (RFC 1952 non-compliance)

2020-09-14 Thread Lance Andersen
Hi Joe, Ok, will create one tomorrow. Best Lance > On Sep 14, 2020, at 7:07 PM, Joe Darcy wrote: > > Hi Lance, > > I'd prefer to err on the side of having a CSR; thanks, > > -Joe > > On 9/14/2020 3:55 PM, Lance Andersen wrote: >> Hi Joe, >>

<    1   2   3   4   5   6   7   8   9   10   >