Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.org/jdk/pull/7445/files - new: https://git.openjdk.org/jdk/pull/7445/files/75ac9c18..adcbcb71 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=23-24 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]
On Wed, 1 Jun 2022 05:09:42 GMT, ExE Boss wrote: >> Or `AbstractMethodError`, which is what `Executable::getParameterCount()` >> does: >> https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258 > > Actually, it should probably be `UnsupportedOperationException` instead. Hmm. If we had sealed classes and interfaces back in JDK 1.1 when Member was added, it most likely would have been added as sealed interface. But, we didn't have sealed interfaces back then so Member can (potentially) be extended by anyone. IIRC, there are a few classes implementing Member outside of the JDK. So, when adding a new method would JDK 20, the method should certainly have be default method. I think throwing UnsupportedOperationException in the default is marginally better than the alternatives. I'll update the PR accordingly in a subsequent push. Thanks. - PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]
On Tue, 14 Jun 2022 01:40:53 GMT, liach wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make mask fields final in ModuleDescriptor.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
>
>> 298: /**
>> 299: * {@return a set of access flags for the given mask value
>> 300: * appropriate for the location in question}
>
> Should we specify that the returned set is unmodifiable/immutable?
Sure; that would be consistent with other parts of the PR.
-
PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4]
On Tue, 31 May 2022 17:23:18 GMT, Rémi Forax wrote: >> For completeness, I think including SUPER is reasonable, even though has >> been a no-op for some time. (Some time in the future, there could be a class >> file version aware additions to this enum class.) Well spotted omission. > > `ACC_SUPER`may be reconed as `ACC_IDENTITY`by Valhalla, so i'm not sure it's > a good idea to add ACC_SUPER. As discussed elsewhere in the PR, given the historical existence of ACC_SUPER, I think it is reasonable to leave it all. Also, even if removed later in the release, it would be helpful to validate how overlapping flags can be handled in practice in Valhalla. - PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Make mask fields final in ModuleDescriptor. - Changes: - all: https://git.openjdk.org/jdk/pull/7445/files - new: https://git.openjdk.org/jdk/pull/7445/files/fd682ac8..75ac9c18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=22-23 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]
On Tue, 31 May 2022 17:20:08 GMT, Rémi Forax 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 contains 32 additional commits
>> since the last revision:
>>
>> - Target JDK 20 rather than 19.
>> - Merge branch 'master' into JDK-8266670
>> - Add mask values to constants' javadoc.
>> - Implement review feedback from mlchung.
>> - Fix type in @throws tag.
>> - Merge branch 'master' into JDK-8266670
>> - Respond to review feedback.
>> - Merge branch 'master' into JDK-8266670
>> - Make workding changes suggested in review feedback.
>> - Merge branch 'master' into JDK-8266670
>> - ... and 22 more: https://git.openjdk.org/jdk/compare/3d668090...05cf2d8b
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 130:
>
>> 128: MANDATED(AccessFlag.MANDATED.mask());
>> 129:
>> 130: private int mask;
>
> it should be declared final ?
Sure; will change.
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 134:
>
>> 132: this.mask = mask;
>> 133: }
>> 134: private int mask() {return mask;}
>
> seem useless, `mask` can be accessed directly
Hmm. Stylistically, I prefer methods.
-
PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v23]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Correct STATIC vs STATIC_PHASE issue found in code review. - Changes: - all: https://git.openjdk.org/jdk/pull/7445/files - new: https://git.openjdk.org/jdk/pull/7445/files/840edf2a..fd682ac8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=21-22 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]
On Wed, 13 Apr 2022 21:21:25 GMT, liach wrote: >> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167: >> >>> 165: * but is optional in the dynamic phase, during execution. >>> 166: */ >>> 167: STATIC(AccessFlag.STATIC.mask()), >> >> This is actually `AccessFlag.STATIC_PHASE` (`0x0040`), and not >> `AccessFlag.STATIC` (`0x0008`): >> Suggestion: >> >> STATIC(AccessFlag.STATIC_PHASE.mask()), > >> In the current hodgepodge AccessFlag, we have STATIC and STATIC_PHASE, and >> the incorrect ModuleDescriptor.accessFlags().contains(AccessFlag.STATIC) >> call is much more subtle, especially to new users of this class. Arguably, >> this misuse would be way worse than that in the distinct enum case. > > Oops, didn't know this already happened. Good spot right there. Corrected to STATIC_PHASE in subsequent push; thanks. - PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v22]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: From review feedback, use package-private contstants in Modifier. - Changes: - all: https://git.openjdk.org/jdk/pull/7445/files - new: https://git.openjdk.org/jdk/pull/7445/files/111c6014..840edf2a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=21 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=20-21 Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4]
On Tue, 15 Feb 2022 09:06:02 GMT, ExE Boss wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to more review feedback. > > src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 163: > >> 161: * @see Class#isEnum() >> 162: */ >> 163: ENUM(0x4000, false, Set.of(TYPE, FIELD)), > > These can use the **package‑private** constant fields from > `java.lang.reflect.Modifier`: > <https://github.com/openjdk/jdk/blob/ab623f8ae05c57b165d4d918d896dbdc5b4177e9/src/java.base/share/classes/java/lang/reflect/Modifier.java#L338-L347> Good suggestion; will be reflected in the next push. - PR: https://git.openjdk.org/jdk/pull/7445
Integrated: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html
On Sat, 11 Jun 2022 00:35:52 GMT, Joe Darcy wrote: > 8288173: JDK-8202449 fix causes conformance test failure : > api/java_util/Random/RandomGenerator/NextFloat.html This pull request has now been integrated. Changeset: f4b05a11 Author: Joe Darcy URL: https://git.openjdk.org/jdk19/commit/f4b05a1168e17000ef31173860af77aa722d2280 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html Backport-of: da2339cf6971532593e4f1b5ebbce8d1ed2e83b2 - PR: https://git.openjdk.org/jdk19/pull/5
Integrated: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html
8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html - Commit messages: - Backport da2339cf6971532593e4f1b5ebbce8d1ed2e83b2 Changes: https://git.openjdk.org/jdk19/pull/5/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk19=5=00 Issue: https://bugs.openjdk.org/browse/JDK-8288173 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/5.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/5/head:pull/5 PR: https://git.openjdk.org/jdk19/pull/5
Re: RFR: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html
On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti wrote: > This fixes a bug introduced with JDK-8202449. Changes look okay, but please do a follow-up fix to add some regression tests for this condition. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/9120
Integrated: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof
On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy wrote: > There are many instanceof checks in the sun.reflection.annotation code; these > would be improved by using pattern matching for instanceof. This pull request has now been integrated. Changeset: aaa89714 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/aaa897148ab2669e06531521221f0551335b3d1f Stats: 57 lines in 4 files changed: 1 ins; 14 del; 42 mod 8288227: Refactor annotation implementation to use pattern matching for instanceof Reviewed-by: alanb - PR: https://git.openjdk.org/jdk/pull/9129
RFR: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof
There are many instanceof checks in the sun.reflection.annotation code; these would be improved by using pattern matching for instanceof. - Commit messages: - JDK-8288227: Refactor annotation implementation to use pattern matching for instanceo Changes: https://git.openjdk.org/jdk/pull/9129/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9129=00 Issue: https://bugs.openjdk.org/browse/JDK-8288227 Stats: 57 lines in 4 files changed: 1 ins; 14 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/9129.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9129/head:pull/9129 PR: https://git.openjdk.org/jdk/pull/9129
Integrated: JDK-8284858: Start of release updates for JDK 20
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... This pull request has now been integrated. Changeset: edff51e5 Author: Joe Darcy Committer: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/edff51e5fdb5282830ecfb3792a88c7b28ca6557 Stats: 6453 lines in 69 files changed: 6403 ins; 5 del; 45 mod 8284858: Start of release updates for JDK 20 8286035: Add source 20 and target 20 to javac 8286034: Add SourceVersion.RELEASE_20 Reviewed-by: dholmes, kcr, iris, erikj, jjg, ihse - PR: https://git.openjdk.org/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]
> Time to start getting ready for JDK 20... 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 44 additional commits since the last revision: - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbols for JDK 19 b25. - Merge branch 'master' into JDK-8284858 - Adjust deprecated options test. - Merge branch 'master' into JDK-8284858 - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/530d16c1...1b29a17c - Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/e495a579..1b29a17c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8236=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=04-05 Stats: 16423 lines in 539 files changed: 12382 ins; 2143 del; 1898 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str) [v2]
On Fri, 27 May 2022 22:59:47 GMT, Raffaello Giulietti wrote: >> BigDecimal(String) currently fails to accept some strings produced by >> BigDecimal.toString(). This PR removes this limitation. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8233760: Result of BigDecimal.toString throws overflow exception on new > BigDecimal(str) Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8905
Re: RFR: 8202449: overflow handling in Random.doubles [v3]
On Tue, 24 May 2022 12:58:45 GMT, Raffaello Giulietti wrote: >> Extend the range of Random.doubles(double, double) and similar methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8202449: overflow handling in Random.doubles Marked as reviewed by darcy (Reviewer). src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 733: > 731: /* avoids overflow at the cost of 3 more multiplications > */ > 732: float halfOrigin = 0.5f * origin; > 733: r = (r * (0.5f * bound - halfOrigin) + halfOrigin) * > 2.0f; This could be done in double arithmetic, but I think it is better to keep it in float arithmetic for similarity with the code in the double version of the method. - PR: https://git.openjdk.java.net/jdk/pull/8791
Integrated: 8273346: Expand library mappings to IEEE 754 operations
On Wed, 25 May 2022 00:19:41 GMT, Joe Darcy wrote: > Generally add apiNote's to map from Java library methods to particular IEEE > 754 operations. For now, I only added such notes to java.lang.Math and not > java.lang.StrictMath. This pull request has now been integrated. Changeset: 5d4ea9b9 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/5d4ea9b9549b762b7c207e5c2ee65bc51591433b Stats: 156 lines in 4 files changed: 143 ins; 0 del; 13 mod 8273346: Expand library mappings to IEEE 754 operations Reviewed-by: bpb - PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v5]
> Generally add apiNote's to map from Java library methods to particular IEEE > 754 operations. For now, I only added such notes to java.lang.Math and not > java.lang.StrictMath. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Correct typo found in review and reflow paragraph. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8876/files - new: https://git.openjdk.java.net/jdk/pull/8876/files/ba3e9a75..b82f2668 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8876=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8876=03-04 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/8876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876 PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
On Thu, 2 Jun 2022 08:22:11 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/lang/Math.java line 823:
>>
>>> 821: * @apiNote
>>> 822: * This method corresponds to the convertTowardPositive operation
>>> 823: * defined in IEEE 754.
>>
>> Probably what is meant is IEEE `convertToIntegerTowardPositive` (not
>> `convertTowardPositive`).
>> However, that's another kind of rounding, which always rounds any
>> non-integral value toward positive infinity, not just ties. This is not what
>> happens with this method.
>
>> not just ties
> Plz. disregard this 3 words
Okay, checking the IEEE 754-2019 spec again, there are operations to round a
floating-point value to an integral-valued floating-point value
(roundToIntegral{$ROUNDING_DIRECTION_ATTRIBUTE} and separately operations to
round from a floating-point value to a value in an integer format
(convertToInteger{$ROUNDING_DIRECTION_ATTRIBUTE} ). However, as noted, there is
no IEEE 754 operations for rounding up only for ties. I'll remove the API notes
for the round methods; thanks for catching this.
-
PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v4]
> Generally add apiNote's to map from Java library methods to particular IEEE > 754 operations. For now, I only added such notes to java.lang.Math and not > java.lang.StrictMath. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8876/files - new: https://git.openjdk.java.net/jdk/pull/8876/files/be81f60b..ba3e9a75 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8876=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8876=02-03 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876 PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v3]
> Generally add apiNote's to map from Java library methods to particular IEEE > 754 operations. For now, I only added such notes to java.lang.Math and not > java.lang.StrictMath. 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 six additional commits since the last revision: - Merge branch 'master' into JDK-8273346 - Merge branch 'master' into JDK-8273346 - Respond to review feedback; make another pass to link methods to IEEE 754 operations. - Merge branch 'master' into JDK-8273346 - Add floor and ceil. - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath - Changes: - all: https://git.openjdk.java.net/jdk/pull/8876/files - new: https://git.openjdk.java.net/jdk/pull/8876/files/9169ad9e..be81f60b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8876=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8876=01-02 Stats: 17707 lines in 455 files changed: 14288 ins; 2165 del; 1254 mod Patch: https://git.openjdk.java.net/jdk/pull/8876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876 PR: https://git.openjdk.java.net/jdk/pull/8876
Integrated: JDK-8287838: Update Float and Double to use snippets
On Sun, 5 Jun 2022 21:19:37 GMT, Joe Darcy wrote: > Various code blocks in Float and Double would be better as snippets. This pull request has now been integrated. Changeset: 0e06bf3b Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/0e06bf3b04f69c57120d32106a3ae5f69030934d Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod 8287838: Update Float and Double to use snippets Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/9034
Re: RFR: JDK-8287838: Update Float and Double to use snippets [v2]
On Mon, 6 Jun 2022 05:29:24 GMT, Alan Bateman wrote: > One other thing you could do is link Pattern.matches in the snippet to the > matches method. Suggestion made in subsequent push; thanks. > src/java.base/share/classes/java/lang/Double.java line 683: > >> 681: * "[\\x00-\\x20]*");// Optional trailing "whitespace" >> 682: * >> 683: * if (Pattern.matches(fpRegex, myString)) // @link >> substring="Pattern.matches" target ="java.util.regex.Pattern#matches" > > If you want to avoid the annoyingly long line then you can put the "// @link > ..." on the previous line if you want. It can be done with a snippet region like this: * // @link region substring="Pattern.matches" target ="java.util.regex.Pattern#matches" * if (Pattern.matches(fpRegex, myString)) * Double.valueOf(myString); // Will not throw NumberFormatException * // @end - PR: https://git.openjdk.java.net/jdk/pull/9034
Re: RFR: JDK-8287838: Update Float and Double to use snippets [v2]
> Various code blocks in Float and Double would be better as snippets. Joe Darcy has updated the pull request incrementally with two additional commits since the last revision: - Use idiom for shorter lines - Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/9034/files - new: https://git.openjdk.java.net/jdk/pull/9034/files/255fbb15..56abd0ac Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=9034=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9034=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/9034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9034/head:pull/9034 PR: https://git.openjdk.java.net/jdk/pull/9034
RFR: JDK-8287838: Update Float and Double to use snippets
Various code blocks in Float and Double would be better as snippets. - Commit messages: - JDK-8287838: Update Float and Double to use snippets Changes: https://git.openjdk.java.net/jdk/pull/9034/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9034=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287838 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/9034.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/9034/head:pull/9034 PR: https://git.openjdk.java.net/jdk/pull/9034
Re: RFR: 8284199: Implementation of Structured Concurrency (Incubator) [v5]
On Thu, 2 Jun 2022 11:25:36 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>>
>> This is a non-final API that provides a gentle on-ramp to structure a task
>> as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> Alan Bateman 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 12 additional
> commits since the last revision:
>
> - Add test directory to jdk_other so tests run in tier2
> - Merge
> - Fix typo in javadoc
> - Merge
> - Javadoc updates, add to jdk_loom test group
> - Add statement to close about thread termination
> - Use {@code ...}, replace task->subtask, fix typos, add jls ref
> - Merge
> - @ignore StructuredThreadDumpTest until test infra in place
> - Refresh
> - ... and 2 more:
> https://git.openjdk.java.net/jdk/compare/3c34c506...7f48656e
Marked as reviewed by darcy (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/8787
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]
> Time to start getting ready for JDK 20... 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 40 additional commits since the last revision: - Update symbols for JDK 19 b25. - Merge branch 'master' into JDK-8284858 - Adjust deprecated options test. - Merge branch 'master' into JDK-8284858 - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7a25d65...e495a579 - Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/54e872b5..e495a579 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8236=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=03-04 Stats: 7203 lines in 242 files changed: 5859 ins; 868 del; 476 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v15]
On Wed, 1 Jun 2022 10:37:23 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 >> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was >> a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about >> multi-line (block) comments. Nothing in the code proper has changed, except >> for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 4511638: Double.toString(double) sometimes produces incorrect results Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v4]
> Time to start getting ready for JDK 20... 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 38 additional commits since the last revision: - Adjust deprecated options test. - Merge branch 'master' into JDK-8284858 - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 28 more: https://git.openjdk.java.net/jdk/compare/2ffc9a25...54e872b5 - Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/eedd36bd..54e872b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8236=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=02-03 Stats: 1101 lines in 21 files changed: 708 ins; 170 del; 223 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
On Wed, 25 May 2022 08:56:27 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 contains four additional commits
>> since the last revision:
>>
>> - Respond to review feedback; make another pass to link methods to IEEE 754
>> operations.
>> - Merge branch 'master' into JDK-8273346
>> - Add floor and ceil.
>> - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math
>> and StrictMath
>
> src/java.base/share/classes/java/lang/Math.java line 771:
>
>> 769: * This method corresponds to the convertToIntegerTiesToEven
>> 770: * operation defined in IEEE 754.
>> 771: *
>
> IEEE `convertToIntegerTiesToEven` rounds ties to the even integer.
> The method's spec, however, requires ties to round toward positive infinity.
> Unfortunately, IEEE 754 doesn't offer a `convertToIntegerTiesToPositive`
Good catch; found a different 754 operation that seems to fit.
> src/java.base/share/classes/java/math/RoundingMode.java line 49:
>
>> 47: * exponent range of {@code BigDecimal}, the mathematical result will
>> 48: * be exactly representable in the result precision or fall between
>> 49: * two representable values. In the case of falling between two
>
> Perhaps better would be
> `two adjacent representable values.`
Agreed; adjusted in subsequent push.
-
PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
On Wed, 1 Jun 2022 02:05:40 GMT, Joe Darcy wrote: >> Generally add apiNote's to map from Java library methods to particular IEEE >> 754 operations. For now, I only added such notes to java.lang.Math and not >> java.lang.StrictMath. > > 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 four additional commits since > the last revision: > > - Respond to review feedback; make another pass to link methods to IEEE 754 > operations. > - Merge branch 'master' into JDK-8273346 > - Add floor and ceil. > - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math > and StrictMath I look another pass over the methods in Float, Double, and Math for opportunities to link to IEEE 754 operations. At least for now, I choose not to link to abs since IEEE 754 abs can have different behavior for NaN values that java.lang.Math.abs. If a link is made, this difference would need to be noted. - PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8273346: Expand library mappings to IEEE 754 operations [v2]
> Generally add apiNote's to map from Java library methods to particular IEEE > 754 operations. For now, I only added such notes to java.lang.Math and not > java.lang.StrictMath. 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 four additional commits since the last revision: - Respond to review feedback; make another pass to link methods to IEEE 754 operations. - Merge branch 'master' into JDK-8273346 - Add floor and ceil. - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath - Changes: - all: https://git.openjdk.java.net/jdk/pull/8876/files - new: https://git.openjdk.java.net/jdk/pull/8876/files/050e6ecd..9169ad9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8876=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8876=00-01 Stats: 46471 lines in 566 files changed: 22606 ins; 17922 del; 5943 mod Patch: https://git.openjdk.java.net/jdk/pull/8876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876 PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v3]
> Time to start getting ready for JDK 20... 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 36 additional commits since the last revision: - Update deprecated options test. - Merge branch 'master' into JDK-8284858 - Respond to review feedback. - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbol information for JDK 19 b23. - ... and 26 more: https://git.openjdk.java.net/jdk/compare/57d97d36...eedd36bd - Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/96be1787..eedd36bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8236=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=01-02 Stats: 41686 lines in 344 files changed: 18832 ins; 17644 del; 5210 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]
On Fri, 27 May 2022 21:53:38 GMT, Roger Riggs wrote: > As for retaining SUPER, both SUPER and IDENTITY have location class and > according to the BasicAccessFlagTest, the bit patterns should be disjoint If the defined set of class locations, considered over time, have non-disjoint definitions, then the test would need to be modified accordingly of course. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: 8233760: Result of BigDecimal.toString throws overflow exception on new BigDecimal(str)
On Thu, 26 May 2022 18:02:14 GMT, Raffaello Giulietti
wrote:
> BigDecimal(String) currently fails to accept some strings produced by
> BigDecimal.toString(). This PR removes this limitation.
test/jdk/java/math/BigDecimal/StringConstructor.java line 69:
> 67: constructWithError("0.01e"+Integer.MIN_VALUE);
> 68: constructWithError("1e"+((long)Integer.MIN_VALUE-1));
> 69:
Please add some test cases to demonstrate that the round-tripping that previous
did not work is functional after the fix.
-
PR: https://git.openjdk.java.net/jdk/pull/8905
Re: RFR: 8287440: Typo in package-info.java of java.util.random
On Wed, 18 May 2022 11:45:46 GMT, Anthony Vanelverdinghe wrote: > The change is trivial, but I'll need help from someone to create a JBS issue > & sponsor this PR. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8766
Re: RFR: 8284199: Implementation of Structured Concurrency (Incubator) [v3]
On Tue, 24 May 2022 15:15:43 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>>
>> This is a non-final API that provides a gentle on-ramp to structure a task
>> as a family of concurrent subtasks, and to coordinate the subtasks as a unit.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add statement to close about thread termination
src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java
line 668:
> 666: sb.append('/');
> 667: }
> 668: String id = getClass().getName() + "@" +
> System.identityHashCode(this);
Can use Objects.toIdentityString() instead.
-
PR: https://git.openjdk.java.net/jdk/pull/8787
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]
On Wed, 25 May 2022 19:22:51 GMT, Roger Riggs wrote: > AccessFlags.SUPER can/should be removed; it is unused and will be redefined > in the [Value Objects JEP](https://openjdk.java.net/jeps/8277163). It will be > a cleaner transition if there is no opportunity to create a dependency on the > obsolete flag. Hmm. I don't agree with that conclusion. I see the role of AccessFlags is to model what is in the class file. ACC_SUPER has been documented and in multiple versions of the JVMS and has appeared set in class files. If the bit position is reused, that is fine and the API can accommodate that overlap, unlike a bit-flag based model. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
On Thu, 26 May 2022 22:38:12 GMT, David Holmes wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java line > 312: > >> 310: int V18 = 0 << 16 | 62; >> 311: int V19 = 0 << 16 | 63; >> 312: int V20 = 0 << 17 | 64; > > 17 ?? > > Though why do we even bother with this when the minor version is zero? Simple > assignment works. Doh! Will fix in the next pushed. - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v2]
> Time to start getting ready for JDK 20... Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8236/files - new: https://git.openjdk.java.net/jdk/pull/8236/files/49c871d9..96be1787 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8236=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8236=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20
On Thu, 26 May 2022 22:40:59 GMT, Kevin Rushforth wrote: > You also need to change the JBS version from 19 to 20 in > [`.jcheck/conf`](https://github.com/openjdk/jdk/blob/6a33974a6b8a629744c6d76c3b4fa1f772e52ac8/.jcheck/conf#L4): Acknowledged; will fix in the next push. Thanks. - PR: https://git.openjdk.java.net/jdk/pull/8236
RFR: JDK-8284858: Start of release updates for JDK 20
Time to start getting ready for JDK 20... - Commit messages: - Update symbol information for JDK 19 b24. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Update symbol information for JDK 19 b23. - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - Merge branch 'master' into JDK-8284858 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/295be6f1...49c871d9 Changes: https://git.openjdk.java.net/jdk/pull/8236/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8236=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284858 Stats: 6210 lines in 67 files changed: 6166 ins; 0 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/8236.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8236/head:pull/8236 PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: JDK-8284858: Start of release updates for JDK 20
On Thu, 14 Apr 2022 05:09:14 GMT, Joe Darcy wrote: > Time to start getting ready for JDK 20... The expected kinds of updates to start up JDK 20. - PR: https://git.openjdk.java.net/jdk/pull/8236
Re: RFR: 8287064: Modernize ProxyGenerator.PrimitiveTypeInfo [v2]
On Fri, 20 May 2022 22:18:42 GMT, liach wrote:
>> Simplify opcode handling, use `final` in `PrimitiveTypeInfo`, and replace
>> the hash map with a simple lookup, similar to what's done in
>> [JDK-8284880](https://bugs.openjdk.java.net/browse/JDK-8284880) (#8242)
>
> liach has updated the pull request incrementally with one additional commit
> since the last revision:
>
> Convert PrimitiveTypeInfo to an enum
> > Did you consider switch (class) {...} in PrimitiveTypeInfo.get?
>
> I don't think we can switch on class instances yet. Even with preview
> enabled, best I can get is (for type incompatibility of `Class` and
> `Class`, etc.)
>
> ```java
> return switch (cl) {
> case Class e && e == int.class -> 1;
> case Class e && e == long.class -> 2;
> case Class e && e == boolean.class -> 3;
> case Class e && e == short.class -> 4;
> case Class e && e == byte.class -> 5;
> case Class e && e == char.class -> 6;
> case Class e && e == float.class -> 7;
> case Class e && e == double.class -> 8;
> default -> 0;
> };
> ```
>
> to avoid type incompatibility; this is in turn implemented by a bootstrap
> method and a loop, which is of course obviously much slower.
Not necessarily recommending this coding idiom, but if you screened on
Class.isPrimitive() being true (taking care to avoid void.class), you could
switch on the string presentations on the class such as getName or
getSimpleName.
-
PR: https://git.openjdk.java.net/jdk/pull/8801
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v19]
On Tue, 3 May 2022 21:35:48 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >> distinct. There are concepts that overlap in the two domains (public, >> private, etc.), others that only have a language-level modifier (sealed), >> and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these >> subtleties. For example, the bit positions used by access flags on different >> kinds of elements overlap (such as "volatile" for fields and "bridge" for >> methods. Just having a raw integer does not provide sufficient context to >> decode the corresponding language-level string. Methods like >> Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like >> Valhalla, addressing the existent modeling deficiency now ahead of time is >> reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. >> It is missing implementations to map from, say, method modifiers to access >> flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in >> once the API is further along. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Add mask values to constants' javadoc. Will take up work on this issue again for JDK 20. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. 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 32 additional commits since the last revision: - Target JDK 20 rather than 19. - Merge branch 'master' into JDK-8266670 - Add mask values to constants' javadoc. - Implement review feedback from mlchung. - Fix type in @throws tag. - Merge branch 'master' into JDK-8266670 - Respond to review feedback. - Merge branch 'master' into JDK-8266670 - Make workding changes suggested in review feedback. - Merge branch 'master' into JDK-8266670 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/60434fb7...05cf2d8b - Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/ead5911f..05cf2d8b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=19 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=18-19 Stats: 255671 lines in 3128 files changed: 171304 ins; 68829 del; 15538 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445
RFR: 8273346: Expand library mappings to IEEE 754 operations
Generally add apiNote's to map from Java library methods to particular IEEE 754 operations. For now, I only added such notes to java.lang.Math and not java.lang.StrictMath. - Commit messages: - Add floor and ceil. - JDK-8273346: Examine use of "rounding mode" and "rounding policy" in Math and StrictMath Changes: https://git.openjdk.java.net/jdk/pull/8876/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8876=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273346 Stats: 108 lines in 4 files changed: 103 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8876/head:pull/8876 PR: https://git.openjdk.java.net/jdk/pull/8876
Re: RFR: 8287206: Use WrongThreadException for confinement errors
On Tue, 24 May 2022 09:26:44 GMT, Maurizio Cimadamore wrote: > This patch tweaks the foreign API to use the newly added > `WrongThreadException` instead of `IllegalStateException` to report > confinement errors. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8865
Re: RFR: 8284199: Implementation of Structured Concurrency (Incubator)
On Thu, 19 May 2022 13:05:54 GMT, Alan Bateman wrote:
> This is the implementation of JEP 428: Structured Concurrency (Incubator).
>
> This is a non-final API that provides a gentle on-ramp to structure a task as
> a family of concurrent subtasks, and to coordinate the subtasks as a unit.
src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java
line 237:
> 235: * the task result is retrieved via its {@code Future}, or
> happen-before any actions
> 236: * taken in a thread after {@linkplain #join() joining} of the task
> scope.
> 237: *
Would a @-jls reference to the appropriate section of the memory model chapter
help here?
-
PR: https://git.openjdk.java.net/jdk/pull/8787
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v3]
On Tue, 10 May 2022 13:47:35 GMT, Raffaello Giulietti wrote: >> Add a family of "safe" cast methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8279986: methods Math::asXExact for safely checked primitive casts As a reminder, once the spec is finalized, versions of the methods and spec need to be added to StrictMath too. - PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 8286654: Add an optional description accessor on ToolProvider interface
On Wed, 18 May 2022 14:56:47 GMT, Christian Stein wrote: > This PR adds an optional description accessor on `ToolProvider` interface. > > This PR also adds short description for each of the listed tool: > - `jar` > - `javac` > - `javadoc` > - `javap` and `jdeps` > - `jlink` and `jmod` > - `jpackage` Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8772
Integrated: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses
On Sun, 15 May 2022 18:36:07 GMT, Joe Darcy wrote: > Make the javadoc in the InputStream and OutputStream subclasses in core libs > DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in > client libs will be done another a separate bug.) When the time comes, will > do any necessary merging for the changes in[JDK-8286200. > > Please also review the CSR to cover the introduction of implspec and implNote > tags: https://bugs.openjdk.java.net/browse/JDK-8286784 This pull request has now been integrated. Changeset: 8e602b86 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/8e602b862db305e6f28b13f9fb0f7ff2cab89bae Stats: 201 lines in 13 files changed: 60 ins; 45 del; 96 mod 8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: 8286788: Test java/lang/Thread/virtual/ThreadAPI.testGetStackTrace3 fails
On Tue, 17 May 2022 11:15:19 GMT, Alan Bateman wrote: > This is a test fix. ThreadAPI.testGetStackTrace3 tests Thread::getStackTrace > on a thread doing a selection operation. The test is not reliable as it > expects to see the "select" method in the stack trace after waiting 200ms. > The test is changed to poll the stack trace so that it's no longer dependent > on sleep. > > The update includes a drive-by change to the test description to use > `@enablePreview`. Marked as reviewed by darcy (Reviewer). test/jdk/java/lang/Thread/virtual/ThreadAPI.java line 28: > 26: * @bug 8284161 8286788 > 27: * @summary Test Thread API with virtual threads > 28: * @enablePreview Good to see there is directed jtreg support for this. - PR: https://git.openjdk.java.net/jdk/pull/8743
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses [v4]
On Mon, 16 May 2022 17:53:17 GMT, Alan Bateman wrote: > thanks for the updates. Updated the CSR to match this version. - PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: 8213045: Add commonly used symbolic math constants to the JDK
On Mon, 16 May 2022 21:29:22 GMT, Brian Burkhalter wrote: > Add constant `java.math.BigDecimal.TWO`. Looks fine. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8735
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses [v4]
> Make the javadoc in the InputStream and OutputStream subclasses in core libs > DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in > client libs will be done another a separate bug.) When the time comes, will > do any necessary merging for the changes in[JDK-8286200. > > Please also review the CSR to cover the introduction of implspec and implNote > tags: https://bugs.openjdk.java.net/browse/JDK-8286784 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add @Override's requested in review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8717/files - new: https://git.openjdk.java.net/jdk/pull/8717/files/07e8a6a6..c31a408d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8717=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8717=02-03 Stats: 11 lines in 5 files changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717 PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses [v3]
On Sun, 15 May 2022 21:16:53 GMT, Pavel Rappo wrote:
> 1. One the one hand, it's not clear to me what criterion was used for adding
> `@Override` annotations. On the other hand, the more `@Override` annotations
> a codebase has, the better.
>
> 2. Have you compared the resulting documentation before and after the
> change? Aside from added `@implSpec` and `@implNote`, were there anything
> anything different?
>
> 3. I wonder if it makes sense to also reduce the size of the doc comments
> by changing explicit documentation inheritance for the `@param` and `@return`
> tags to implicit one, i.e. removing the tags on the overrider's side.
I added the `@Override` annotations to methods I reviewed and/or updated; it
was not necessarily an exhaustive process. I have not run specdiff to
double-check the expected changes; it would be more thorough to do so. The
intention is to only have minor wording changes apart from the `@implSpec` and
`@implNote` tags. Stylistically, I'd prefer the explicit `@foo {@inhertiDoc}`
idiom to indicate the code just want to use the javadoc from a supertype.
-
PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses [v3]
> Make the javadoc in the InputStream and OutputStream subclasses in core libs > DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in > client libs will be done another a separate bug.) When the time comes, will > do any necessary merging for the changes in[JDK-8286200. > > Please also review the CSR to cover the introduction of implspec and implNote > tags: https://bugs.openjdk.java.net/browse/JDK-8286784 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright, change whitespace. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8717/files - new: https://git.openjdk.java.net/jdk/pull/8717/files/c84ef79a..07e8a6a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8717=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8717=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717 PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses [v2]
> Make the javadoc in the InputStream and OutputStream subclasses in core libs > DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in > client libs will be done another a separate bug.) When the time comes, will > do any necessary merging for the changes in[JDK-8286200. > > Please also review the CSR to cover the introduction of implspec and implNote > tags: https://bugs.openjdk.java.net/browse/JDK-8286784 Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8286783 - JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses - Changes: https://git.openjdk.java.net/jdk/pull/8717/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8717=01 Stats: 189 lines in 13 files changed: 49 ins; 45 del; 95 mod Patch: https://git.openjdk.java.net/jdk/pull/8717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717 PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: 8286810: Use public [Double|Float].PRECISION fields in jdk.internal.math.[Double|Float]Consts [v2]
On Mon, 16 May 2022 15:54:25 GMT, Raffaello Giulietti wrote: >> Please review these simple changes in jdk.internal.math.[Double|Float]Consts > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > 8286810: Use public [Double|Float].PRECISION fields in > jdk.internal.math.[Double|Float]Consts Looks fine; at your option, add a comment somewhere to setting the bias fields to explicitly indicate what the value is. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8729
Integrated: JDK-8286760: Update citation of "Effective Java" second edition to third edition
On Fri, 13 May 2022 21:17:22 GMT, Joe Darcy wrote: > Update reference to the latest "Effective Java" version and switch to cite > tags. This pull request has now been integrated. Changeset: 4bc7b7df Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/4bc7b7df0421f74c95421c01ee573a2ec9d6805c Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 8286760: Update citation of "Effective Java" second edition to third edition Reviewed-by: bpb, prappo - PR: https://git.openjdk.java.net/jdk/pull/8707
RFR: JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses
Make the javadoc in the InputStream and OutputStream subclasses in core libs DRY-er by use of inheritDoc. (Any analagous changes to AudioInputStream in client libs will be done another a separate bug.) When the time comes, will do any necessary merging for the changes in[JDK-8286200. Please also review the CSR to cover the introduction of implspec and implNote tags: https://bugs.openjdk.java.net/browse/JDK-8286784 - Commit messages: - JDK-8286783: Expand use of @inheritDoc in InputStream and OutputStream subclasses Changes: https://git.openjdk.java.net/jdk/pull/8717/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8717=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286783 Stats: 190 lines in 13 files changed: 49 ins; 45 del; 96 mod Patch: https://git.openjdk.java.net/jdk/pull/8717.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8717/head:pull/8717 PR: https://git.openjdk.java.net/jdk/pull/8717
Re: RFR: JDK-8281001 Examine the behavior of Class::forName if the caller is null
On Sat, 14 May 2022 00:30:00 GMT, Tim Prinzing wrote: > The Class::forName behavior change to match JNI FindClass is a compatible > change and seems pretty attractive as it would be expected that > Class::forName would give the same behavior as FindClass which uses the > system classloader. The test for 8281006 was enhanced to test for this > change. Merged master to pick up fixes to unrelated test failures to reduce > noise. @tprinzing , please file a CSR for this discuss so the behavioral changes can be reviewed. - PR: https://git.openjdk.java.net/jdk/pull/8711
RFR: JDK-8286760: Update citation of "Effective Java" second edition to third edition
Update reference to the latest "Effective Java" version and switch to cite tags. - Commit messages: - JDK-8286760: Update citation of "Effective Java" second edition to third edition Changes: https://git.openjdk.java.net/jdk/pull/8707/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8707=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286760 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8707.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8707/head:pull/8707 PR: https://git.openjdk.java.net/jdk/pull/8707
Integrated: JDK-8286604: Update InputStream and OutputStream to use @implSpec
On Wed, 11 May 2022 20:40:30 GMT, Joe Darcy wrote: > While doing a CSR review of another issue, I noticed some cases in > InputStream and OutputStream what would benefit from being upgraded to > implSpec and related javadoc tags. > > The "A subclass must provide an implementation of this method." statements on > several abstract methods don't add much value, but I chose to leave them in > for this request. > > Please also review the corresponding CSR: > https://bugs.openjdk.java.net/browse/JDK-8286605 This pull request has now been integrated. Changeset: 1e843c3d Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/1e843c3d4fbc0b68eceec17be29186dcb5b37de1 Stats: 40 lines in 2 files changed: 18 ins; 9 del; 13 mod 8286604: Update InputStream and OutputStream to use @implSpec Reviewed-by: bpb, lancea, iris, alanb - PR: https://git.openjdk.java.net/jdk/pull/8663
Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec [v2]
On Thu, 12 May 2022 20:04:33 GMT, Joe Darcy wrote: >> While doing a CSR review of another issue, I noticed some cases in >> InputStream and OutputStream what would benefit from being upgraded to >> implSpec and related javadoc tags. >> >> The "A subclass must provide an implementation of this method." statements >> on several abstract methods don't add much value, but I chose to leave them >> in for this request. >> >> Please also review the corresponding CSR: >> https://bugs.openjdk.java.net/browse/JDK-8286605 > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Respond to review feedback. CSR also updated to reflect changes made in response to review comments; thanks. - PR: https://git.openjdk.java.net/jdk/pull/8663
Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec [v2]
On Wed, 11 May 2022 22:43:43 GMT, liach wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to review feedback.
>
> src/java.base/share/classes/java/io/OutputStream.java line 151:
>
>> 149: * The {@code write} method of {@code OutputStream} calls
>> 150: * the write method of one argument on each of the bytes to be
>> 151: * written out. Subclasses are encouraged to override this method
>> and
>
> Shouldn't the "subclasses" information be part of the API Note?
Sure; moved to an apiNote.
-
PR: https://git.openjdk.java.net/jdk/pull/8663
Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec [v2]
> While doing a CSR review of another issue, I noticed some cases in > InputStream and OutputStream what would benefit from being upgraded to > implSpec and related javadoc tags. > > The "A subclass must provide an implementation of this method." statements on > several abstract methods don't add much value, but I chose to leave them in > for this request. > > Please also review the corresponding CSR: > https://bugs.openjdk.java.net/browse/JDK-8286605 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8663/files - new: https://git.openjdk.java.net/jdk/pull/8663/files/a29e5c36..7d88f44c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8663=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8663=00-01 Stats: 13 lines in 2 files changed: 3 ins; 8 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8663/head:pull/8663 PR: https://git.openjdk.java.net/jdk/pull/8663
Re: RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec
On Thu, 12 May 2022 12:24:17 GMT, Alan Bateman wrote:
>> While doing a CSR review of another issue, I noticed some cases in
>> InputStream and OutputStream what would benefit from being upgraded to
>> implSpec and related javadoc tags.
>>
>> The "A subclass must provide an implementation of this method." statements
>> on several abstract methods don't add much value, but I chose to leave them
>> in for this request.
>>
>> Please also review the corresponding CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8286605
>
> src/java.base/share/classes/java/io/InputStream.java line 177:
>
>> 175: *
>> 176: * @apiNote
>> 177: * A subclass must provide an implementation of this method.
>
> Is this sentence useful to keep? The method is abstract so a concrete
> implementation has to implement it. On the other other hand, an abstract
> subclass does not need to implement it.
If such a sentence occurred in new code, I would recommend it be removed. I
left it in place in the spirit of just adding apiNote, implSpec, etc., but I'm
happy to delete these comments too. I assume it was deemed useful to readers of
JDK 1.0, but the assumed background of Java developers now is rather different
:-)
> src/java.base/share/classes/java/io/InputStream.java line 688:
>
>> 686: * @implSpec
>> 687: * The {@code mark} method of {@code InputStream} does
>> 688: * nothing.
>
> Minor nit but the line break can be removed so that "nothing" is on the same
> line.
Sure. (I default to not making such reflow changes in the initial version of a
patch to avoid spurious diffs.
-
PR: https://git.openjdk.java.net/jdk/pull/8663
Integrated: JDK-8286615: Small refactor to SerializedLambda
On Thu, 12 May 2022 00:10:28 GMT, Joe Darcy wrote: > Noticed by inspection during a CSR review, small refactoring to use a > message-cause exception constructor when one is available. > > Will update the copyright before a push. This pull request has now been integrated. Changeset: 160944bc Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/160944bc6bd94d2927f398cf7732027c1b836a42 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod 8286615: Small refactor to SerializedLambda Reviewed-by: bpb, iris - PR: https://git.openjdk.java.net/jdk/pull/8670
Re: RFR: JDK-8286615: Small refactor to SerializedLambda [v2]
> Noticed by inspection during a CSR review, small refactoring to use a > message-cause exception constructor when one is available. > > Will update the copyright before a push. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8670/files - new: https://git.openjdk.java.net/jdk/pull/8670/files/82d7ab2c..6b15c809 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8670=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8670=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8670/head:pull/8670 PR: https://git.openjdk.java.net/jdk/pull/8670
RFR: JDK-8286615: Small refactor to SerializedLambda
Noticed by inspection during a CSR review, small refactoring to use a message-cause exception constructor when one is available. Will update the copyright before a push. - Commit messages: - JDK-8286615: Small refactor to SerializedLambda Changes: https://git.openjdk.java.net/jdk/pull/8670/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8670=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286615 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8670.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8670/head:pull/8670 PR: https://git.openjdk.java.net/jdk/pull/8670
RFR: JDK-8286604: Update InputStream and OutputStream to use @implSpec
While doing a CSR review of another issue, I noticed some cases in InputStream and OutputStream what would benefit from being upgraded to implSpec and related javadoc tags. The "A subclass must provide an implementation of this method." statements on several abstract methods don't add much value, but I chose to leave them in for this request. Please also review the corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8286605 - Commit messages: - JDK-8286604: Update InputStream and OutputStream to use @implSpec Changes: https://git.openjdk.java.net/jdk/pull/8663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8663=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286604 Stats: 36 lines in 2 files changed: 18 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/8663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8663/head:pull/8663 PR: https://git.openjdk.java.net/jdk/pull/8663
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
On Tue, 10 May 2022 15:50:26 GMT, Raffaello Giulietti wrote: > `[Float|Double]ToDecimal` do not have access to `AbstractStringBuilder`, so > have to fail over `Appendable`, which can throw `IOException` in `append(*)` > methods. > > I have to find another way if this wrapping to make the compiler happy is > unacceptable. Ah, I haven't used it myself recently enough to recall the details, but I believe the shared secrets mechanism is intended to allow such cross-package access. If the current code is kept and if the exception can actually be thrown, explicitly throwing an assertion error is preferable to "assert false". - PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8279986: methods Math::asXExact for safely checked primitive casts [v2]
On Mon, 9 May 2022 09:26:58 GMT, Raffaello Giulietti
wrote:
>> Add a family of "safe" cast methods.
>
> Raffaello Giulietti 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 four additional
> commits since the last revision:
>
> - 8279986: methods Math::asXExact for safely checked primitive casts
>
>Merge branch 'master' into JDK-8279986
> - 8279986: methods Math::asXExact for safely checked primitive casts
>
>Merge branch 'master' into JDK-8279986
> - 8279986: methods Math::asXExact for safely checked primitive casts
> - 8279986: methods Math::asXExact for safely checked primitive casts
src/java.base/share/classes/java/lang/Math.java line 1367:
> 1365: * Returns the value of the {@code double} argument,
> 1366: * throwing an exception if the conversion is inexact.
> 1367: * The method returns iff the argument and the result
Style suggestion: given the audience of the javadoc, rather than "iff" write
out "if and only if" or other full word construct.
src/java.base/share/classes/java/lang/Math.java line 1578:
> 1576: */
> 1577: @ForceInline
> 1578: public static long toUnsignedIntExact(long value) {
Existing methods like Integer.parseUnsignedInt interpret the negative int
values as positive values larger than MAX_INT. So if an int is not going to be
returned here, I suggest a name like "toUnsignedIntRangeExact".
-
PR: https://git.openjdk.java.net/jdk/pull/8548
Re: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v11]
On Mon, 9 May 2022 12:38:48 GMT, Raffaello Giulietti
wrote:
>> Hello,
>>
>> here's a PR for a patch submitted on March 2020
>> [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was
>> a thing.
>>
>> The patch has been edited to adhere to OpenJDK code conventions about
>> multi-line (block) comments. Nothing in the code proper has changed, except
>> for the addition of redundant but clarifying parentheses in some expressions.
>>
>>
>> Greetings
>> Raffaello
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 4511638: Double.toString(double) sometimes produces incorrect results
Generally looks solid!
src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 882:
> 880: try {
> 881: FloatToDecimal.appendTo(f, this);
> 882: } catch (IOException ignored) {
What is the motivation for wrapping with IOException?
src/java.base/share/classes/java/lang/Double.java line 33:
> 31: import java.util.Optional;
> 32:
> 33: import jdk.internal.math.FloatingDecimal;
Presumably the FloatingDecimal import here and in Float can be removed.
src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java line 38:
> 36: * This class exposes a method to render a {@code double} as a string.
> 37: *
> 38: * @author Raffaello Giulietti
New code shouldn't use author tags.
-
PR: https://git.openjdk.java.net/jdk/pull/3402
Re: RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments
On Mon, 9 May 2022 15:56:35 GMT, Adam Sotona wrote: > Please review this patch adding new lint option, **lossy-conversions**, to > javac to warn about type casts in compound assignments with possible lossy > conversions. > > The new lint warning is shown if the type of the right-hand operand of a > compound assignment is not assignment compatible with the type of the > variable. > > The implementation of the warning is based on similar check performed to emit > "possible lossy conversion" compilation error for simple assignments. > > Proposed patch also include complex matrix-style test with positive and > negative test cases of lossy conversions in compound assignments. > > Proposed patch also disables this new lint option in all affected JDK modules > and libraries to allow smooth JDK build. Individual cases to address possibly > lossy conversions warnings in JDK are already addressed in a separate > umbrella issue and its sub-tasks. > > Thanks for your review, > Adam I see there is already a bug filed to address situations found by the new warning in the JDK's libraries (JDK-8286374). As a matter of policy, I recommend the (potential) warnings be addressed in at least the java.base and java.desktop modules before the new warning is enabled. In other words, a priority should be given to keeping java.base and java.desktop compiling successfully with all warnings enabled. - PR: https://git.openjdk.java.net/jdk/pull/8599
Re: RFR: 8286363: BigInteger.parallelMultiply missing @since 19
On Mon, 9 May 2022 15:26:20 GMT, Brian Burkhalter wrote: > Add missing `@since 19` tag. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8598
Re: RFR: JDK-8286347: incorrect use of `{@link}`
On Fri, 6 May 2022 23:30:44 GMT, Jonathan Gibbons wrote:
> Please review a small doc fix to update incorrect use of `{@link}` on arrays
> of primitive types.
Looks fine in and of itself, but not sure how it will interact with the
(presumed) integration of JEP 424: "Foreign Function & Memory API (Preview)"
which will at least move the file, if not otherwise modify it.
-
PR: https://git.openjdk.java.net/jdk/pull/8584
Integrated: JDK-8285497: Add system property for Java SE specification maintenance version
On Wed, 27 Apr 2022 22:27:34 GMT, Joe Darcy wrote: > Add a new system property, java.specification.maintenance.version, to return > the maintenance release number of the Java SE specification being > implemented. The property is unset, optional in the terminology of > System.getProperties, for an initial release of a specification. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 > > I'll update copyright years before an integration. This pull request has now been integrated. Changeset: 59ef76a3 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/59ef76a365eafe40d8d68b4d5e028f0e731abd01 Stats: 23 lines in 4 files changed: 22 ins; 0 del; 1 mod 8285497: Add system property for Java SE specification maintenance version Reviewed-by: mullan, jpai, iris - PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v8]
> Add a new system property, java.specification.maintenance.version, to return > the maintenance release number of the Java SE specification being > implemented. The property is unset, optional in the terminology of > System.getProperties, for an initial release of a specification. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 > > I'll update copyright years before an integration. 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 14 additional commits since the last revision: - Respond to review feedback and update copyrights. - Merge branch 'master' into JDK-8285497 - Respond to mbreinhold review feedback. - Merge branch 'master' into JDK-8285497 - Update wording to address review feedback. - Merge branch 'master' into JDK-8285497 - Change punctuation from review feedback. - Respond to review feedback; make sequence of values explicit. - Respond to review feedback. - Respond to review feedback. - ... and 4 more: https://git.openjdk.java.net/jdk/compare/796f256f...28ff456b - Changes: - all: https://git.openjdk.java.net/jdk/pull/8437/files - new: https://git.openjdk.java.net/jdk/pull/8437/files/7b7720cf..28ff456b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8437=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8437=06-07 Stats: 1430 lines in 53 files changed: 600 ins; 493 del; 337 mod Patch: https://git.openjdk.java.net/jdk/pull/8437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437 PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v12]
On Thu, 5 May 2022 09:35:42 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview). >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling _Unimplemented_) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. We >> can add additional labels, if required, as the PR progresses. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Extent Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 19 commits: > > - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f > - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 > - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 > - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 > - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a > - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 > - Refresh ee9fa8ed05ec22de7a13383052d68aa8aa7832ec > - Merge with jdk-19+20 > - Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e > - Refresh 8d8f0a2fd646e57fe6b4e8ab669f836dc46dda69 > - ... and 9 more: > https://git.openjdk.java.net/jdk/compare/1bb4de2e...86bea8ec Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8286154: Fix 3rd party notices in test files
On Thu, 5 May 2022 16:13:59 GMT, Naoto Sato wrote: > Trivial fix to 3rd party copyright notices. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8558
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v6]
On Mon, 2 May 2022 20:31:18 GMT, Joe Darcy wrote: >> Add a new system property, java.specification.maintenance.version, to return >> the maintenance release number of the Java SE specification being >> implemented. The property is unset, optional in the terminology of >> System.getProperties, for an initial release of a specification. >> >> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 >> >> I'll update copyright years before an integration. > > 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 10 additional commits since > the last revision: > > - Update wording to address review feedback. > - Merge branch 'master' into JDK-8285497 > - Change punctuation from review feedback. > - Respond to review feedback; make sequence of values explicit. > - Respond to review feedback. > - Respond to review feedback. > - Respond to CSR feedback. > - Merge branch 'master' into JDK-8285497 > - Update comment in template. > - JDK-8285497: Add system property for Java SE specification maintenance > version PR and CSR updated as suggested. - PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v7]
> Add a new system property, java.specification.maintenance.version, to return > the maintenance release number of the Java SE specification being > implemented. The property is unset, optional in the terminology of > System.getProperties, for an initial release of a specification. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 > > I'll update copyright years before an integration. 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 12 additional commits since the last revision: - Respond to mbreinhold review feedback. - Merge branch 'master' into JDK-8285497 - Update wording to address review feedback. - Merge branch 'master' into JDK-8285497 - Change punctuation from review feedback. - Respond to review feedback; make sequence of values explicit. - Respond to review feedback. - Respond to review feedback. - Respond to CSR feedback. - Merge branch 'master' into JDK-8285497 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f4e6f016...7b7720cf - Changes: - all: https://git.openjdk.java.net/jdk/pull/8437/files - new: https://git.openjdk.java.net/jdk/pull/8437/files/741ececa..7b7720cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8437=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8437=05-06 Stats: 7420 lines in 158 files changed: 4834 ins; 1036 del; 1550 mod Patch: https://git.openjdk.java.net/jdk/pull/8437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437 PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: 8279598: Provide adapter from RandomGenerator to Random [v21]
On Sun, 1 May 2022 17:48:39 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i >> decided to use the >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html >> interface to create the default method `asRandom()` that wraps around the >> newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method >> next(int bits) is not overrided and setSeed() method if left blank up to >> discussion on what to do with it. >> >> Small test done on >> https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional > commit since the last revision: > > Update specs of setSeed() and next(bits). Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7001
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]
On Fri, 29 Apr 2022 20:34:21 GMT, Mandy Chung wrote: > I took a closer look at the proposed APIs. I think it's in a good state to > target for 19. I skimmed on the existing JDK usage of `getModifiers` other > than a trivial test e.g. is public, final, etc and the proposed API works > well (btw no plan to convert them and just use those cases for validation). > > The value of `ACC_SUPER` and `ACC_STRICT` could possibly be reused for new > access flags. It may be useful to document when the flag becomes obsolete. > > Nit: the enum constants are listed in the order of the mask value, which I > like. Some enum constants reference the `Modifer` constants but I think it'd > help to see the mask value here consistently for all entries. One go-to place > in the source if I want to find the value of different flags. I've pushed a changeset to add the mask values to the constants' javadoc. Following a don't-repeat-yourself approach, I would have preferred to do this with a @-value tage using the java.lang.reflect.Modifier value (where available), but the @-value tags doesn't seem to offer any formatting so I added the values separately. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v19]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add mask values to constants' javadoc. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/8a3a3cd8..ead5911f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=17-18 Stats: 46 lines in 1 file changed: 23 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445
Integrated: JDK-8285977: Add links to IEEE 754 specification
On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy wrote: > Please review the addition of @-see links from classes that mention the IEEE > 754 floating-point standard to an IEEE page about the standard. The URL in > the initial version of the PR is the top search result on the IEEE home page > for "754 standard". > > Another candidate page to use is > > https://ieeexplore.ieee.org/servlet/opac?punumber=8766227 > > which is (apparently) a stable citation page for the standard. > > These links may be upgraded to the the forthcoming @-spec facility in the > future. ( JDK-6251738). This pull request has now been integrated. Changeset: 3cbf769f Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/3cbf769f55ed9f1837e6417db97bce9597701229 Stats: 22 lines in 7 files changed: 21 ins; 0 del; 1 mod 8285977: Add links to IEEE 754 specification Reviewed-by: jjg, iris, bpb - PR: https://git.openjdk.java.net/jdk/pull/8511
Re: RFR: JDK-8285977: Add links to IEEE 754 specification
On Tue, 3 May 2022 08:25:30 GMT, Raffaello Giulietti wrote: > What about the DOI URL? Probably even more stable. > https://doi.org/10.1109/IEEESTD.2019.8766229 Hmm. I'd rather use the IEEE URL for now; if that turns out to problematic, we can switch to the DOI one. - PR: https://git.openjdk.java.net/jdk/pull/8511
Re: RFR: JDK-8285977: Add links to IEEE 754 specification [v2]
> Please review the addition of @-see links from classes that mention the IEEE > 754 floating-point standard to an IEEE page about the standard. The URL in > the initial version of the PR is the top search result on the IEEE home page > for "754 standard". > > Another candidate page to use is > > https://ieeexplore.ieee.org/servlet/opac?punumber=8766227 > > which is (apparently) a stable citation page for the standard. > > These links may be upgraded to the the forthcoming @-spec facility in the > future. ( JDK-6251738). Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8511/files - new: https://git.openjdk.java.net/jdk/pull/8511/files/244fe910..1d9e1521 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8511=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8511=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8511.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8511/head:pull/8511 PR: https://git.openjdk.java.net/jdk/pull/8511
Re: RFR: JDK-8285977: Add links to IEEE 754 specification
Hello, While informative, I think some kind of official link to the IEEE 754 document is more appropriate in this context. -Joe On 5/3/2022 2:59 AM, Rony G. Flatscher wrote: On 03.05.2022 10:28, Raffaello Giulietti wrote: On Mon, 2 May 2022 22:55:43 GMT, Joe Darcy wrote: Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard". Another candidate page to use is https://ieeexplore.ieee.org/servlet/opac?punumber=8766227 which is (apparently) a stable citation page for the standard. These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738). What about the DOI URL? Probably even more stable. https://doi.org/10.1109/IEEESTD.2019.8766229 - PR: https://git.openjdk.java.net/jdk/pull/8511 Maybe informal links to the resources made available via the web by the IEEE 754 editor, Mike F. Cowlishaw, could be helpful: - <http://speleotrove.com/decimal/> - Previous standard: <https://www.iso.org/standard/57469.html> with <http://speleotrove.com/misc/IEEE754-errata.html> - Current standard: <https://www.iso.org/standard/80985.html> with <http://speleotrove.com/misc/IEEE754-errata-2019.html> ---rony
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v18]
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains (public, > private, etc.), others that only have a language-level modifier (sealed), and > still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these > subtleties. For example, the bit positions used by access flags on different > kinds of elements overlap (such as "volatile" for fields and "bridge" for > methods. Just having a raw integer does not provide sufficient context to > decode the corresponding language-level string. Methods like > Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like > Valhalla, addressing the existent modeling deficiency now ahead of time is > reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It > is missing implementations to map from, say, method modifiers to access > flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in > once the API is further along. 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 29 additional commits since the last revision: - Implement review feedback from mlchung. - Fix type in @throws tag. - Merge branch 'master' into JDK-8266670 - Respond to review feedback. - Merge branch 'master' into JDK-8266670 - Make workding changes suggested in review feedback. - Merge branch 'master' into JDK-8266670 - Typo fix; add implSpec to Executable. - Appease jcheck. - Fix some bugs found by inspection, docs cleanup. - ... and 19 more: https://git.openjdk.java.net/jdk/compare/97d4dde5...8a3a3cd8 - Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/14980605..8a3a3cd8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=16-17 Stats: 358875 lines in 5512 files changed: 257744 ins; 47741 del; 53390 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Mon, 2 May 2022 20:30:53 GMT, Joe Darcy wrote:
>> @irisclark does raise an interesting point: If, say, MR 2 doesn’t require a
>> change to the RI then the MR 1 RI is also the MR 2 RI, but its
>> `java.specification.maintenance.version` property will report that it’s the
>> MR 1 RI.
>>
>> One way to fix this would be to require an RI update with every MR just to
>> update this property, even if no other code in the RI changes — but we
>> prefer to avoid doing RI builds unnecessarily.
>>
>> Another way to fix it would be to finesse the specification of this
>> property, perhaps:
>>
>>
>> * {@systemProperty
>> java.specification.maintenance.version}
>> * Java Runtime Environment specification maintenance version,
>> which may
>> * be interpreted as a non-zero integer. If defined, the value
>> of this
>> * property is the identifying number of the most recent > * href="https://jcp.org/en/procedures/jcp2#3.6.4;>specification
>> * maintenance release that required a change to the
>> runtime
>> * (optional).
>> *
>
> In the latest push, to address the concerns raised updated the proposed
> wording to, in plain text:
>
> Java Runtime Environment specification maintenance version, not defined
> before the specification implemented by this runtime has undergone a
> maintenance release (optional). When defined, the value of this property may
> be interpreted as a positive integer. The value indicates the latest
> maintenance release the runtime is known to support. A later release may be
> supported by the environment. To indicate the first maintenance release this
> property will have the value "1"; to indicate the second maintenance release,
> this property will have the value "2", and so on.
PS CSR Updated to reflect this push; please review:
https://bugs.openjdk.java.net/browse/JDK-8285764
-
PR: https://git.openjdk.java.net/jdk/pull/8437
RFR: JDK-8285977: Add links to IEEE 754 specification
Please review the addition of @-see links from classes that mention the IEEE 754 floating-point standard to an IEEE page about the standard. The URL in the initial version of the PR is the top search result on the IEEE home page for "754 standard". Another candidate page to use is https://ieeexplore.ieee.org/servlet/opac?punumber=8766227 which is (apparently) a stable citation page for the standard. These links may be upgraded to the the forthcoming @-spec facility in the future. ( JDK-6251738). - Commit messages: - JDK-8285977: Add links to IEEE 754 specification Changes: https://git.openjdk.java.net/jdk/pull/8511/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8511=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285977 Stats: 21 lines in 7 files changed: 21 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8511.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8511/head:pull/8511 PR: https://git.openjdk.java.net/jdk/pull/8511
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v5]
On Fri, 29 Apr 2022 17:11:55 GMT, Mark Reinhold wrote:
>> src/java.base/share/classes/java/lang/System.java line 743:
>>
>>> 741: * have the value {@code "1"}; after a second maintenance
>>> 742: * release, this property will have the value {@code "2"},
>>> 743: * and so on.
>>
>> There should be no requirement that values be allocated sequentially. In
>> other words, if JCP MR does not require an RI, then it should not be
>> surprising if there is no JDK build with maintenance version . As an
>> example, JSR 337 MR 1 and MR 2 both used the same RI. If this system
>> property had existed during development of MR 1, it would return "1". Since
>> no RI was submitted for MR 2, a build returning "2" should never exist. MR
>> 3 did update the RI, so it would return "3".
>
> @irisclark does raise an interesting point: If, say, MR 2 doesn’t require a
> change to the RI then the MR 1 RI is also the MR 2 RI, but its
> `java.specification.maintenance.version` property will report that it’s the
> MR 1 RI.
>
> One way to fix this would be to require an RI update with every MR just to
> update this property, even if no other code in the RI changes — but we prefer
> to avoid doing RI builds unnecessarily.
>
> Another way to fix it would be to finesse the specification of this property,
> perhaps:
>
>
> * {@systemProperty
> java.specification.maintenance.version}
> * Java Runtime Environment specification maintenance version,
> which may
> * be interpreted as a non-zero integer. If defined, the value of
> this
> * property is the identifying number of the most recent * href="https://jcp.org/en/procedures/jcp2#3.6.4;>specification
> * maintenance release that required a change to the
> runtime
> * (optional).
> *
In the latest push, to address the concerns raised updated the proposed wording
to, in plain text:
Java Runtime Environment specification maintenance version, not defined before
the specification implemented by this runtime has undergone a maintenance
release (optional). When defined, the value of this property may be interpreted
as a positive integer. The value indicates the latest maintenance release the
runtime is known to support. A later release may be supported by the
environment. To indicate the first maintenance release this property will have
the value "1"; to indicate the second maintenance release, this property will
have the value "2", and so on.
-
PR: https://git.openjdk.java.net/jdk/pull/8437
Re: RFR: JDK-8285497: Add system property for Java SE specification maintenance version [v6]
> Add a new system property, java.specification.maintenance.version, to return > the maintenance release number of the Java SE specification being > implemented. The property is unset, optional in the terminology of > System.getProperties, for an initial release of a specification. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8285764 > > I'll update copyright years before an integration. 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 10 additional commits since the last revision: - Update wording to address review feedback. - Merge branch 'master' into JDK-8285497 - Change punctuation from review feedback. - Respond to review feedback; make sequence of values explicit. - Respond to review feedback. - Respond to review feedback. - Respond to CSR feedback. - Merge branch 'master' into JDK-8285497 - Update comment in template. - JDK-8285497: Add system property for Java SE specification maintenance version - Changes: - all: https://git.openjdk.java.net/jdk/pull/8437/files - new: https://git.openjdk.java.net/jdk/pull/8437/files/2048aaac..741ececa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8437=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8437=04-05 Stats: 13916 lines in 459 files changed: 8927 ins; 2577 del; 2412 mod Patch: https://git.openjdk.java.net/jdk/pull/8437.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8437/head:pull/8437 PR: https://git.openjdk.java.net/jdk/pull/8437
