On Sat, 27 Jan 2024 17:05:59 GMT, Chen Liang <li...@openjdk.org> wrote:
> Your API is risky as well: it won't get a compile error if you add a new > field but forgot to add that field to equality checks too. And since > initialization happens in `<clinit>`, your said error is quite easy to detect > if this class is ever loaded. > > If you want this example to be "not brittle" you can resort to annotation > processors (essentially compiler plugins) that automatically generate > invokedynamic (which is better than this explicit field approach, as this > field is initialized eagerly while indy is lazy) As far as I can tell, the risk of my API is fully subsetted by yours. And while I can appreciate the suggestion to use annotations, I really question the wisdom of using an annotation for something that can be done with a simple library method. I understand that my version may not have the constant folding benefits of yours, but I am taking code that developers were already going to write and refactoring it to be slightly less error-prone and slightly more streamlined. Then, I package it into this `Objects` class and make it easy for them to understand and use. Not to mention, it's an import they probably have in hand already. And either way, the annotation would be somewhat unclear on where/how to use it. Remember, this method isn't just to implement `equals` for a class -- it is meant to be used anywhere that we need ad-hoc equality checks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17603#issuecomment-1913266509
