[infinispan-dev] Strategy to adopting Optional in APIs

[Radim Vansa]

I secretly hope that all these allocations would be inlined and 
eliminated. If we find out that it really allocates the objects (from 
JFR's allocation stats), it's a reason to rewrite that piece of code to 
the dull optionless version.
TBH I am rather afraid that the JVM will allocate the consumer which 
will need some captured variables. Maybe I trust C2 compiler too much, 
believing that if the handler isn't too big, it will generate similar 
instructions with nicer source code :-/

R.


On 03/30/2017 11:08 PM, Sanne Grinovero wrote:
> I'm for "at discretion" and "avoid if not really needed" : not cool to 
> allocate objects for no reason.
>
> On 30 Mar 2017 16:57, "Radim Vansa" <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hi,
>
>     I was wondering what's the common attitude towards using Optional in
>     APIs, and what naming pattern should we use. As an example, I dislike
>     calling
>
>     if (entry.getMetadata() != null && entry.getMetadata().version()
>     != null) {
>          foo.use(entry.getMetadata().version())
>     }
>
>     where I could just do
>
>     entry.metadata().flatMap(Metadata::optionalVersion).ifPresent(foo::use)
>
>     Here I have proposed metadata() method returning Optional<Metadata>
>     (regular getter method is called getMetadata()) and annoying
>     optionalVersion() as version() is the regular getter.
>
>     Shall we adopt some common stance (use/don't use/use at developer's
>     discretion) and naming conventions? Is it acceptable to start adding
>
>     default Optional<Foo> foo() { Optional.ofNullable(getFoo()); }
>
>     whenever we feel the urge to chain Optionals?
>
>     Radim
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team