Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Alan Bateman
On Thu, 30 Mar 2023 20:28:52 GMT, Jonathan Gibbons wrote: >> src/java.base/share/classes/java/lang/Thread.java line 1960: >> >>> 1958: * thread. >>> 1959: * >>> 1960: * @spec jni/index.html Java Native Interface Specification >> >> The link to the JNI spec in this met

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Alan Bateman
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1)

2023-03-31 Thread Alan Bateman
On Thu, 30 Mar 2023 20:38:13 GMT, Jonathan Gibbons wrote: > The initial assumption was "after the @param/@return/@throws group". Overall, > as I said in the description for this PR, the block tags are not very > consistent about ordering. I was thinking we might want to recommend an > overall

Re: RFR: 8304919: Implementation of Virtual Threads [v5]

2023-03-31 Thread Alan Bateman
> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The > APIs that were preview APIs in Java 19/20 are changed to permanent and their > `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The > JNI and JVMTI versions are bumped as this is the first chan

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Lance Andersen
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Daniel Fuchs
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Lance Andersen
On Fri, 31 Mar 2023 10:33:50 GMT, Lance Andersen wrote: > Hi Jon, > > This looks fine. I was wondering if we should do the same for java.util.zip > and the PKWare Zip Spec or where java.sql references the JDBC Spec? Well, I must need coffee this morning as obviously JDBC is in the java.sql mo

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Maurizio Cimadamore
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee wrote: >> Rewrite BindingSpecializer to use the new class file API. >> >> Note: There is a big try/catch/finally block generated in the `specialize` >> method that currently uses labels. I looked at replacing this with a call to >> `CodeBuilder::tr

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Maurizio Cimadamore
On Fri, 31 Mar 2023 03:24:22 GMT, Jorn Vernee wrote: >> Classfile API does have some sort of error reporting mechanism in >> verification; at least it tracks the error context. >> https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/src/java.base/share/classes/jdk/interna

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Maurizio Cimadamore
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee wrote: >> Rewrite BindingSpecializer to use the new class file API. >> >> Note: There is a big try/catch/finally block generated in the `specialize` >> method that currently uses labels. I looked at replacing this with a call to >> `CodeBuilder::tr

Re: RFR: 8304265: Implementation of Foreign Function and Memory API (Third Preview) [v16]

2023-03-31 Thread Maurizio Cimadamore
On Thu, 30 Mar 2023 11:28:25 GMT, Per Minborg wrote: >> API changes for the FFM API (third preview) >> >> Specdiff: >> https://cr.openjdk.org/~pminborg/panama/21/v1/specdiff/overview-summary.html >> >> Javadoc: >> https://cr.openjdk.org/~pminborg/panama/21/v1/javadoc/java.base/module-summary.ht

Small survey about JDK-8280101: in String.split grouped regex should keep the delimiter

2023-03-31 Thread Raffaello Giulietti
HI, JBS issue JDK-8280101 [0] proposes to add functionality to String.split() to behave more like the perl equivalent. Rather than returning only the substrings resulting from the split, the perl implementation can return an alternation of the substrings and the matched delimiters when the de

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Adam Sotona
On Fri, 31 Mar 2023 11:22:46 GMT, Maurizio Cimadamore wrote: >> I'm not really looking for anything specific. I'm just trying to figure out >> if it's worth it to keep the `PERFORM_VERIFICATION` flag, and change it to >> call the verifier in the new impl. i.e. does it catch more errors than ju

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v6]

2023-03-31 Thread Quan Anh Mai
> Hi, > > This patch reimplements `VectorShuffle` implementations to be a vector of the > bit type. Currently, VectorShuffle is stored as a byte array, and would be > expanded upon usage. This poses several drawbacks: > > 1. Inefficient conversions between a shuffle and its corresponding vector

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2]

2023-03-31 Thread Quan Anh Mai
On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz wrote: >> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, >> I have to resort to raw types, though, since there seems to be no way to do >> the same with wild cards, and the generics mechanism is not powerful enough >> f

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v5]

2023-03-31 Thread Quan Anh Mai
On Fri, 31 Mar 2023 00:18:21 GMT, Paul Sandoz wrote: >> Quan Anh Mai has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 14 commits: >> >> - move implementations up >> - Merge branch 'master' into shufflerefactor >> - Merge branch

Re: Small survey about JDK-8280101: in String.split grouped regex should keep the delimiter

2023-03-31 Thread Jim Laskey
[IMHO] I think you’ll find that split isn’t everyone’s favourite method for lots of reasons. For example, more often than not I would like to have split guarantee N + 1 elements in the result, where N is the number delimiters found. Case 1: text blocks split on newlines. Case 2: string templates

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Adam Sotona
On Fri, 31 Mar 2023 12:20:49 GMT, Adam Sotona wrote: >> I believe that, in order to generate the actual bytecodes, the classfile API >> does a full verification pass (as it needs to infer the stackmap >> information). This leads me to believe that, yes, most (but probably all) >> errors would

Re: Small survey about JDK-8280101: in String.split grouped regex should keep the delimiter

2023-03-31 Thread Raffaello Giulietti
IIUC, Case 1 could be covered already today with split("\\n", -1). That returns N+1 substrings when the delimiter occurs N times. The proposed overload in String would be String[] split(String regex, int limit, boolean withDelimiters) with the existing split(regex, limit) simply invoking spl

Re: Small survey about JDK-8280101: in String.split grouped regex should keep the delimiter

2023-03-31 Thread Jim Laskey
D’oh - I did not know that. Good idiom to have in your pocket. > On Mar 31, 2023, at 10:20 AM, Raffaello Giulietti > wrote: > > IIUC, Case 1 could be covered already today with split("\\n", -1). That > returns N+1 substrings when the delimiter occurs N times. > > The proposed overload in Stri

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Adam Sotona
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee wrote: >> Rewrite BindingSpecializer to use the new class file API. >> >> Note: There is a big try/catch/finally block generated in the `specialize` >> method that currently uses labels. I looked at replacing this with a call to >> `CodeBuilder::tr

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
> CorruptedZipFiles could benefit from some spring cleaning and a conversion to > testNG: > > - The actual tests are moved into their own `@Test` methods, given more > meaningful names and a Javadoc comment explaining the constraint being > verified > - The setup code is moved to a `@Before` me

Re: Small survey about JDK-8280101: in String.split grouped regex should keep the delimiter

2023-03-31 Thread Roger Riggs
Hi Raffaello, It sounds useful to return the delimiters in a new API. It might be interesting to guarantee the array returns n strings and n-1 delimiters; filling with an empty string at the beginning and end if the input starts with or ends with a delimiter. Similar to the construction of Temp

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos wrote: >> CorruptedZipFiles could benefit from some spring cleaning and a conversion >> to testNG: >> >> - The actual tests are moved into their own `@Test` methods, given more >> meaningful names and a Javadoc comment explaining the constraint

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos wrote: >> CorruptedZipFiles could benefit from some spring cleaning and a conversion >> to junit: >> >> - The actual tests are moved into their own `@Test` methods, given more >> meaningful names and a Javadoc comment explaining the constraint b

Re: Small survey about JDK-8280101: in String.split grouped regex should keep the delimiter

2023-03-31 Thread Raffaello Giulietti
Hi Roger, I agree that Pattern.splitStream() would be hard use without contextual information, so let's drop it from the (still to be written) CSR. As for the guarantee that the array contains an alternation of n substrings and n-1 delimiters, this is what the overload String[] split(St

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc

2023-03-31 Thread ExE Boss
On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang wrote: > Also remove redundant casts to avoid javac warnings. src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 197: > 195: * @apiNote {@linkplain MethodTypeDesc} can represent method type > descriptors > 196: * that

Re: RFR: 8303530: Add system property for custom JAXP configuration file [v6]

2023-03-31 Thread Joe Wang
> Add a system property, jdk.xml.config.file, to return the path to a custom > JAXP configuration file. The current configuration file, jaxp.properties, > that the JDK supports will become the default configuration file. > > CSR: https://bugs.openjdk.org/browse/JDK-8303531 > > Tests: XML SQE an

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc

2023-03-31 Thread Chen Liang
On Fri, 31 Mar 2023 15:14:42 GMT, ExE Boss wrote: >> Also remove redundant casts to avoid javac warnings. > > src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 197: > >> 195: * @apiNote {@linkplain MethodTypeDesc} can represent method type >> descriptors >> 196:

Re: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v3]

2023-03-31 Thread Raffaello Giulietti
On Wed, 29 Mar 2023 04:21:10 GMT, Joe Darcy wrote: >> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to >> write some more implementation-specific tests around decision points in the >> FDLIBM algorithm, but I wanted to get the bulk of the changes out for review >> f

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v5]

2023-03-31 Thread Paul Sandoz
On Fri, 31 Mar 2023 12:17:49 GMT, Quan Anh Mai wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template >> line 1106: >> >>> 1104: @Override >>> 1105: @ForceInline >>> 1106: public int laneSource(int i) { >> >> Can this method be

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Sean Mullan
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base

Re: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR [v7]

2023-03-31 Thread Justin Lu
> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` > rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and > `DAY_OF_WEEK` combo. > > For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, > 31 December 2018_, which is incorrect. This is

Re: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR [v6]

2023-03-31 Thread Justin Lu
On Thu, 30 Mar 2023 23:20:52 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - dayInMinWeek should range check input and throw exception >> - Tweak static cal builder > > src/java.base/share/classes/j

Re: RFR: 8305113: (tz) Update Timezone Data to 2023c

2023-03-31 Thread Naoto Sato
On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato wrote: > Pleases review this PR. > The PR includes the following changes. > - tzdata 2023c > - Hack code to deal with Cairo's DST end, which is same as done in > 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work > around

Re: RFR: 8304450: [vectorapi] Refactor VectorShuffle implementation [v2]

2023-03-31 Thread Paul Sandoz
On Tue, 21 Mar 2023 16:29:44 GMT, Paul Sandoz wrote: >> I have moved most of the methods to `AbstractVector` and `AbstractShuffle`, >> I have to resort to raw types, though, since there seems to be no way to do >> the same with wild cards, and the generics mechanism is not powerful enough >> f

Integrated: 8303930: Fix ConstantUtils.skipOverFieldSignature void case return value

2023-03-31 Thread Chen Liang
On Thu, 9 Mar 2023 23:04:57 GMT, Chen Liang wrote: > This typo doesn't allow creation of malformed ClassDesc or MethodTypeDesc, > but it produces an erroneous exception on certain inputs. Running > `java.lang.constant.MethodTypeDesc.ofDescriptor("(I[[[V)I")` in Jshell > 19.0.2 throws Strin

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Iris Clark
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v3]

2023-03-31 Thread Jorn Vernee
> Rewrite BindingSpecializer to use the new class file API. > > Note: There is a big try/catch/finally block generated in the `specialize` > method that currently uses labels. I looked at replacing this with a call to > `CodeBuilder::trying` but it would require threading the nested code builder

Re: RFR: 8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes [v2]

2023-03-31 Thread Jorn Vernee
On Thu, 30 Mar 2023 19:55:15 GMT, Jorn Vernee wrote: >> Rewrite BindingSpecializer to use the new class file API. >> >> Note: There is a big try/catch/finally block generated in the `specialize` >> method that currently uses labels. I looked at replacing this with a call to >> `CodeBuilder::tr

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Mandy Chung
On Thu, 30 Mar 2023 20:45:08 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base

Re: RFR: 8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR [v7]

2023-03-31 Thread Naoto Sato
On Fri, 31 Mar 2023 16:39:17 GMT, Justin Lu wrote: >> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` >> rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and >> `DAY_OF_WEEK` combo. >> >> For example, Rolling _Monday, 30 December 2019_ by 1 week produced

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Lance Andersen
On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos wrote: >> CorruptedZipFiles could benefit from some spring cleaning and a conversion >> to junit: >> >> - The actual tests are moved into their own `@Test` methods, given more >> meaningful names and a Javadoc comment explaining the constraint b

Integrated: 8304928: Optimize ClassDesc.resolveConstantDesc

2023-03-31 Thread Chen Liang
On Thu, 30 Mar 2023 20:06:02 GMT, Chen Liang wrote: > This patch optimizes ClassDesc.resolveConstantDesc for array classes. > Otherwise, the performance of reference class resolution remain unchanged. > > A benchmark comparing resolution for reference arrays, primitive arrays, and > class or i

Integrated: 8297605: improve DelayQueue removal method javadoc

2023-03-31 Thread Martin Buchholz
On Thu, 2 Mar 2023 20:00:56 GMT, Martin Buchholz wrote: > Inviting @DougLea and @viktorklang-ora to review. > > As usual, I couldn't resist more fiddling. > - Added missing tests for take, remove(), remove(Object). > - Improved DelayQueueTest's testing infrastructure > - added more test assert

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Jonathan Gibbons
On Fri, 31 Mar 2023 10:45:39 GMT, Lance Andersen wrote: > > Hi Jon, > > This looks fine. I was wondering if we should do the same for java.util.zip > > and the PKWare Zip Spec or where java.sql references the JDBC Spec? > > Well, I must need coffee this morning as obviously JDBC is in the java.

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Jonathan Gibbons
On Fri, 31 Mar 2023 17:14:01 GMT, Iris Clark wrote: >> Jonathan Gibbons has updated the pull request incrementally with one >> additional commit since the last revision: >> >> address review feedback > > src/java.base/share/classes/java/io/ObjectOutputStream.java line 165: > >> 163: * @see

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc

2023-03-31 Thread Mandy Chung
On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang wrote: > Also remove redundant casts to avoid javac warnings. Looks fine. This is a good change. It'd be good to update the `java.lang.constant` tests - Marked as reviewed by mchung (Reviewer). PR Review: https://git.openjdk.org/jdk/p

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc

2023-03-31 Thread Mandy Chung
On Fri, 31 Mar 2023 15:22:05 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java line 197: >> >>> 195: * @apiNote {@linkplain MethodTypeDesc} can represent method type >>> descriptors >>> 196: * that are not representable by {@linkplain MethodT

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Martin Buchholz
On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos wrote: >> CorruptedZipFiles could benefit from some spring cleaning and a conversion >> to junit: >> >> - The actual tests are moved into their own `@Test` methods, given more >> meaningful names and a Javadoc comment explaining the constraint b

Re: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v3]

2023-03-31 Thread Brian Burkhalter
On Wed, 29 Mar 2023 04:21:10 GMT, Joe Darcy wrote: >> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to >> write some more implementation-specific tests around decision points in the >> FDLIBM algorithm, but I wanted to get the bulk of the changes out for review >> f

Re: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v4]

2023-03-31 Thread Joe Darcy
> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to > write some more implementation-specific tests around decision points in the > FDLIBM algorithm, but I wanted to get the bulk of the changes out for review > first. > > Note that since IEEEremainder was the last nat

Re: RFR: JDK-8304028: Port fdlibm IEEEremainder to Java [v4]

2023-03-31 Thread Brian Burkhalter
On Fri, 31 Mar 2023 19:23:10 GMT, Joe Darcy wrote: >> Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to >> write some more implementation-specific tests around decision points in the >> FDLIBM algorithm, but I wanted to get the bulk of the changes out for review >> f

Integrated: JDK-8304028: Port fdlibm IEEEremainder to Java

2023-03-31 Thread Joe Darcy
On Tue, 21 Mar 2023 06:11:57 GMT, Joe Darcy wrote: > Last but not least, a port of fdlibm IEEEremainder from C to Java. I plan to > write some more implementation-specific tests around decision points in the > FDLIBM algorithm, but I wanted to get the bulk of the changes out for review > first

Re: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes

2023-03-31 Thread Chris Plummer
On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use > the standard alignas operator for alignment requirements I don't have any comments on this change in general (it's not something I've dealt with in the past),

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
On Fri, 31 Mar 2023 17:27:25 GMT, Lance Andersen wrote: >> Eirik Bjorsnos has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Document the structure of the 'good' ZIP >> - Use the "Validate that.." comment style >> - Document the ByteBu

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v6]

2023-03-31 Thread Eirik Bjorsnos
> CorruptedZipFiles could benefit from some spring cleaning and a conversion to > junit: > > - The actual tests are moved into their own `@Test` methods, given more > meaningful names and a Javadoc comment explaining the constraint being > verified > - The setup code is moved to a `@Before` met

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
On Fri, 31 Mar 2023 18:37:58 GMT, Martin Buchholz wrote: > I support rewriting tests like this into junit 5. Glad to hear! I would be a bit sad to hear you were against this. > I wrote many jdk tests (like this) before a standard high quality test > framework like junit 5 was available. And

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc

2023-03-31 Thread Chen Liang
On Sat, 11 Mar 2023 04:59:07 GMT, Chen Liang wrote: > Also remove redundant casts to avoid javac warnings. Done. Updated the tests and copyright year of changed files. Would you mind review the associated CSR as well? - PR Comment: https://git.openjdk.org/jdk/pull/12986#issuecomme

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc [v2]

2023-03-31 Thread Chen Liang
> Also remove redundant casts to avoid javac warnings. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last

Re: RFR: 8284493: Improve computeNextExponential tail performance and accuracy [v18]

2023-03-31 Thread Chris Hennick
> This PR improves both the worst-case performance of `nextExponential` and > `nextGaussian` and the distribution of output at the tails. It fixes the > following imperfections: > > * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a > rounding error to accumulate at the ta

Re: RFR: 8284871: Use covariant overrides for the resolveConstantDesc(Lookup) method in sub‑interfaces of java.lang.constant.ConstantDesc [v2]

2023-03-31 Thread Mandy Chung
On Fri, 31 Mar 2023 20:32:13 GMT, Chen Liang wrote: >> Also remove redundant casts to avoid javac warnings. > > Chen Liang has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. Th

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5]

2023-03-31 Thread Justin Lu
On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in t

RFR: 8305400: ISO 4217 Amendment 175 Update

2023-03-31 Thread Justin Lu
Please review the ISO 4217 amendment 175 update. There are no meaningful code changes, but the version number should be updated accordingly to be in sync. - Commit messages: - Update to 175 Changes: https://git.openjdk.org/jdk/pull/13275/files Webrev: https://webrevs.openjdk.org/

Re: RFR: 8305400: ISO 4217 Amendment 175 Update

2023-03-31 Thread Steven R . Loomis
On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu wrote: > Please review the ISO 4217 amendment 175 update. > > There are no meaningful code changes, but the version number should be > updated accordingly to be in sync. Do you track the legal tender date? Because that did change, for CLDR https://g

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]

2023-03-31 Thread Jonathan Gibbons
> Please review a change to add `@spec` tags (and remove some equivalent `@see` > tags) to the main "core-libs" packages in `java.base` module. > > This is similar to, and a subset of, PR #11073. That PR was withdrawn, and > based on the ensuing discussion and suggestion, is now being handled

Re: RFR: 8305113: (tz) Update Timezone Data to 2023c

2023-03-31 Thread Sergey Bylokhov
On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato wrote: > Pleases review this PR. > The PR includes the following changes. > - tzdata 2023c > - Hack code to deal with Cairo's DST end, which is same as done in > 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)). To work > around

Re: RFR: 8305400: ISO 4217 Amendment 175 Update

2023-03-31 Thread Naoto Sato
On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu wrote: > Please review the ISO 4217 amendment 175 update. > > There are no meaningful code changes, but the version number should be > updated accordingly to be in sync. Marked as reviewed by naoto (Reviewer). > Do you track the legal tender date? B

Re: RFR: 8305400: ISO 4217 Amendment 175 Update

2023-03-31 Thread Steven R . Loomis
On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu wrote: > Please review the ISO 4217 amendment 175 update. > > There are no meaningful code changes, but the version number should be > updated accordingly to be in sync. Marked as reviewed by srl...@github.com (no known OpenJDK username). --

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v2]

2023-03-31 Thread Jonathan Gibbons
On Fri, 31 Mar 2023 16:28:14 GMT, Sean Mullan wrote: > I didn't see any changes to security APIs - are they coming in a follow-on > issue? Yes, this is _Add `@spec` tags in java.base/java.* (part 1)_ The rest of `java.base` will be in part 2. - PR Comment: https://git.openjdk.org/

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
On Fri, 31 Mar 2023 17:38:02 GMT, Lance Andersen wrote: >> Eirik Bjorsnos has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Document the structure of the 'good' ZIP >> - Use the "Validate that.." comment style >> - Document the ByteBu

Re: RFR: 8304014: Convert test/jdk/java/util/zip/ZipFile/CorruptedZipFiles.java to junit [v5]

2023-03-31 Thread Eirik Bjorsnos
On Fri, 31 Mar 2023 18:24:26 GMT, Martin Buchholz wrote: >> Eirik Bjorsnos has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Document the structure of the 'good' ZIP >> - Use the "Validate that.." comment style >> - Document the ByteB

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5]

2023-03-31 Thread Naoto Sato
On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in t

Re: RFR: JDK-8305206: Add @spec tags in java.base/java.* (part 1) [v3]

2023-03-31 Thread Iris Clark
On Fri, 31 Mar 2023 22:07:26 GMT, Jonathan Gibbons wrote: >> Please review a change to add `@spec` tags (and remove some equivalent >> `@see` tags) to the main "core-libs" packages in `java.base` module. >> >> This is similar to, and a subset of, PR #11073. That PR was withdrawn, and >> base