Armeria: Reconsider the usage of `Optional<T>` in our API

[trustin]

The early API such as Scheme.tryParse() and Server.activePort() returns an Optional while more recent APIs just return null.

Given that Optional tends to make user code verbose and JDK will nor make Optional a value type due to backward compatibility (which is a shame..), I think it's better just returning a nullable value.

This guarantees breaking changes, but migration should be as simple as wrapping with Optional.ofNullable(), so ... :sweat_smile:

[minwoox]

Let's get rid of all of'em!

[ikhoon]

👍 I think this is also good for interop with Kotlin. #1078

[alex-lx]

Hi, @trustin, I'm a Armeria's fan and we're doing something like code style in our team, but we meet a problem that when to use Optional or Nullable. could you mind to share more details about how you make this decision?

AFAIK, Optional could be used as return type of a method, then it can be used in a fluent style, using map to simulate ?. and orElse to simulate ?: in some other language. However, it doesn't recommend to use Optional as a field because Optional is not serializable(In practise, we rarely use Java Serialization, so if the rule can be break? :-)).

At last, In "JDK will nor make Optional a value type", what's a value type, is it a fancy thing in newer Java?

Big thanks to you~~

[trustin]

Hi @alex-lx! Value types are 'inline classes':

• https://www.infoq.com/articles/inline-classes-java/
• https://dzone.com/articles/project-valhalla-fast-and-furious-java

Optional is not an inline class and I guess it will never be so due to backward compatibility reasons.

A user who prefers method chaining with Optional could wrap the return value with Optional.ofNullable(...), although it's verbose. I wish Java introduces operators like ?, ?. ?: once Project Valhalla is ready.

[alex-lx]

Thanks, @trustin! I agree sometimes it's really verbose and hard to read that using Optional.