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