On Thu, 16 May 2024 12:35:22 GMT, Raffaello Giulietti <rgiulie...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java >> line 204: >> >>> 202: new RandomGeneratorProperties(rgClass, name, group, >>> 203: i, j, k, equidistribution, >>> 204: flags | >>> (rgClass.isAnnotationPresent(Deprecated.class) ? DEPRECATED : 0))); >> >> Hello Raffaello, this is the final remaining reflection usage and even this >> I think isn't required now that all the random generator implementations >> reside within java.base as an implementation detail. >> >> I think we should just skip this annotation check here and set `DEPRECATED` >> bit on the `flags` to `0` for all implementations. When/if we do deprecate >> any of the random generators, we can just come here and switch that bit to >> on for the specific random generator when instantiating this >> `RandomGeneratorProperties` record. I had a brief look at the code and the >> documentation in `package-info.java` of `java/util/random` and we don't >> mention that we rely on the `@Deprecated` annotation to determine whether >> an algorithm is deprecated. I think that's a good thing. > > Yes, I thought about this the other day but decided for a bit more > conservative approach, relying on the annotation. > > But I agree that, since the meta-information now resides in > `RandomGeneratorProperties`, we might "migrate" the deprecation status here > as well. Since the legacy generators are public classes, they can be publicly deprecated, so in the last commit the `DEPRECATED` bit for them still relies on the annotation, which IMO is the authoritative "source of truth". For the 10 other algorithms, which are accessible only via `RandomFactoryGenerator`, we can rely on the info in `RandomProperties`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19212#discussion_r1603336696
