RFR: 8345139: Fix bugs and inconsistencies in the Provider services map [v4]
Martin Balao
mbalao at openjdk.org
Wed Feb 12 00:11:17 UTC 2025
On Tue, 11 Feb 2025 23:33:49 GMT, Francisco Ferrari Bihurriet <fferrari at openjdk.org> wrote:
>> Hi, this pull request implements the fixes for bugs and inconsistencies described in [JDK-8345139](https://bugs.openjdk.org/browse/JDK-8345139 "Fix bugs and inconsistencies in the Provider services map").
>>
>> #### New services map design
>>
>> Here is the high-level hierarchy of the new services map design:
>>
>> * `servicesMap` (`ServicesMap`)
>> * Instances
>> * `impl` (`ServicesMapImpl`)
>> * `services` (`Map<ServiceKey, Service>`): unifies the previous `serviceMap` and `legacyMap`
>> * `legacySvcKeys` (`Set<ServiceKey>`): set indicating which keys in `services` correspond to the Legacy API
>> * `serviceProps` (`Map<ServiceKey, String>`): keeps track of the _provider Hashtable entries_ that originated services entries <sup>(1)</sup>
>> * `serviceAttrProps` (`Map<ServiceKey, Map<UString, String>>`): keeps track of the _provider Hashtable entries_ that originated service attributes <sup>(1)</sup>
>> * `serviceSet` (`AtomicReference<Set<Service>>`): part of a lock-free mechanism to implement a consistent version of the `getServices()` readers method
>> * Writers' methods (for providers registration)
>> * `Current asCurrent()`: returns `impl` seen as a `Current` interface implementer
>> * `putService(Service svc)`
>> * `removeService(Service svc)`
>> * `Legacy asLegacy()`: returns `impl` seen as a `Legacy` interface implementer
>> * `putClassName(ServiceKey key, String className, String propKey)`
>> * `putAlias(ServiceKey key, ServiceKey aliasKey, String propKey)`
>> * `putAttribute(ServiceKey key, String attrName, String attrValue, String propKey)`
>> * `remove(ServiceKey key, String className)`
>> * `removeAlias(ServiceKey key, ServiceKey aliasKey)`
>> * `removeAttribute(ServiceKey key, String attrName, String attrValue)`
>> * Readers' methods (for services users and `GetInstance` APIs)
>> * `Set<Service> getServices()`
>> * `Service getService(ServiceKey key)`
>> * Other methods: default and copy constructors, `void clear()`
>>
>> (1): to maintain the consistency between the provider's `servicesMap` and its _Hashtable entries_, even if Legacy API updates occur through _properties_ with different casing, or aliases instead of main algorithms.
>>
>> #### Testing
>>
>> As part of our testing, we observed all the tests pass in the following categories:
>>
>> * `jdk:tier1` (see [...
>
> Francisco Ferrari Bihurriet has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>
> - Merge openjdk/master into JDK-8345139
>
> Fix conflict caused by e20bd018c4046870d0cf632bb8e5440cb9f5c3c2:
> 1. Ignore the change, as this had already been identified and fixed
> (see JDK-8345139, section 3.1).
> 2. Remove the test, as it is already covered by
> ServicesConsistency::testInvalidServiceNotReturned.
> 3. Add the corresponding bug ID to ServicesConsistency.
>
> Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
> Co-authored-by: Martin Balao Alonso <mbalao at redhat.com>
> - ServicesMapImpl class and Current, Legacy interfaces removed.
>
> Co-authored-by: Martin Balao Alonso <mbalao at redhat.com>
> Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
> - Copyright update.
>
> Co-authored-by: Martin Balao Alonso <mbalao at redhat.com>
> Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
> - 8345139: Fix bugs and inconsistencies in the Provider services map
>
> Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
> Co-authored-by: Martin Balao <mbalao at redhat.com>
The reason for having `Current` and `Legacy` interfaces was only to internally group methods and stress the distinction. We have now removed it and proposed a flat hierarchy for the `ServicesMap` (without the interfaces and impl class).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22613#issuecomment-2652335492
More information about the security-dev
mailing list