Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3]

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Wed, 8 Mar 2023 01:53:14 GMT, Fei Yang wrote:

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v4]

> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in > Interpreter and C1 compiler to produce the same results as C2 intrinsics on > x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java > methods were implemented originally. > > Replaced

Re: Testing no memory leak occurs via references

Having just a very few sources of wisdom on this in the JDK test suites is a good idea because then any tests that might be affected by policy changes would be easily spotted. I say this despite an instinctive reticence to rely on "frameworks" and "utilities" in jtreg tests. As resources allow

Integrated: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes

Re: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources

On Wed, 8 Mar 2023 02:31:09 GMT, Joe Darcy wrote: >> This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. >> >> Thanks. > > Sorry for the noise (and missing IEEERemainer)! Thanks @dholmes-ora . Thanks for the reviews @jddarcy and @bplb ! - PR:

Re: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources

On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes wrote: > This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. > > Thanks. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12916

Re: RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources

On Wed, 8 Mar 2023 02:27:21 GMT, David Holmes wrote: > This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. > > Thanks. Sorry for the noise (and missing IEEERemainer)! Thanks @dholmes-ora . - Marked as reviewed by darcy (Reviewer). PR:

RFR: 8303799: [BACKOUT] JDK-8302801 Remove fdlibm C sources

This reverts commit b5b5cba7feb0e7ef957fd6bef1e591fdb6fdaa9f. Thanks. - Commit messages: - Revert "8302801: Remove fdlibm C sources" Changes: https://git.openjdk.org/jdk/pull/12916/files Webrev: https://webrevs.openjdk.org/?repo=jdk=12916=00 Issue:

Re: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801

On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy wrote: > Quick port of IEEEremainder; sorry for missing this earlier. Will add > targeted tests in a follow-up fix. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.org/jdk/pull/12915

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3]

On Tue, 7 Mar 2023 21:38:38 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in >> Interpreter and C1 compiler to produce the same results as C2 intrinsics on >> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java

Re: RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801

On Wed, 8 Mar 2023 01:30:58 GMT, Joe Darcy wrote: > Quick port of IEEEremainder; sorry for missing this earlier. Will add > targeted tests in a follow-up fix. I can't attest to the correctness of the algorithm but I assume the necessary testing has been done in that regard. I can attest to

RFR: JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801

Quick port of IEEEremainder; sorry for missing this earlier. Will add targeted tests in a follow-up fix. - Commit messages: - Fixes. - JDK-8303794: IEEEremainder problems are causing test failures after JDK-8302801 Changes: https://git.openjdk.org/jdk/pull/12915/files Webrev:

Re: Integrated: JDK-8302801: Remove fdlibm C sources

Please note this fix has a problem with a missing definition for IEEEremainder that is causing UnsatisfiedLinkError. You can expect some significant noise in testing above tier 1 until this is fixed - which will hopefully be in the next 30 minutes or so. Otherwise a Backout will be performed.

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that > concatenates the 2 inputs into an intermediate composite and extracts a > window equal to the size of the inputs into the result. It is used in vector >

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that > concatenates the 2 inputs into an intermediate composite and extracts a > window equal to the size of the inputs into the result. It is used in vector >

Re: RFR: 8171156: Class java.util.LocaleISOData has outdated information for country Code NP

On Tue, 7 Mar 2023 22:55:56 GMT, Justin Lu wrote: > The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for > Nepal. > > According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the >

RFR: 8171156: Class java.util.LocaleISOData has outdated information for country Code NP

The java.util.LocaleISOData.isoCountryTable has an incorrect formal name for Nepal. According to [Wikipedia](https://en.wikipedia.org/wiki/Nepal) and the [UN](https://www.un.int/protocol/sites/www.un.int/files/Protocol%20and%20Liaison%20Service/officialnamesofcountries.pdf), Nepal's formal

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v3]

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- > Implemented `Float.floatToFloat16` and

Integrated: 8302791: Add specific ClassLoader object to Proxy IllegalArgumentException message

On Sun, 19 Feb 2023 08:28:37 GMT, Ravali Yatham wrote: > Added specific class loader object to proxy IllegalArgumentException from > which the class was not visible > > The bug report for the same: https://bugs.openjdk.org/browse/JDK-8302791 This pull request has now been integrated.

Integrated: JDK-8302801: Remove fdlibm C sources

On Thu, 2 Mar 2023 05:54:52 GMT, Joe Darcy wrote: > While the review of https://github.com/openjdk/jdk/pull/12800 finishes up, I > thought I'd get out for the review the next phase of the FDLIBM port: > removing the FDLIBM C sources from the repo. > > A repo with the changes for JDK-8302027

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter

On Tue, 7 Mar 2023 18:28:46 GMT, Jatin Bhateja wrote: >> @sviswa7 I update changes based on your comments. Please, look: >> [9302d4b](https://github.com/openjdk/jdk/pull/12869/commits/9302d4bc00f8f1d8e774a260eb6aacb2d51a2dd4) > > Hi @vnkozlov , There is some discrepancy in results b/w

Withdrawn: 8303431: [JVMCI] libgraal annotation API

On Wed, 1 Mar 2023 18:07:34 GMT, Doug Simon wrote: > This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing > annotations. The main differences from `java.lang.reflect.AnnotatedElement` > are: > * Each `Annotated` method explicitly specifies the annotation type(s) for >

Re: RFR: 8303431: [JVMCI] libgraal annotation API [v3]

On Sun, 5 Mar 2023 22:37:38 GMT, Doug Simon wrote: >> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for >> accessing annotations. The main differences from >> `java.lang.reflect.AnnotatedElement` are: >> * Each `Annotated` method explicitly specifies the annotation type(s)

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2]

On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in >> Interpreter and C1 compiler to produce the same results as C2 intrinsics on >> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2]

On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in >> Interpreter and C1 compiler to produce the same results as C2 intrinsics on >> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2]

On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in >> Interpreter and C1 compiler to produce the same results as C2 intrinsics on >> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2]

On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in >> Interpreter and C1 compiler to produce the same results as C2 intrinsics on >> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter

On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote: >> Other than the minor comments above, the x86 side changes look good to me. > > @sviswa7 I update changes based on your comments. Please, look: >

Integrated: 6453901: (cal) clean up sun.util.calendar classes

On Wed, 1 Mar 2023 21:58:15 GMT, Justin Lu wrote: > This PR includes cleanup changes to the sun.util.calendar package only. > > The changes include removing unused methods, imports, adjusting incorrect > links, and using newer syntax patterns. Since there are no plans to promote > any of

Re: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice

On Tue, 7 Mar 2023 18:23:42 GMT, Quan Anh Mai wrote: > `Vector::slice` is a method at the top-level class of the Vector API that > concatenates the 2 inputs into an intermediate composite and extracts a > window equal to the size of the inputs into the result. It is used in vector >

RFR: 8303762: [vectorapi] Intrinsification of Vector.slice

`Vector::slice` is a method at the top-level class of the Vector API that concatenates the 2 inputs into an intermediate composite and extracts a window equal to the size of the inputs into the result. It is used in vector conversion methods where the part number is not 0 to slice the parts to

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter

On Tue, 7 Mar 2023 03:00:34 GMT, Vladimir Kozlov wrote: >> Other than the minor comments above, the x86 side changes look good to me. > > @sviswa7 I update changes based on your comments. Please, look: >

Integrated: 8303275: Use {@Return and @linkplain in Locale and related classes

On Tue, 28 Feb 2023 00:09:45 GMT, Justin Lu wrote: > This PR modifies the javadoc of methods in Locale, LocaleServiceProvider, and > LocaleServiceProviderPool to use {@return and @linkplain. This pull request has now been integrated. Changeset: acf89961 Author:Justin Lu Committer: Naoto

Integrated: 8217496: Matcher.group() can return null after usePattern

On Thu, 2 Mar 2023 17:13:28 GMT, Ian Graves wrote: > Updates to the documentation to describe behavior in Matcher.group(). This pull request has now been integrated. Changeset: ac3ab5b0 Author:Ian Graves URL:

Re: RFR: 8302976: C2 intrinsification of Float.floatToFloat16 and Float.float16ToFloat yields different result than the interpreter [v2]

On Tue, 7 Mar 2023 02:53:48 GMT, Vladimir Kozlov wrote: >> Implemented `Float.floatToFloat16` and `Float.float16ToFloat` intrinsics in >> Interpreter and C1 compiler to produce the same results as C2 intrinsics on >> x64, Aarch64 and RISC-V - all platforms where C2 intrinsics for these Java

Re: RFR: 8294982: Implementation of Classfile API [v55]

> This is root pull request with Classfile API implementation, tests and > benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, > and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) > will chain to this one.

Re: RFR: 8294982: Implementation of Classfile API [v54]

> This is root pull request with Classfile API implementation, tests and > benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, > and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) > will chain to this one.

Re: RFR: 8294982: Implementation of Classfile API [v43]

On Tue, 7 Mar 2023 14:35:22 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line >> 176: >> >>> 174: } >>> 175: >>> 176: public static long nextPowerOfTwo( long x ) { >> >> If you like you can change the implementation to be: >> >> x

Re: RFR: 8294982: Implementation of Classfile API [v49]

On Tue, 7 Mar 2023 15:48:22 GMT, Maurizio Cimadamore wrote: >> Here I'm also not sure I understand, the long line has bee wrapped. > > I mean here (and in the other) there seems to be a missing newline at the end > of the file OK, I'll fix it, thanks. - PR:

Re: RFR: 8294982: Implementation of Classfile API [v49]

On Tue, 7 Mar 2023 14:48:43 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line >> 194: >> >>> 192: return (int)s; >>> 193: } >>> 194: } >> >> newline! > > Here I'm also not sure I understand, the long line has bee wrapped. I mean

Re: RFR: 8294982: Implementation of Classfile API [v36]

On Tue, 7 Mar 2023 08:35:34 GMT, Adam Sotona wrote: >> I am unsure how you might use `BlockCodeBuilder`. If the current signature >> is not changed then `transformFromHandler` seems reasonable (since its the >> handler that pushes elements into its given builder). >> >> The other `transform`

Integrated: 8303480: Miscellaneous fixes to mostly invisible doc comments

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo wrote: > Please review this superficial documentation cleanup that was triggered by > unrelated analysis of doc comments in JDK API. > > The only effect that this multi-area PR has on the JDK API Documentation > (i.e. the observable effect on the

Re: RFR: 8294982: Implementation of Classfile API [v53]

> This is root pull request with Classfile API implementation, tests and > benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, > and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) > will chain to this one.

Re: RFR: 8294982: Implementation of Classfile API [v52]

> This is root pull request with Classfile API implementation, tests and > benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, > and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) > will chain to this one.

Re: RFR: 8294982: Implementation of Classfile API [v49]

On Tue, 7 Mar 2023 11:14:17 GMT, Maurizio Cimadamore wrote: >> Adam Sotona has updated the pull request incrementally with one additional >> commit since the last revision: >> >> snippets and tests synced with jdk.jfr class instrumentation source code > >

RFR: 8303648: Add String.indexOf(String str, int beginIndex, int endIndex)

As a followup of [JDK-8302590](https://bugs.openjdk.org/browse/JDK-8302590), this issue covers the analogous case for a search of a string rather than a character. - Commit messages: - 8303648: Add String.indexOf(String str, int beginIndex, int endIndex) Changes:

Re: RFR: 8294982: Implementation of Classfile API [v36]

On Fri, 3 Mar 2023 15:51:25 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/NewObjectInstruction.java >> line 38: >> >>> 36: * of a {@link CodeModel}. >>> 37: */ >>> 38: public sealed interface NewObjectInstruction extends Instruction >> >> Should

Re: RFR: 8294982: Implementation of Classfile API [v15]

On Wed, 15 Feb 2023 14:24:18 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/instruction/CharacterRange.java >> line 47: >> >>> 45: * {@return the start of the instruction range} >>> 46: */ >>> 47: Label startScope(); >> >> I noticed that this

Re: RFR: 8294982: Implementation of Classfile API [v43]

On Fri, 3 Mar 2023 22:48:23 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - fixed AccessFlags javadoc >> - TransformImpl.FakeXyzTransform renamed to UnresolvedXyzTransform >> - removed

Re: RFR: 8294982: Implementation of Classfile API [v12]

On Mon, 6 Feb 2023 14:25:54 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line >> 1371: >> >>> 1369: } >>> 1370: >>> 1371: default CodeBuilder tableswitch(Label defaultTarget, >>> List cases) { >> >> `switch` seems the one instruction

Re: RFR: 8294982: Implementation of Classfile API [v36]

On Thu, 2 Mar 2023 22:05:24 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional >> commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > >

Re: RFR: 8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview) [v10]

> Implementation of "Foreign Function & Memory API" for linux on Power (Little > Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification". > > This PR does not include code for VaList support because it's supposed to get > removed by

Re: RFR: 8294982: Implementation of Classfile API [v51]

> This is root pull request with Classfile API implementation, tests and > benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, > and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) > will chain to this one.

Re: ZipOutputStream & directories

Morning I will take care of this for you -- Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPhone On Mar 7, 2023, at 7:31 AM, Eirik

Re: ZipOutputStream & directories

> > For the note then you might want to change it to "ZipEntry e = ..." > because the reader see the trailing slash after dir so it is obviously a > directory. > That does indeed make more sense for the general case. > Also the javadoc uses "crc-32" rather than "crc" should we should keep >

Re: RFR: 8294982: Implementation of Classfile API [v50]

> This is root pull request with Classfile API implementation, tests and > benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, > and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) > will chain to this one.

Re: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2]

On Tue, 7 Mar 2023 10:23:52 GMT, Viktor Klang wrote: >> I think the following proposal is very non-invasive and merely draws >> attention to the fact that "witness value" is a specific term related to the >> notion of these atomic methods. >> >> It's a small change which I think provides

Re: ZipOutputStream & directories

On 07/03/2023 08:21, Eirik Bjørsnøs wrote: : Seems we reached consensus that the right thing to do here is to add an `@apiNote` Here's a draft PR with a suggested CSR: https://github.com/openjdk/jdk/pull/12899

Re: RFR: 8294982: Implementation of Classfile API [v36]

On Thu, 2 Mar 2023 23:49:24 GMT, Paul Sandoz wrote: >> Adam Sotona has updated the pull request incrementally with one additional >> commit since the last revision: >> >> StackMapFrameInfo extracted to top level from StackMapTableAttribute > >

Re: RFR: 8294982: Implementation of Classfile API [v49]

On Mon, 6 Mar 2023 17:11:42 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and >> benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, >> and transforming >>

Re: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments [v2]

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo wrote: >> Please review this superficial documentation cleanup that was triggered by >> unrelated analysis of doc comments in JDK API. >> >> The only effect that this multi-area PR has on the JDK API Documentation >> (i.e. the observable effect on

Re: RFR: 8294982: Implementation of Classfile API [v49]

On Mon, 6 Mar 2023 17:11:42 GMT, Adam Sotona wrote: >> This is root pull request with Classfile API implementation, tests and >> benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, >> and transforming >>

Re: RFR: 8294982: Implementation of Classfile API [v36]

On Fri, 3 Mar 2023 16:33:49 GMT, Adam Sotona wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java >> line 63: >> >>> 61: private static final Runnable NOTHING = () -> { }; >>> 62: >>> 63: interface FakeClassTransform extends ClassTransform { >> >>

Re: RFR: JDK-8297605 DelayQueue javadoc is confusing

On Tue, 7 Mar 2023 03:53:59 GMT, Martin Buchholz wrote: >>> @Martin-Buchholz @pavelrappo OTOH I see that DelayQueue _has already_ >>> overridden `remove(Object o)` so you should be able to modify that? >> >> Right. But remove(Object) unlike remove() doesn't consider the expiration >> time.

Re: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2]

> I think the following proposal is very non-invasive and merely draws > attention to the fact that "witness value" is a specific term related to the > notion of these atomic methods. > > It's a small change which I think provides additional clarity, see JBS for > the discussion on the topic.

Re: RFR: JDK-8302360 Atomic*.compareAndExchange Javadoc unclear [v2]

On Tue, 7 Mar 2023 02:43:42 GMT, David Holmes wrote: >> Viktor Klang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Reverting wording change to AtomicReference compareAndExchange > >

Re: Testing no memory leak occurs via references

> On Mar 6, 2023, at 10:11 AM, Aleksei Ivanov wrote: > > On 06/03/2023 13:51, Albert Yang wrote: >> Upon a cursory inspection of ForceGC.java, it seems that the fundamental >> logic involves waiting for a certain duration and relying on chance. >> However, I am of the opinion that utilizing

Re: ZipOutputStream & directories

> > It would require re-specifying ZOS.setMethod to set the default > compression method for non-directory entries and re-specifying > ZOS.putNextEntry to use the STORED method as the default for directory > entries. Even so, this wouldn't ensure that directory entries have 0 size. > Given that

Re: RFR: 8294982: Implementation of Classfile API [v36]

On Mon, 6 Mar 2023 17:45:27 GMT, Paul Sandoz wrote: >> I see what you mean. `transforming` was selected to represent the >> continuation of the code building process, similar to `trying` and >> `catching`. While `transform` may imply that the actual code builder gets >> transformed into

Re: ZipOutputStream & directories

On 06/03/2023 20:20, Eirik Bjørsnøs wrote: : I was not thinking of changing anything if the caller actually specified a method. This would be just for the default/unspecified case, in which case ZipEntry.method is -1. It would require re-specifying ZOS.setMethod to set the default

Re: ZipOutputStream & directories

On Mon, Mar 6, 2023 at 9:33 PM Lance Andersen wrote: > Adding an API Note will require a CSR. > Lance, Alan Seems we reached consensus that the right thing to do here is to add an `@apiNote` Here's a draft PR with a suggested CSR: https://github.com/openjdk/jdk/pull/12899 Thanks, Eirik.