RFR: Optional refactoring

[Aleksey Shipilev]

On Sun, 26 Mar 2023 08:38:53 GMT, Andrei Rybak <duke at openjdk.org> wrote:

> This is a follow-up to the email https://mail.openjdk.org/pipermail/jmh-dev/2023-January/003562.html
> 
> `java.util.Optional` isn't `Serializeable`. Because of that `org.openjdk.jmh.runner.options.TestOptions` fails with `java.io.NotSerializableException: java.util.Optional`, when  `org.openjdk.jmh.util.Optional` is completely replaced with `java.util.Optional`. See [test results on branch `java-util-optional`](https://github.com/rybak/jmh/actions/runs/4326921418), ([one commit](https://github.com/rybak/jmh/commit/25b9cb382be7285a51446976247d036ac855fc91) on top of initial state of this PR).
> 
> I didn't look further into possibility of removing `Optional`s as fields of class `CommandLineOptions`. I think that the refactoring up until the drop-in replacement to `java.util.Optional` might still be worth it, at least from the point of making it more approachable for people who are familiar with `java.util.Optional`.  So here are these changes for your consideration. Details are in the commit messages.

I believe `Options` and the relevant classes being `Serializable` is the reminiscent of the JMH a decade ago, when the full options carrier was passed via the binary link to forked VM. Today, `BinaryLinkClient` and `BinaryLinkServer` are passing the separate `*Params` objects. So, technically, we can avoid the issue with `j.l.Optional` being non-`Serializable` by dropping the test.

But, this highlights another issue: changing to `j.l.Optional` changes the public interface `Options`. This is the API-breaking change, AFAICS. The technical benefit of changing to `j.l.Optional` should outweigh the hassle of dealing with this breakage. Is there a benefit, apart from what you already identified ("People might be more familiar with `j.l.Optional`")?

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

PR Comment: https://git.openjdk.org/jmh/pull/98#issuecomment-1484891835