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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2310728235
