On Sat, 23 Apr 2022 00:09:48 GMT, Brent Christian <bchri...@openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java
>>  line 73:
>>> 71:         public void run() {
>>> 72:             if (enumClnt != null) {
>>> 73:                 enumClnt.clearSearchReply(res, homeCtx.reqCtls);
>> It's a bit strange to see that there is no guard here to verify that 
>> `homeCtx != null`, when line 76 implies that it might. My reading is that 
>> `homeCtxt` is not supposed to be `null` when `enumClnt` is not `null`. That 
>> could be explained in a comment, or alternatively asserted just before line 
>> 73 (`assert homeCtx != null;`)
> Yes, it is strange -- that code came from the finalizer. I will add an assert.

It appears that the update() method can set 'homeCtx' for 'ne' to null while 
leaving 'enumClnt' non-null (~L410).
Perhaps here, the clearSearchReply() call should only happen if both are 


PR: https://git.openjdk.java.net/jdk/pull/8311

Reply via email to