RFR: 8304818: Prune HttpURLConnection cache when corresponding Authenticator is garbage collected [v9]

[Daniel Fuchs]

On Thu, 13 Apr 2023 07:42:31 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java line 229:
>> 
>>> 227:         this.realm = realm;
>>> 228:         this.path = null;
>>> 229:         this.authcache = acache == null ? defCache : acache;
>> 
>> Do we really need that field? Now that AuthCacheValue instances are held in separate caches, there should be no need to have a field referring to the authenticator/cache in the auth value.
>> This let me thinks that some more refactoring could further simplify everything.
>> Having the value point to the cache in which it's been added seems wrong.
>
> That structure is not related to this change though. Previously, the value added itself to the single static cache, but now to add itself, it needs a reference to the cache instance. We could certainly reorganise this code, but I'm not sure that work belongs in this PR.

Possibly - but there seems to be a lot of churn caused by having to pass an AuthCacheImpl instance to the AuthCacheValue now. It makes it a bit difficult to reason about. I just wonder if *not* passing that value would not simplify the fix considerably. I'll try to import your changes and see what I can find.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13159#discussion_r1165391501