On Thu, 16 May 2024 09:40:58 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> That seems pretty extreme -- it's an array we explicitly don't want and are >> going to ignore? If somebody passes a non-null member, we will throw as >> unsupported. I was thinking that was enough, hence removing the sbjs array >> to be quite certain we can't pass on any supplied Subjects. > > Well my thinking was this: the fact that the jconsole tab was blank shows > that the array may being passed. The previous code verified that all three > arrays had the same length - so it would have failed if the array had a > length different than the other two. So I would prefer if we kept on throwing > in that case. In other words, we now allow and prefer `null` - but if > non-null - we will allow a null-filled array passed by an older client but > we should not accept something that would have been invalid then. That the JConsole tab was blank shows that the older RMIConnector's addListenerWithSubject creates a new single-entry array from the given delegationSubject (which is null) and passes it onwards. The app is not creating the array itself., that's us. (also, maybe that JConsole relies on listeners in order to show a screen that doesn't really need to depend on them, but this change is obviously about being compatible with that) We all know that that is the only use case out there, the current wisdom is that this feature is not used, nobody is creating the Subject array and calling addListenersWithSubjects (plural) with it... IF we find such an app app, we are going to ignore the array unless it contains a non-null entry. This seems safe and efficient. We are documenting that it should be null, and it is weird to document a length requirement for something that should be null... 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19253#discussion_r1603064299
