RFR: 8304283: Modernize the switch statements in jdk.internal.foreign

[Jorn Vernee]

On Wed, 15 Mar 2023 19:33:19 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java line 208:
>> 
>>> 206:     static boolean isUnbox(Binding binding) {
>>> 207:         return switch (binding) {
>>> 208:             case Binding.VMStore unused -> true;
>> 
>> I wonder... here it might be better to capture the box/unbox nature of a binding in a virtual method in the binding class? E.g. isBox(), isUnbox() ?
>
> I prefer this approach, to be honest, since the logic for all the different binding operators is in one place. It gives an overview of which operators are expected in an unboxing recipe. Making them virtual methods would put quite a bit of visual distance between the different `true`/`false` values.
> 
> I've been through the Binding file quite a bit, and the amount of scrolling/searching needed to find a particular implementation is kind of annoying.

To pull on that string some more. I think we should move the implementations of various Binding::verify methods here, or perhaps into a separate BindingVerifier class.

Ditto for the Binding::interpret implementations. They could be moved to BindingInterpreter. The Binding class would just be left as a simple bag of records + documentation for each operator.

The main motivation for this would be that, if you're looking at e.g. interpretation in `Binding`, there's a lot of noise that you have to filter through. I think it makes more sense to group these things into classes (for specialization/verification/interpretation), where all the code in a class is logically related.

-------------

PR: https://git.openjdk.org/jdk/pull/13047