On Sat, 27 Jan 2024 15:36:59 GMT, Chen Liang <li...@openjdk.org> wrote:
>> David Alayachew has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Rather than reiterating the precondition, let's explain why the method >> failed > > I fail to see the point of this new API. Existing `ObjectMethods::bootstrap` > already achieves the same functionality in a better way (though the user code > looks a bit more conplex), as its produced MethodHandle can be stored in a > static final field and constant-fold by the JIT, while this method's argument > array can't as Java arrays are not constants, and this method is polymorphic. Hello @liach, Thank you for your response! > I fail to see the point of this new API. Existing `ObjectMethods::bootstrap` > already achieves the same functionality in a better way (though the user code > looks a bit more conplex), as its produced MethodHandle can be stored in a > static final field and constant-fold by the JIT, while this method's argument > array can't as Java arrays are not constants, and this method is polymorphic. `ObjectMethods::bootstrap` is a better fit for records, but I don't see how it could apply to general classes. Maybe you are saying a new method should instead be made on `ObjectMethods` that does something similar to the `bootstrap` method, but for classes? Regardless, the goal of this API was to provide functionality very similar to `java.util.Comparator`, where you can provide an ad-hoc set of functions to define your comparison logic. This method is the same thing, but for equality instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913196411
