RFR: 8339735: Remove references to Applet in core-libs/security APIs
Sean Coffey
coffeys at openjdk.org
Wed Sep 18 06:28:05 UTC 2024
On Tue, 17 Sep 2024 23:36:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:
>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>>
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as
>>
>>
>> * @apiNote
>> * Thread groups provided a way in early Java releases to group threads and provide
>> * a form of <i>job control</i> for threads. Thread groups supported the isolation
>> * of applets and defined methods intended for diagnostic purposes. It should be
>> * rare for new applications to create ThreadGroups and interact with this API.
>>
>>
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_.
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:
>
>> 72: <code>volatile</code> (or access to the variable must be
>> 73: synchronized).</p>
>> 74: <p>For example, suppose your application contains the following
>
> The example below is still applet specific (e.g., `repaint()`). May need to be more generic.
`repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.
given the thread name `blink`, perhaps we could just use `blink()` in this example.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764469513
More information about the core-libs-dev
mailing list