On Mon, 28 Oct 2024 19:16:26 GMT, Brent Christian <bchri...@openjdk.org> wrote:
>> Sean Mullan has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 175 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Specify that params passed to getPermissions and implies are ignored and >> implies always returns false. >> - Change deprecated annotations to api notes on getPolicy and setPolicy. >> - clientlibs: Updated Problemlist >> Deleted javax/swing/JPopupMenu/6694823/bug6694823.java entry since it was >> determined that it is not a JDK bug but expected behavior on windows and >> linux platform. >> - clientlibs: Deleted JPopupMenu tests >> The following tests are deleted as they don't hold value without SM >> test/jdk/javax/swing/JPopupMenu/6691503/bug6691503.java - It tests that >> the popup are >> always-on-top for apps which doesn't hold value after SM removal. >> >> test/jdk/javax/swing/JPopupMenu/6694823/bug6694823.java - Tests whether >> popup can overlap taskbar. >> Works differently on macOS and windows & linux but this is the expected >> behavior. >> Details in JDK-8342012. Not a functional issue. >> - clientlibs: GetSoundBankSecurityException.java renamed to >> EmptySoundBankTest.java >> - clientlibs: GetSoundBankSecurityException.java renamed to >> EmptySoundBankTest.java >> test renamed, test summary updated >> - Restore note for implementers in >> src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java >> - Change "SecurityManager" to "Security Manager". Add some missing code and >> linkplain tags. >> - Add api note to class description that permission checking is not >> supported and remove text about getting permissions from system policy. In >> getPermissions(), change "granted to the given codesource" to "for the >> codesource". >> - ... and 165 more: https://git.openjdk.org/jdk/compare/1476f6c4...e490f698 > > src/java.base/share/classes/java/util/concurrent/Executors.java line 529: > >> 527: * execute the given {@code callable} under the current access >> 528: * control context, with the current context class loader as the >> 529: * context class loader. This method should normally be invoked > > We no longer state that the context class loader will be set when the > callable is called, though the returned Callable _will_ still set the ccl. Is > this OK? That's a good observation. Although deprecated for removal, the wording should at least specify what it does for the period before it is removed. I'll come up with some spec wording for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1820163200
