RFR: SKARA-1096: New command and label for JEPs, similar to CSR [v8]

[Magnus Ihse Bursie]

On Tue, 19 Apr 2022 16:48:19 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> The drawback of doing that is that JEPCommand would still need to implement the old handle method, which doesn't make sense for it to do. Unless we also add a default empty implementation for the original handle method.
>> 
>> @lgxbslgx If you want to change it to avoid touching all the other commands, using default methods in the interface instead, that's ok, but I'm also ok leaving it as it is.
>
>> This way, the commands that need the new label handling mechanism can implement the new handle override with the extended argument list. All other commands needs no change.
> 
> If we obey this convention which adds a new "bridge" `handle` method. Next time, we want to add another parameter and add a new `handle` method, too. The interface `CommandHandler` will have sevaral such "bridge" `handle` methods in the future which are actually unnecessary. @erikj79, @magicus and I may feel good with it because we added or reviewed it. But in the future, the new SKARA developers may be confused by it. In other words, the maintainment of the project may become a little more complex.
> 
>>  but I'm also ok leaving it as it is.
> 
> I would like to keep the code as it is now.

No, each and every implementation of `CommandHandler` would only implement a single `handle()` method.

At least, if I'm thinking correctly about this. :-)

When processing WorkItems, in `processCommand`, we call the "long" version, with the two extra arguments. This will have a default implementation in the `CommandHandler` interface, which calls the "short" version, dropping the two last arguments. The "short" version will have a default implementation, which does nothing. (This is exactly the case of the code right now, without this PR.) 

So, my suggestion is that we leave the old "short" method untouched, add a new "long" method which by default delegates to the "short" method, and call the new "long" method in `processCommand`.

Then all old implementations can keep their "short" implementations, and everything will work as before.

JEPCommand will need to override the new "long" version instead (and can just ignore the "short" version), and everything will work perfect for it too.

And if we in the future need to add further arguments, we can do the same procedure again -- add a new long-long method, which deletages to the long method, etc.

I believe this was the exact use case that the `default` method implementation in interfaces was intended for.

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

PR: https://git.openjdk.java.net/skara/pull/1297