On Mon, 26 Aug 2024 14:40:46 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> Francisco Ferrari Bihurriet has updated the pull request incrementally with >> one additional commit since the last revision: >> >> Document list of reserved keys in >> java.security.Security::getProperty/setProperty APIs. >> >> Co-authored-by: Martin Balao <mba...@redhat.com> >> Co-authored-by: Francisco Ferrari Bihurriet <fferr...@redhat.com> > > I think throwing IAE is the cleanest approach and less likely there may be > unexpected behavior if we are not worried about backporting. It would break > any app previously using this as a property, but at least the behavior would > be consistent. > > I think the best alternate approach is to not expose it as a property. > > I think the compatibility risk of an app already using `include` as a > property should be extremely low. But one thought is to prepend a special > character (say "+") to the property name and add a sentence to the > `java.security` file that the `+include` property is not exposed in the > `Security` API. It could also be added as an implementation note to the > `Security` API. Since this property is JDK specific, I think an > implementation note would be acceptable. > Thanks @seanjmullan for sharing your view. Just to clarify, do you mean > renaming the `include` directive as `+include`? If so, I'd suggest using > `#include` that resemblances macros and pragma directives. > > We had an internal discussion at Red Hat and agreed in not pursuing a > backport of this enhancement. If you are not pursuing a backport, then I would stick with the current proposal and throw IAE, and there is no need to rename the property. Please update the compatibility risk section of the CSR to note the new behavior that an IAE will be thrown by the set/getProperty methods if any application previously depends on this property. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2310858585
