> Get JDK 24 underway.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains ten commits:
- Adjust test for deprecated options.
- Merge branch 'master' into JDK-8330188
- Update deprecated options test.
- Merge branch 'mas
On Tue, 7 May 2024 11:53:19 GMT, Pavel Rappo wrote:
> Please review this mechanical change to man pages. This PR should be
> integrated after https://github.com/openjdk/jdk/pull/18787.
Marked as reviewed by darcy (Reviewer).
> This PR is standalone as opposed to dependent because the #18787
On Tue, 7 May 2024 17:37:57 GMT, Pavel Rappo wrote:
> Yes, we do. There's a common misconception that `{@inheritDoc}` inherits the
> complete doc comment. In reality, `{@inheritDoc}` inherits only the main
> description, which does not include any `@throws` tags.
>
> A `@throws` tag is either
On Tue, 7 May 2024 01:26:30 GMT, Chen Liang wrote:
> Should this be final?
With only the private constructor, it doesn't matter too much in practice, but
an explicit `final` would be good documentation if that is the intent.
-
PR Review Comment:
> Get JDK 24 underway.
Joe Darcy 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 seven additional commits since the
last revision:
- Upd
On Mon, 29 Apr 2024 18:55:24 GMT, Vicente Romero wrote:
>> Reflection is not retrieving generic type information for mandated
>> parameters. This is a known issue which has been explicitly stated in the
>> API of some reflection methods. Fix for
>>
On Mon, 29 Apr 2024 18:55:24 GMT, Vicente Romero wrote:
>> Reflection is not retrieving generic type information for mandated
>> parameters. This is a known issue which has been explicitly stated in the
>> API of some reflection methods. Fix for
>>
On Tue, 23 Apr 2024 07:03:45 GMT, David Holmes wrote:
> There are further updates to this test in the pipeline (new deprecated flags
> in 23) so you will need to keep updating to reflect that.
Thanks @dholmes-ora ; acknowledged.
-
PR Review Comment:
On Wed, 24 Apr 2024 14:10:29 GMT, Nizar Benalla wrote:
> This checker checks the values of the `@since` tag found in the documentation
> comment for an element against the release in which the element first
> appeared.
>
> Real since value of an API element is computed as the oldest release
On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy wrote:
> Remove unnecessary setting of variable y, found by an IDE inspection noted in
> the bug report.
This pull request has now been integrated.
Changeset: 4e5c25ee
Author: Joe Darcy
URL:
https://git.openjdk.org/jdk/
On Tue, 19 Mar 2024 19:32:10 GMT, Joe Darcy wrote:
>> I think splitting `CharArraySequence` into two versions is somewhat dubious
>> as more observable types at call sites may mean the performance gain in
>> targeted micros is lost. How much of an improvement di
> Remove unnecessary setting of variable y, found by an IDE inspection noted in
> the bug report.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update copyright year.
-
Changes:
- all: https://git.openjdk.org/jd
Remove unnecessary setting of variable y, found by an IDE inspection noted in
the bug report.
-
Commit messages:
- JDK-8331108: Unused Math.abs call in java.lang.FdLibm.Expm1#compute
Changes: https://git.openjdk.org/jdk/pull/18963/files
Webrev:
On Thu, 25 Apr 2024 21:32:03 GMT, Joe Darcy wrote:
> Remove unnecessary setting of variable y, found by an IDE inspection noted in
> the bug report.
All Math and StrictMath regression tests pass with this change. Examining the
code, y does look to be overwritten on all the code paths
On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons wrote:
>> Please review a set of updates to clean up use of `/**` comments in the
>> vicinity of declarations.
>>
>> There are various categories of update:
>>
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before
On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons wrote:
> Please review a set of updates to clean up use of `/**` comments in the
> vicinity of declarations.
>
> There are various categories of update:
>
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or
On Wed, 17 Apr 2024 20:46:26 GMT, Joe Darcy wrote:
> 8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
This pull request has now been integrated.
Changeset: 235ba9a7
Author: Joe Darcy
URL:
https://git.openjdk.org/jdk/commit/235ba9a7025964b1e43149c7102e26b82b2081ad
St
8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
-
Commit messages:
- JDK-8330458: Add missing @since tag to ClassFile.JAVA_23_VERSION
Changes: https://git.openjdk.org/jdk/pull/18828/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18828=00
Issue:
> Get JDK 24 underway.
Joe Darcy has updated the pull request incrementally with two additional
commits since the last revision:
- Correct release date as observed in review feedback.
- Improve javadoc of class file update.
-
Changes:
- all: https://git.openjdk.org/jdk/p
On Tue, 16 Apr 2024 21:21:43 GMT, Chen Liang wrote:
>> Get JDK 24 underway.
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1481:
>
>> 1479: int JAVA_23_VERSION = 67;
>> 1480:
>> 1481: /** 68 */
>
> We need `@since 24` here.
Ah, good catch; looks like I was
On Mon, 15 Apr 2024 19:57:49 GMT, Iris Clark wrote:
> The copyright year was not updated in all files *14.java. I assume that's
> intentional.
I'll run my copyright update script before pushing.
> I've also Reviewed the associated CSRs.
Thanks.
> make/conf/version-numbers.conf line 36:
>
On Mon, 15 Apr 2024 19:01:08 GMT, Joe Darcy wrote:
> Get JDK 24 underway.
This initial version of the PR intentionally excludes the creation of the new
symbol files so that the fundamental code aspects of the update are easier to
see.
-
PR Comment: https://git.openjdk.org/
Get JDK 24 underway.
-
Commit messages:
- JDK-8330182: Start of release updates for JDK 24
Changes: https://git.openjdk.org/jdk/pull/18787/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18787=00
Issue: https://bugs.openjdk.org/browse/JDK-8330182
Stats: 101 lines in 37
On Fri, 12 Apr 2024 23:55:01 GMT, Joe Darcy wrote:
> Straightforward test update so it doesn't have to be trivially updated for
> each JDK version.
This pull request has now been integrated.
Changeset: da75e015
Author: Joe Darcy
URL:
https://git.openjdk.org/jdk/
On Sat, 13 Apr 2024 00:40:45 GMT, Chen Liang wrote:
> Thanks for this fix. I recall that I had to add this flag because otherwise
> compileSources fails when `@enablePreview` is there. If we can drop the
> preview flag, that would be the best.
Thanks; I did a quick experiment and the test
Straightforward test update so it doesn't have to be trivially updated for each
JDK version.
-
Commit messages:
- JDK-8330196: Make java/lang/invoke/defineHiddenClass/BasicTest release
agnostic
Changes: https://git.openjdk.org/jdk/pull/18769/files
Webrev:
On Fri, 5 Apr 2024 18:32:09 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>> The
On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy wrote:
> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/18590
On Wed, 3 Apr 2024 05:56:55 GMT, Joe Darcy wrote:
> Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.
The changes in this PR are being incorporated into the larger PR for derived
record creation.
-
PR Comment: https://git.openjdk.org/jdk/pull/18
On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy wrote:
> When new language features are added, the javax.lang.model may need to be
> updated. For certain classes of features, the API update includes introducing
> a new set of concrete visitors to handle the language feature.
>
ent of any particular language
> change.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Add informative links.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18609/files
- new: https://git.openjdk.org/jdk/pull/18609/
On Thu, 4 Apr 2024 05:48:25 GMT, Alan Bateman wrote:
> The visitor classes are themselves preview APIs. Is this the first time that
> preview APIs have been proposed without a JEP? Just wondering how much
> visibility this preview API will get.
To clarify the intention, the visitor classes
On Wed, 3 Apr 2024 21:05:20 GMT, Vicente Romero wrote:
>> When new language features are added, the javax.lang.model may need to be
>> updated. For certain classes of features, the API update includes
>> introducing a new set of concrete visitors to handle the language feature.
>>
>> The API
On Wed, 3 Apr 2024 20:17:39 GMT, Joe Darcy wrote:
> When new language features are added, the javax.lang.model may need to be
> updated. For certain classes of features, the API update includes introducing
> a new set of concrete visitors to handle the language feature.
>
When new language features are added, the javax.lang.model may need to be
updated. For certain classes of features, the API update includes introducing a
new set of concrete visitors to handle the language feature.
The API scaffolding to support the new feature tends to be considerably larger
On Tue, 2 Apr 2024 23:43:24 GMT, Joe Darcy wrote:
> Happened to notice a semantic typo in the description of
> MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended,
> and added some additional information to make the related descriptions mo
On Wed, 3 Apr 2024 14:55:07 GMT, Raffaello Giulietti
wrote:
>> Happened to notice a semantic typo in the description of
>> MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended,
>> and added some additional information to make the related descriptions more
>>
Exploratory work in support of https://github.com/openjdk/jdk/pull/18509.
-
Commit messages:
- Add more support for component local variables.
- Add uses of new visitor types.
- JDK-8329556: javax.lang.model suppor for Derived Record Creation (Preview)
- Baseline on 04 version of
On Tue, 2 Apr 2024 18:09:52 GMT, Joe Darcy wrote:
> > For the `javax.lang.model` changes, as a new ElementKind is being
> > introduced, there should be a matching layer of new concrete visitors and
> > selected updates to existing visitor implementations, etc.
>
Happened to notice a semantic typo in the description of
MathContext.DECIMAL128, use of "decimal64" where "decimal128" was intended, and
added some additional information to make the related descriptions more
informative.
-
Commit messages:
- JDK-8329557: Fix statement around
On Tue, 2 Apr 2024 18:05:43 GMT, Joe Darcy wrote:
> For the `javax.lang.model` changes, as a new ElementKind is being introduced,
> there should be a matching layer of new concrete visitors and selected
> updates to existing visitor implementations, etc.
I can help develop the visito
On Thu, 28 Mar 2024 14:08:44 GMT, Jan Lahoda wrote:
>> This is a patch for javac, that adds the Derived Record Creation
>> expressions. The current draft specification for the feature is:
>> https://cr.openjdk.org/~gbierman/jep468/jep468-20240326/specs/derived-record-creation-jls.html
>>
>>
On Tue, 12 Mar 2024 14:03:01 GMT, Claes Redestad wrote:
>> Shaojin Wen has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> restore comment
>
> I think splitting `CharArraySequence` into two versions is somewhat dubious
> as more observable
On Wed, 13 Mar 2024 13:51:27 GMT, Claes Redestad wrote:
> Relying on the upper bounds check of `charAt` doesn't work well with the
> `CharArraySequence` whose `charAt` deliberately does not throw an IIOBE if
> the array is longer than the provided length, ie, it'll look at chars beyond
> the
On Wed, 6 Mar 2024 17:54:57 GMT, Joe Darcy wrote:
> The atan2 and hypot cases added would fail for a particular test library that
> has errors in the millions of ulps for those inputs, rather than the small
> number of ulps specified for the error.
This pull request has now been i
On Tue, 12 Mar 2024 00:16:52 GMT, Mandy Chung wrote:
> I agree with the evaluation of
> [JDK-8327786](https://bugs.openjdk.org/browse/JDK-8327786) that
> `setAccessible(true)` isn't for most developers and this proposal is not
> worth doing.
I concur.
-
PR Comment:
On Mon, 11 Mar 2024 20:41:25 GMT, Shaojin Wen wrote:
>> The current BigDecimal(String) constructor calls String#toCharArray, which
>> has a memory allocation.
>>
>>
>> public BigDecimal(String val) {
>> this(val.toCharArray(), 0, val.length()); // allocate char[]
>> }
>>
>>
>> When the
> The atan2 and hypot cases added would fail for a particular test library that
> has errors in the millions of ulps for those inputs, rather than the small
> number of ulps specified for the error.
Joe Darcy has updated the pull request incrementally with one additional commit
since
> The atan2 and hypot cases added would fail for a particular test library that
> has errors in the millions of ulps for those inputs, rather than the small
> number of ulps specified for the error.
Joe Darcy has updated the pull request incrementally with one additional commit
since
The atan2 and hypot cases added would fail for a particular test library that
has errors in the millions of ulps for those inputs, rather than the small
number of ulps specified for the error.
-
Commit messages:
- JDK-8327487: Further augment WorstCaseTests with more cases
On Tue, 5 Mar 2024 00:51:33 GMT, Naoto Sato wrote:
> Fixing test cases. For bad test cases, only the first case was run, and the
> rest were ignored.
Looks fine; thanks for sending out the fix.
test/jdk/java/lang/Double/ParseDouble.java line 559:
> 557: private static void
On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote:
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZi
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the un
On Wed, 28 Feb 2024 06:08:18 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://me
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Respond to r
On Tue, 27 Feb 2024 11:20:11 GMT, Raffaello Giulietti
wrote:
> There are no libraries that have worse errors than OpenLibm, so I'm wondering
> what these values are good for?
When I was working on updating the worst-case tests for Math, I would check the
input values in Math.foo() and
On Tue, 27 Feb 2024 11:20:01 GMT, Raffaello Giulietti
wrote:
> I can't find this one on the paper.
Good catch; must have been a cut and paste error on my part.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15879#discussion_r1504993038
On Tue, 27 Feb 2024 19:21:13 GMT, Chad Rakoczy wrote:
> What is the issue with this? Is there a different way to set a timeout? The
> test tests that format does not take a long time to run so I would like to
> have a timeout
Hard-coded timeout in a test are generally considered harmful as
On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy wrote:
> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug
> with Formatter.format taking a long time when there is a lot of padding. This
> test runs Formatter.format with very large padding. Test fails before
>
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Appease jcheck.
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update atan2 and hypot
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Expand
On Mon, 26 Feb 2024 06:43:43 GMT, Joe Darcy wrote:
> To improve the "fingerprinting" coverage of the StrictMath tests, I've added
> test cases where the worst-case of a non-FDLIBM library is larger than the
> FDLIBM worst-case. Assuming reasonable methodology of th
On Sat, 24 Feb 2024 20:31:13 GMT, Joe Darcy wrote:
>> A new paper
>>
>> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
>> Quadruple Precision"
>> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
>> https://me
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request incrementally with five additional
commits since the last revision:
- Fix missing minus sign.
On Fri, 23 Feb 2024 19:18:22 GMT, Joe Darcy wrote:
> > Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result
> > here. I don't know why the paper says otherwise. Perhaps OpenLibm is not
> > exactly fdlibm.
>
> I've looked a bit over the OpenLibm
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Imp
On Fri, 22 Sep 2023 15:33:11 GMT, Raffaello Giulietti
wrote:
>> Joe Darcy 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 conta
On Fri, 22 Sep 2023 21:32:26 GMT, Joe Darcy wrote:
> For FDLIBM tan, the stated error in the Math.tan spec is 1 ulp and the FDLIBM
> sources say tan is "nearly rounded," which could reasonably be interpreted as
> meaning within 1 ulp. However, the reported error by the
nputs with generate the worst-case observed errors in different
> math library implementations. The FDLIBM-related worst cases should be added
> to the test suite.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the un
On Fri, 22 Sep 2023 05:36:02 GMT, Joe Darcy wrote:
> A new paper
>
> "Accuracy of Mathematical Functions in Single, Double, Double Extended, and
> Quadruple Precision"
> by Brian Gladman, Vincenzo Innocente and Paul Zimmermann
> https://members.loria.fr/PZi
On Fri, 22 Sep 2023 15:48:26 GMT, Raffaello Giulietti
wrote:
> Both `Math.cos` and `StrictMath.cos` produce the correctly rounded result
> here. I don't know why the paper says otherwise. Perhaps OpenLibm is not
> exactly fdlibm.
I've looked a bit over the OpenLibm changelog. They've added a
On Thu, 22 Feb 2024 22:00:26 GMT, Joe Darcy wrote:
> Widen acceptable error bound of Math.tan to accommodate the worst-case
> observed error which is slightly outside of the allowable range.
This pull request has now been integrated.
Changeset: 63f6a563
Author: Joe Darcy
URL:
Widen acceptable error bound of Math.tan to accommodate the worst-case observed
error which is slightly outside of the allowable range.
-
Commit messages:
- JDK-8326530: Widen allowable error bound of Math.tan
Changes: https://git.openjdk.org/jdk/pull/17973/files
Webrev:
On Thu, 22 Feb 2024 03:01:58 GMT, Chris Hennick wrote:
> Update: confirmed that the new test fails without the fix.
Thanks for verifying the test checks the fix; I'll let others who have worked
more directly on the random code review the actual fix.
-
PR Comment:
On Mon, 5 Feb 2024 04:25:16 GMT, Chris Hennick wrote:
> This provides a slightly more accurate bounding limit for
> `computeNextExponentialSoftCapped` when the computed bound is greater than
> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the
> `while
On Wed, 7 Feb 2024 19:06:21 GMT, Weijun Wang wrote:
> Security changes look fine. Although I don't know how to remove those
> annotations later. A lot of compatibility impact.
In case you didn't see it, the warning message are listed in an attachment on
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the b
On Wed, 7 Feb 2024 19:28:11 GMT, Joe Darcy wrote:
>> After the "this-escape" lint warning was added to javac (JDK-8015831), the
>> base module was not updated to be able to compile with this warning enabled.
>> This PR makes the necessary changes to al
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warning enabled.
Joe Darcy has up
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the base module to build with
> the warning enabled.
Joe Darcy has up
On Thu, 1 Feb 2024 01:32:42 GMT, Joe Darcy wrote:
> A double quote character doesn't need to be escaped when it is a char literal
> and single quote character doesn't need to be escaped when it is in a string.
> This change updates the toString() output of annotations t
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the b
On Tue, 6 Feb 2024 14:35:52 GMT, Daniel Fuchs wrote:
>> After the "this-escape" lint warning was added to javac (JDK-8015831), the
>> base module was not updated to be able to compile with this warning enabled.
>> This PR makes the necessary changes to allow the base module to build with
>>
On Sun, 4 Feb 2024 22:43:28 GMT, David Holmes wrote:
> This update drops the "ea" from the version string.
>
> We also propagate the following fixes from the markdown sources to the troff
> manpage file:
>
> JDK-8322478: Update java manpage for multi-file source-code launcher
> JDK-8302233:
On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote:
> In its initial form, the changes are tested on Linux. Later on, I'll do
> cross-platform builds to make sure there aren't any, say, windows-specific
> changes that are needed as well.
>
> I can file a follow-up umbrella bug wi
On Fri, 2 Feb 2024 23:38:41 GMT, Joe Darcy wrote:
> In its initial form, the changes are tested on Linux. Later on, I'll do
> cross-platform builds to make sure there aren't any, say, windows-specific
> changes that are needed as well.
>
PS Builds pass on all platforms
On Fri, 2 Feb 2024 23:36:41 GMT, Joe Darcy wrote:
> After the "this-escape" lint warning was added to javac (JDK-8015831), the
> base module was not updated to be able to compile with this warning enabled.
> This PR makes the necessary changes to allow the b
After the "this-escape" lint warning was added to javac (JDK-8015831), the base
module was not updated to be able to compile with this warning enabled. This PR
makes the necessary changes to allow the base module to build with the warning
enabled.
-
Commit messages:
-
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The incremental webrev excludes the unrelated changes b
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
This pull request has now been integrated.
Changeset: adc36040
Author: Joe Darcy
URL:
On Thu, 1 Feb 2024 22:01:49 GMT, Jorn Vernee wrote:
> This looks good to me. It will be easier to find where we are doing
> restricted operations like this.
Right; follows the recommended approach of minimizing the scope of the
SuppressWarnings annotations too. Thanks.
-
PR
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Add comment highlighting restricted method
The restricted javac warning is disabled for java.base, but could be enabled by
suppressing the warning in a handful of files.
-
Commit messages:
- JDK-8325148: Enable restricted javac warning in java.base
Changes: https://git.openjdk.org/jdk/pull/17677/files
Webrev:
On Thu, 1 Feb 2024 11:57:04 GMT, Magnus Ihse Bursie wrote:
> This is a follow-up on
> [JDK-8324053](https://bugs.openjdk.org/browse/JDK-8324053). I have run the
> bin/blessed-modifier-order.sh on the entire code base, and manually checked
> the result. I have reverted all but these trivial
A double quote character doesn't need to be escaped when it is a char literal
and single quote character doesn't need to be escaped when it is in a string.
This change updates the toString() output of annotations to account for the
different escaping requirements of strings and characters.
On Tue, 30 Jan 2024 17:21:07 GMT, Aleksey Shipilev wrote:
> Can we maybe see if we can fix these tests without exclusive-accessing them?
> I find it surprising that `java/lang/StringBuilder` tests are problematic,
> but `java/lang/StringBuffer` tests are not. Which tests fail?
I agree it
On Mon, 29 Jan 2024 23:53:08 GMT, Aggelos Biboudis
wrote:
>> This is the proposed patch for Primitive types in patterns, instanceof, and
>> switch (Preview).
>>
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/latest/
>
> Aggelos Biboudis has updated the pull request
On Fri, 26 Jan 2024 21:52:37 GMT, Joe Darcy wrote:
>> A trivial fix for validate-source.
>
> Marked as reviewed by darcy (Reviewer).
> @jddarcy - Thanks for the lightning fast review!
>
> /integrate auto
Sorry for missing that before pushing.
---
On Fri, 26 Jan 2024 21:51:04 GMT, Daniel D. Daugherty
wrote:
> A trivial fix for validate-source.
Marked as reviewed by darcy (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/17599#pullrequestreview-1846604299
1 - 100 of 727 matches
Mail list logo
