Re: RFR: 8247781: Day periods support [v11]
On Tue, 10 Nov 2020 00:07:16 GMT, Naoto Sato wrote: >> Hi, >> >> Please review the changes for the subject issue. This is to enhance the >> java.time package to support day periods, such as "in the morning", defined >> in CLDR. It will add a new pattern character 'B' and its supporting builder >> method. The motivation and its spec are in this CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8254629 >> >> Naoto > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Clarified 24:00 for "midnight" type in the spec. Some clean up. src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1483: > 1481: * exception is thrown and the day period is ignored. > 1482: * > 1483: * "midnight" type allows both "00:00" as the start-of-day and > "24:00" as the Editorial: Add "The " at the beginning of the sentence. - PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v12]
On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting builder
>> method. The motivation and its spec are in this CSR:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>>
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Added a test case for user defined temporal field resolution with day
> period.
test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line
877:
> 875: try {
> 876: dtf.parse("0 at night");
> 877: throw new RuntimeException("DateTimeParseException should be
> thrown");
Testng has `Assert.fail(message)` for this case.
-
PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v12]
On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato wrote: >> Hi, >> >> Please review the changes for the subject issue. This is to enhance the >> java.time package to support day periods, such as "in the morning", defined >> in CLDR. It will add a new pattern character 'B' and its supporting builder >> method. The motivation and its spec are in this CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8254629 >> >> Naoto > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Added a test case for user defined temporal field resolution with day > period. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v12]
On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato wrote:
>> Hi,
>>
>> Please review the changes for the subject issue. This is to enhance the
>> java.time package to support day periods, such as "in the morning", defined
>> in CLDR. It will add a new pattern character 'B' and its supporting builder
>> method. The motivation and its spec are in this CSR:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>>
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Added a test case for user defined temporal field resolution with day
> period.
src/java.base/share/classes/java/time/format/Parsed.java line 550:
> 548: long midpoint = dayPeriod.mid();
> 549: fieldValues.put(HOUR_OF_DAY, midpoint / 60);
> 550: fieldValues.put(MINUTE_OF_HOUR, midpoint % 60);
Set `dayPeriod = null` here, as it has been successfully used.
src/java.base/share/classes/java/time/format/Parsed.java line 502:
> 500: HOUR_OF_AMPM.checkValidValue(hoap);
> 501: }
> 502: if (dayPeriod.includes((hoap % 24 + 12) * 60)) {
Pretty sure the 24 should be 12.
Also, it should use `Math.floorMod()` to handle `HOUR_OF_AMPM = -1` (which is
11 o'clock).
Also, this doesn't take into account minutes. So if the day period rule is
afternoon1 to 18:30 and evening1 after 18:30, and the input is `HOUR_OF_AMPM =
6, MINUTE_OF_HOUR = 45`, this will fail to resolve,
Something like this should work (no need for `updateCheckDayPeriodConflict`):
long hoap = fieldValues.remove(HOUR_OF_AMPM);
if (resolverStyle == ResolverStyle.LENIENT) {
HOUR_OF_AMPM.checkValidValue(hoap);
}
Long mohObj = fieldValues.get(MINUTE_OF_HOUR);
long moh = mohObj != null ? Math.floorMod(mohObj, 60) : 0;
long excessHours = dayPeriod.includes(Math.floorMod(hoap, 12) + 12 * 60 +
moh ? 12 : 0;
long hod = Math.addExact(hoap, excessHours);
updateCheckConflict(HOUR_OF_AMPM, HOUR_OF_DAY, hod);
dayPeriod = null;
src/java.base/share/classes/java/time/format/Parsed.java line 546:
> 544:
> 545: // Set the hour-of-day, if not exist and not in STRICT, to
> the mid point of the day period or am/pm.
> 546: if (!fieldValues.containsKey(HOUR_OF_DAY) && resolverStyle
> != ResolverStyle.STRICT) {
Since this logic replaces both `HOUR_OF_DAY` and `MINUTE_OF_HOUR` I think it
should only be invoked if both do not exist. Beyond that, it doesn't really
make sense to do this logic if second/sub-second are present. Thus, it needs to
check all four fields and can then directly set the time.
if (!fieldValues.containsKey(HOUR_OF_DAY) &&
!fieldValues.containsKey(MINUTE_OF_HOUR) &&
!fieldValues.containsKey(SECOND_OF_MINUTE) &&
!fieldValues.containsKey(NANO_OF_SECOND) &&
resolverStyle != ResolverStyle.STRICT) {
if (dayPeriod != null) {
long midpoint = dayPeriod.mid();
resolveTime(midpoint / 60, midpoint % 60, 0, 0);
dayPeriod = null;
} else if (fieldValues.containsKey(AMPM_OF_DAY)) {
long ap = fieldValues.remove(AMPM_OF_DAY);
if (resolverStyle == ResolverStyle.LENIENT) {
resolveTime(Math.addExact(Math.multiplyExact(ap, 12), 6), 0, 0, 0);
} else { // SMART
AMPM_OF_DAY.checkValidValue(ap);
resolveTime(ap * 12 + 6, 0, 0, 0);
}
src/java.base/share/classes/java/time/format/Parsed.java line 568:
> 566: if (dayPeriod != null) {
> 567: // Check whether the hod is within the day period
> 568: updateCheckDayPeriodConflict(HOUR_OF_DAY, hod);
With the other changes, this is the only use of this method and it can
therefore be simplified (no need to check for conflicts, just whether it
matches the day period).
test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line
778:
> 776: {"h B", ResolverStyle.SMART, "59 in the morning", 11},
> 777:
> 778: {"H B", ResolverStyle.LENIENT, "47 at night", 23},
This test should be split in two - smart (fails) and lenient (succeeds). The
lenient tests should ensure that
`p.query(DateTimeFormatter.parsedExcessDays())` returns the expected number of
excess days.
I'd also add a test for a negative value such as "-2 at night"
-
PR: https://git.openjdk.java.net/jdk/pull/938
RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
JDK-8189198: Add "forRemoval = true" to Applet APIs - Commit messages: - Merge branch 'master' into JDK-8189198 - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs Changes: https://git.openjdk.java.net/jdk/pull/1127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8189198 Stats: 61 lines in 20 files changed: 10 ins; 0 del; 51 mod Patch: https://git.openjdk.java.net/jdk/pull/1127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127 PR: https://git.openjdk.java.net/jdk/pull/1127
Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs preliminary changes for JDK-8189198 for evaluation - PR: https://git.openjdk.java.net/jdk/pull/1127
Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > preliminary changes for JDK-8189198 for evaluation The following field, which is currently deprecated (not for removal) should probably also be marked as deprecated for removal:: javax.naming.Context: static final String APPLET The CSR and JEP should be updated accordingly. Also, what about the following? javax.swing.text.html.parser.DTD Element applet - PR: https://git.openjdk.java.net/jdk/pull/1127
Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs Since all APIs in the java.applet package are deprecated "forRemoval = true", consider adding a brief deprecation note to java/applet/package-info.java too. As an example, when all of the APIs in package java.rmi.activation were similarly deprecated in JDK 15, the following note was added: https://docs.oracle.com/en/java/javase/15/docs/api/java.rmi/java/rmi/activation/package-summary.html . Thanks! Iris - Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1127
Re: RFR: 8247781: Day periods support [v13]
> Hi, > > Please review the changes for the subject issue. This is to enhance the > java.time package to support day periods, such as "in the morning", defined > in CLDR. It will add a new pattern character 'B' and its supporting builder > method. The motivation and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addressed the following comments: - https://github.com/openjdk/jdk/pull/938#discussion_r522185469 - https://github.com/openjdk/jdk/pull/938#discussion_r522187931 - https://github.com/openjdk/jdk/pull/938#discussion_r522203757 - https://github.com/openjdk/jdk/pull/938#discussion_r522211444 - https://github.com/openjdk/jdk/pull/938#discussion_r522244221 - https://github.com/openjdk/jdk/pull/938#discussion_r522262379 - https://github.com/openjdk/jdk/pull/938#discussion_r522266836 - Changes: - all: https://git.openjdk.java.net/jdk/pull/938/files - new: https://git.openjdk.java.net/jdk/pull/938/files/a960804f..570b4582 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=11-12 Stats: 75 lines in 3 files changed: 23 ins; 23 del; 29 mod Patch: https://git.openjdk.java.net/jdk/pull/938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938 PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v11]
On Thu, 12 Nov 2020 15:18:44 GMT, Roger Riggs wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Clarified 24:00 for "midnight" type in the spec. Some clean up. > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java > line 1483: > >> 1481: * exception is thrown and the day period is ignored. >> 1482: * >> 1483: * "midnight" type allows both "00:00" as the start-of-day and >> "24:00" as the > > Editorial: Add "The " at the beginning of the sentence. Fixed. - PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v12]
On Thu, 12 Nov 2020 15:21:52 GMT, Roger Riggs wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a test case for user defined temporal field resolution with day
>> period.
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
> line 877:
>
>> 875: try {
>> 876: dtf.parse("0 at night");
>> 877: throw new RuntimeException("DateTimeParseException should
>> be thrown");
>
> Testng has `Assert.fail(message)` for this case.
Fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v12]
On Thu, 12 Nov 2020 15:41:56 GMT, Stephen Colebourne
wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added a test case for user defined temporal field resolution with day
>> period.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 550:
>
>> 548: long midpoint = dayPeriod.mid();
>> 549: fieldValues.put(HOUR_OF_DAY, midpoint / 60);
>> 550: fieldValues.put(MINUTE_OF_HOUR, midpoint % 60);
>
> Set `dayPeriod = null` here, as it has been successfully used.
Fixed.
> src/java.base/share/classes/java/time/format/Parsed.java line 502:
>
>> 500: HOUR_OF_AMPM.checkValidValue(hoap);
>> 501: }
>> 502: if (dayPeriod.includes((hoap % 24 + 12) * 60)) {
>
> Pretty sure the 24 should be 12.
>
> Also, it should use `Math.floorMod()` to handle `HOUR_OF_AMPM = -1` (which is
> 11 o'clock).
>
> Also, this doesn't take into account minutes. So if the day period rule is
> afternoon1 to 18:30 and evening1 after 18:30, and the input is `HOUR_OF_AMPM
> = 6, MINUTE_OF_HOUR = 45`, this will fail to resolve,
>
> Something like this should work (no need for `updateCheckDayPeriodConflict`):
>
> long hoap = fieldValues.remove(HOUR_OF_AMPM);
> if (resolverStyle == ResolverStyle.LENIENT) {
> HOUR_OF_AMPM.checkValidValue(hoap);
> }
> Long mohObj = fieldValues.get(MINUTE_OF_HOUR);
> long moh = mohObj != null ? Math.floorMod(mohObj, 60) : 0;
> long excessHours = dayPeriod.includes(Math.floorMod(hoap, 12) + 12 * 60 +
> moh ? 12 : 0;
> long hod = Math.addExact(hoap, excessHours);
> updateCheckConflict(HOUR_OF_AMPM, HOUR_OF_DAY, hod);
> dayPeriod = null;
Fixed.
> src/java.base/share/classes/java/time/format/Parsed.java line 546:
>
>> 544:
>> 545: // Set the hour-of-day, if not exist and not in STRICT, to
>> the mid point of the day period or am/pm.
>> 546: if (!fieldValues.containsKey(HOUR_OF_DAY) && resolverStyle
>> != ResolverStyle.STRICT) {
>
> Since this logic replaces both `HOUR_OF_DAY` and `MINUTE_OF_HOUR` I think it
> should only be invoked if both do not exist. Beyond that, it doesn't really
> make sense to do this logic if second/sub-second are present. Thus, it needs
> to check all four fields and can then directly set the time.
>
> if (!fieldValues.containsKey(HOUR_OF_DAY) &&
> !fieldValues.containsKey(MINUTE_OF_HOUR) &&
> !fieldValues.containsKey(SECOND_OF_MINUTE) &&
> !fieldValues.containsKey(NANO_OF_SECOND) &&
> resolverStyle != ResolverStyle.STRICT) {
>
> if (dayPeriod != null) {
> long midpoint = dayPeriod.mid();
> resolveTime(midpoint / 60, midpoint % 60, 0, 0);
> dayPeriod = null;
> } else if (fieldValues.containsKey(AMPM_OF_DAY)) {
> long ap = fieldValues.remove(AMPM_OF_DAY);
> if (resolverStyle == ResolverStyle.LENIENT) {
> resolveTime(Math.addExact(Math.multiplyExact(ap, 12), 6), 0, 0, 0);
> } else { // SMART
> AMPM_OF_DAY.checkValidValue(ap);
> resolveTime(ap * 12 + 6, 0, 0, 0);
> }
Fixed.
> src/java.base/share/classes/java/time/format/Parsed.java line 568:
>
>> 566: if (dayPeriod != null) {
>> 567: // Check whether the hod is within the day period
>> 568: updateCheckDayPeriodConflict(HOUR_OF_DAY, hod);
>
> With the other changes, this is the only use of this method and it can
> therefore be simplified (no need to check for conflicts, just whether it
> matches the day period).
Fixed.
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
> line 778:
>
>> 776: {"h B", ResolverStyle.SMART, "59 in the morning", 11},
>> 777:
>> 778: {"H B", ResolverStyle.LENIENT, "47 at night", 23},
>
> This test should be split in two - smart (fails) and lenient (succeeds). The
> lenient tests should ensure that
> `p.query(DateTimeFormatter.parsedExcessDays())` returns the expected number
> of excess days.
>
> I'd also add a test for a negative value such as "-2 at night"
Fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
> JDK-8189198: Add "forRemoval = true" to Applet APIs Andy Herrick 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: - JDK-8189198: Add "forRemoval = true" to Applet APIs - Merge branch 'master' into JDK-8189198 - Merge branch 'master' into JDK-8189198 - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs - Changes: - all: https://git.openjdk.java.net/jdk/pull/1127/files - new: https://git.openjdk.java.net/jdk/pull/1127/files/a74d..d9850cd8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00-01 Stats: 7753 lines in 89 files changed: 4891 ins; 1603 del; 1259 mod Patch: https://git.openjdk.java.net/jdk/pull/1127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127 PR: https://git.openjdk.java.net/jdk/pull/1127
Re: RFR: 8247781: Day periods support [v13]
On Thu, 12 Nov 2020 20:03:14 GMT, Naoto Sato wrote: >> Hi, >> >> Please review the changes for the subject issue. This is to enhance the >> java.time package to support day periods, such as "in the morning", defined >> in CLDR. It will add a new pattern character 'B' and its supporting builder >> method. The motivation and its spec are in this CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8254629 >> >> Naoto > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Addressed the following comments: > - https://github.com/openjdk/jdk/pull/938#discussion_r522185469 > - https://github.com/openjdk/jdk/pull/938#discussion_r522187931 > - https://github.com/openjdk/jdk/pull/938#discussion_r522203757 > - https://github.com/openjdk/jdk/pull/938#discussion_r522211444 > - https://github.com/openjdk/jdk/pull/938#discussion_r522244221 > - https://github.com/openjdk/jdk/pull/938#discussion_r522262379 > - https://github.com/openjdk/jdk/pull/938#discussion_r522266836 Approved with one overflow to fix. The spec could do with some rewording too. It might be better to explicitly mention the "resolving phase" with the three parts: > The day period is combined with other fields to make a `LocalTime` in the > resolving phase. If the `HOUR_OF_AMPM` field is present, it is combined with > the day period to make `HOUR_OF_DAY` taking into account any `MINUTE_OF_HOUR` > value. If `HOUR_OF_DAY` is present, it is validated against the day period > taking into account any `MINUTE_OF_HOUR` value. If a day period is present > without `HOUR_OF_DAY`, `MINUTE_OF_HOUR`, `SECOND_OF_MINUTE` and > `NANO_OF_SECOND` then the midpoint of the day period is set as the time. Note that the above is incomplete, and it doesn't describe STRICT/LENIENT, so the actual words will be more complex, src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5063: > 5061: } > 5062: Long moh = context.getValue(MINUTE_OF_HOUR); > 5063: long value = (hod * 60 + (moh != null ? moh : 0)) % 1_440; `long value = Math.floorMod(hod, 24) * 60 + (moh != null ? Math.floorMod(moh, 60) : 0);` and remove the next three lines - Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v13]
On Thu, 12 Nov 2020 21:49:16 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Addressed the following comments: >> - https://github.com/openjdk/jdk/pull/938#discussion_r522185469 >> - https://github.com/openjdk/jdk/pull/938#discussion_r522187931 >> - https://github.com/openjdk/jdk/pull/938#discussion_r522203757 >> - https://github.com/openjdk/jdk/pull/938#discussion_r522211444 >> - https://github.com/openjdk/jdk/pull/938#discussion_r522244221 >> - https://github.com/openjdk/jdk/pull/938#discussion_r522262379 >> - https://github.com/openjdk/jdk/pull/938#discussion_r522266836 > > src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java > line 5063: > >> 5061: } >> 5062: Long moh = context.getValue(MINUTE_OF_HOUR); >> 5063: long value = (hod * 60 + (moh != null ? moh : 0)) % 1_440; > > `long value = Math.floorMod(hod, 24) * 60 + (moh != null ? Math.floorMod(moh, > 60) : 0);` > > and remove the next three lines Thanks, Stephen. I made the changes based on your comments. - PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: 8247781: Day periods support [v14]
> Hi, > > Please review the changes for the subject issue. This is to enhance the > java.time package to support day periods, such as "in the morning", defined > in CLDR. It will add a new pattern character 'B' and its supporting builder > method. The motivation and its spec are in this CSR: > > https://bugs.openjdk.java.net/browse/JDK-8254629 > > Naoto Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Re-worded the spec of appendDayPeriodText, refactored calculation of minute-of-day. - Changes: - all: https://git.openjdk.java.net/jdk/pull/938/files - new: https://git.openjdk.java.net/jdk/pull/938/files/570b4582..1aa3134f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=12-13 Stats: 18 lines in 1 file changed: 0 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938 PR: https://git.openjdk.java.net/jdk/pull/938
Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick 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: > > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - Merge branch 'master' into JDK-8189198 > - Merge branch 'master' into JDK-8189198 > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - JDK-8189198: Add "forRemoval = true" to Applet APIs Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/1127
Re: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs @andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer. - PR: https://git.openjdk.java.net/jdk/pull/1127
