From mark at lawinegevaar.nl  Thu Dec 12 15:15:13 2024
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Thu, 12 Dec 2024 16:15:13 +0100
Subject: Feedback on JSR-221 maintenance release 4 (JDBC 4.4)
Message-ID: <a3f72450-7373-4a2b-842f-1496ea544c6a@lawinegevaar.nl>

Looking at the changelog in 
https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/index4.html, 
and specifically the javadoc diff from 
https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/221ChangeLog.html, 
I think the changed to SQLPermission should be reverted, and instead it 
should be deprecated (for removal, assuming BasicPermission also gets 
deprecated for removal?), as I think it serves no purpose when the 
SecurityManager is disabled/removed.

Without further context, the fact only the second paragraph is retained 
is confusing IMHO, and for example the see "(see below)" no longer 
applies with the removal of the table of permission names.

I think the original description should be preserved, and together with 
deprecation and an explanation why it is no longer used is better than 
the current change.

Mark
-- 
Mark Rotteveel


From lance.andersen at oracle.com  Thu Dec 12 15:54:10 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 12 Dec 2024 15:54:10 +0000
Subject: Feedback on JSR-221 maintenance release 4 (JDBC 4.4)
In-Reply-To: <a3f72450-7373-4a2b-842f-1496ea544c6a@lawinegevaar.nl>
References: <a3f72450-7373-4a2b-842f-1496ea544c6a@lawinegevaar.nl>
Message-ID: <CFC424ED-379F-4EF3-A36B-A241A5CF89A0@oracle.com>

As indicated in JEP 486<https://openjdk.org/jeps/486>:

??????
In a future release we will deprecate Permission and related classes such as BasicPermission, PermissionCollection, and Permissions, and also subclasses of Permission outside of the java.security package, such as java.lang.RuntimePermission, java.net.NetPermission, and java.lang.reflect.ReflectPermission.

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

Once the above occurs the same will be done for other classes such as SQLPermission


As a side note, I will be working on a small JDBC MR tentatively targeted for JDK 26 at which point I hopefully will be in position to deprecate this class and other Permission related classes within the JDK


On Dec 12, 2024, at 10:15?AM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:

Looking at the changelog in https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/index4.html, and specifically the javadoc diff from https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/221ChangeLog.html, I think the changed to SQLPermission should be reverted, and instead it should be deprecated (for removal, assuming BasicPermission also gets deprecated for removal?), as I think it serves no purpose when the SecurityManager is disabled/removed.

Without further context, the fact only the second paragraph is retained is confusing IMHO, and for example the see "(see below)" no longer applies with the removal of the table of permission names.

I think the original description should be preserved, and together with deprecation and an explanation why it is no longer used is better than the current change.

Mark
--
Mark Rotteveel


[oracle_sig_logo.gif]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdbc-spec-discuss/attachments/20241212/02257f16/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/jdbc-spec-discuss/attachments/20241212/02257f16/oracle_sig_logo.gif>

From mark at lawinegevaar.nl  Thu Dec 12 16:08:02 2024
From: mark at lawinegevaar.nl (Mark Rotteveel)
Date: Thu, 12 Dec 2024 17:08:02 +0100
Subject: Feedback on JSR-221 maintenance release 4 (JDBC 4.4)
In-Reply-To: <CFC424ED-379F-4EF3-A36B-A241A5CF89A0@oracle.com>
References: <a3f72450-7373-4a2b-842f-1496ea544c6a@lawinegevaar.nl>
 <CFC424ED-379F-4EF3-A36B-A241A5CF89A0@oracle.com>
Message-ID: <fd193389-0c1d-4bb2-a4ec-3ea25d73f107@lawinegevaar.nl>

OK, so deprecation will follow later together with Permission, etc. I 
understand, that seems OK.

What about my other point? IMHO, the javadoc is now a bit confusing with 
the retention of the text:

"""
A SQLPermission object contains a name (also referred to as a "target 
name") but no actions list; there is either a named permission or there 
is not. The target name is the name of the permission (see below). The 
naming convention follows the hierarchical property naming convention. 
In addition, an asterisk may appear at the end of the name, following a 
".", or by itself, to signify a wildcard match. For example: 
loadLibrary.* and * signify a wildcard match, while *loadLibrary and a*b 
do not.
"""

Especially given the:

* "(see below)", referring to the now removed table
* The second part of the paragraph ("The naming convention ... a*b do 
not."), which I think never really applied for SQLPermission, but was 
copied (and modified?) from BasicPermission

The retained paragraph feels a bit as if you're falling into the middle 
of a conversation and have missed something ("OK, a SQLPermission has a 
name, but what is it?"), which is why I think it's probably better to 
retain the old text and together with the API note, it will be clear 
it's no longer used, and why.

And good to hear there are plans for a further maintenance release.

Mark

On 12/12/2024 16:54, Lance Andersen wrote:
> As indicated in JEP 486 <https://openjdk.org/jeps/486>:
> 
> ??????
> In a future release we will deprecate |Permission|?and related classes 
> such as |BasicPermission|, |PermissionCollection|, and |Permissions|, 
> and also subclasses of |Permission|?outside of the |java.security| 
>  ?package, such as |java.lang.RuntimePermission|, | 
> java.net.NetPermission|, and |java.lang.reflect.ReflectPermission|.
> 
> ------------------
> 
> Once the above occurs the same will be done for other classes such as 
> SQLPermission
> 
> 
> As a side note, I will be working on a small JDBC MR tentatively 
> targeted for JDK 26 at which point I hopefully will be in position to 
> deprecate this class and other Permission related classes within the JDK

-- 
Mark Rotteveel

From lance.andersen at oracle.com  Fri Dec 13 17:38:12 2024
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 13 Dec 2024 17:38:12 +0000
Subject: Feedback on JSR-221 maintenance release 4 (JDBC 4.4)
In-Reply-To: <fd193389-0c1d-4bb2-a4ec-3ea25d73f107@lawinegevaar.nl>
References: <a3f72450-7373-4a2b-842f-1496ea544c6a@lawinegevaar.nl>
 <CFC424ED-379F-4EF3-A36B-A241A5CF89A0@oracle.com>
 <fd193389-0c1d-4bb2-a4ec-3ea25d73f107@lawinegevaar.nl>
Message-ID: <959BA7CE-E59C-41C9-84F3-20E35AC30DF7@oracle.com>

I am in the process of removing ?(see below)?  which was an oversight (as you can imagine there was a lot of code touched because of JEP 486)

The rest of the verbiage has been around since JDK 1.3 when SQLPermission was introduced and there was nothing to prevent anyone from specifying a name that was not in the table as there was never any validation of the name value passed to the SQLPermission constructor (and you still have to specify a name to the constructor).

With JEP 486, we have tried to keep changes as small as possible across the JDK and with SecurityManager permanently disabled, there is no real use case for SQLPermission.

On Dec 12, 2024, at 11:08?AM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:

OK, so deprecation will follow later together with Permission, etc. I understand, that seems OK.

What about my other point? IMHO, the javadoc is now a bit confusing with the retention of the text:

"""
A SQLPermission object contains a name (also referred to as a "target name") but no actions list; there is either a named permission or there is not. The target name is the name of the permission (see below). The naming convention follows the hierarchical property naming convention. In addition, an asterisk may appear at the end of the name, following a ".", or by itself, to signify a wildcard match. For example: loadLibrary.* and * signify a wildcard match, while *loadLibrary and a*b do not.
"""

Especially given the:

* "(see below)", referring to the now removed table
* The second part of the paragraph ("The naming convention ... a*b do not."), which I think never really applied for SQLPermission, but was copied (and modified?) from BasicPermission

The retained paragraph feels a bit as if you're falling into the middle of a conversation and have missed something ("OK, a SQLPermission has a name, but what is it?"), which is why I think it's probably better to retain the old text and together with the API note, it will be clear it's no longer used, and why.

And good to hear there are plans for a further maintenance release.

Mark

On 12/12/2024 16:54, Lance Andersen wrote:
As indicated in JEP 486 <https://openjdk.org/jeps/486>:
??????
In a future release we will deprecate |Permission| and related classes such as |BasicPermission|, |PermissionCollection|, and |Permissions|, and also subclasses of |Permission| outside of the |java.security|   package, such as |java.lang.RuntimePermission|, | java.net.NetPermission|, and |java.lang.reflect.ReflectPermission|.
------------------
Once the above occurs the same will be done for other classes such as SQLPermission
As a side note, I will be working on a small JDBC MR tentatively targeted for JDK 26 at which point I hopefully will be in position to deprecate this class and other Permission related classes within the JDK

--
Mark Rotteveel

[oracle_sig_logo.gif]






Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdbc-spec-discuss/attachments/20241213/ae848272/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.org/pipermail/jdbc-spec-discuss/attachments/20241213/ae848272/oracle_sig_logo-0001.gif>