On Mon, 26 Aug 2024 18:53:58 GMT, Sean Mullan <mul...@openjdk.org> wrote:
>> 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. @seanjmullan @wangweij , is there anything else that you would like to discuss regarding this proposal? ------------- PR Comment: https://git.openjdk.org/jdk/pull/16483#issuecomment-2329565712
