Optimize helidon optionals - io.helidon.common.mapper.OptionalValue

[re-thc]

Helidon docs says that Optional is expensive and don't use it unless you need to. In the generator, optionals are more of an implementation detail and null or the default value is returned. For better performance, this PR replaces optionals with contains / get as Helidon suggests.

[SentryMan]

Sure that makes sense, but it would seem the tests are failing. Try running your mvn commands with -Ptest. In addition, the helidon jsonb test module has a test that you can debug to set breakpoints during generation

[re-thc]

Thanks for the tip. Updated the code and ran the test locally with the fix.

[rob-bygrave]

Helidon docs says that Optional is expensive and don't use it unless you need to.

Well yes, it's actually an io.helidon.common.mapper.OptionalValue and not a java.util.Optional and yes, looking at the source it does look ugly in there (especially given we are only interested in the first String value).

It seems like an API miss to have the most common case sub-optimal with the 2 lookups of the key ... hmmm.

This is a nice improvement though, thanks !!

[re-thc]

@rob-bygrave thanks and yes in regards to the Helidon source there's a lot of great high level ideas, but it's definitely not as well optimized / polished like Netty or Jetty. There's likely some 20-40% performance to be gained just by tweaking some functions / flows. There's also missing validation and spec compliance so expect slowdowns (there's already a PR to fix host validation that looks heavy).