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
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
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
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
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/
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).
--
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
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
> 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
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
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/
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
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
> 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
> 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
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
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
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
> 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
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),
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
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
> 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
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
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
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
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
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.
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
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
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
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
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
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
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
> 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
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
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
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
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
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
> 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
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
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
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
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:
> 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
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
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
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
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
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
> 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
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
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
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
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
[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
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
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
> 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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
74 matches
Mail list logo
