RFR: 8356557: Update CodeSource::implies API documentation and deprecate java.net.SocketPermission class for removal [v2]

Jaikiran Pai jpai at openjdk.org
Thu Jul 17 12:35:51 UTC 2025


On Mon, 14 Jul 2025 20:04:21 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> `SocketPermission` should be deprecated for removal as has already been done for many other `Permission` subclasses. However, `CodeSource.implies()` has specification dependencies on `SocketPermission` which requires additional changes to decouple those dependencies. 
>> 
>> This change deprecates `SocketPermission`for removal and removes the dependency on `SocketPermission` from `CodeSource.implies` by copying the relevant conditions from `SocketPermission.implies`. Additional test cases for `CodeSource.implies` were also added to check that the behavior is consistent.
>> 
>> Note that we may also eventually deprecate `CodeSource.implies` for removal but that requires more investigation.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @SuppressWarnings("removal") to SocketPermissionCollection.

src/java.base/share/classes/java/security/CodeSource.java line 287:

> 285:      *           one of <i>codesource</i>'s IP addresses or this object's
> 286:      *           canonical host name must equal <i>codesource</i>'s canonical
> 287:      *           host name.

Hello Sean, the original text in `SocketPermission.implies()` lists these 2 rules separately, as follows:

>
> <li>If this object was not initialized with a single IP address, and one of this object's IP addresses equals one of <i>p</i>'s IP addresses.
>
> <li>If this canonical name equals <i>p</i>'s canonical name.

Given that we state at the beginning of this text that `the following checks are made in order:`, do you think we should continue to list these 2 rules separately, in that order, instead of combining them into one, like what's being proposed here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26300#discussion_r2213215820


More information about the security-dev mailing list