On Thu, 9 Feb 2023 13:17:30 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> Adam Sotona has updated the pull request incrementally with one additional >> commit since the last revision: >> >> AttributeElement.Kind removal (#48) > > src/java.base/share/classes/jdk/internal/classfile/Classfile.java line 66: > >> 64: * @param <V> the type of the optional value >> 65: */ >> 66: public sealed interface Option<V> permits Options.OptionValue { > > After looking more at the usages of Options it is not clear to me as to why > generics are needed. Lookup is always performed using a non-generic > Option.Key - so the API code has to be unchecked anyway. In fact, I'm not > even sure you need a `value()` method. When looking at usages, Option is > mostly something you create when you need to pass it to something else (e.g. > a constant pool, etc.). Since the client has created the option, it is not > clear to me that the client has a need to access the option value (which the > API implementation can access internally by other means). You are right, I've tried to remove generics from `Option` and `Option::value` method and it didn't have any impact on any use case we have. All access to the `Option` value is done through `ClassReader::optionValue` or `ConstantPoolBuilder::optionValue`, there was no use of `Option::value` at all. I think it is valuable API cleanup, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10982