[infinispan-dev] Strategy to adopting Optional in APIs

[Dan Berindei]

Maybe yes, maybe not... in my experience escape analysis is very
fickle, e.g. it's very easy for a method to become big enough after
inlining that escape analysis is not performed at all.

Dan

On Fri, Mar 31, 2017 at 10:59 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> I was about to say the same: in the typical use case of returning an
> optional and using it immediately it would probably end up on the stack
> anyway...
>
> Tristan
>
> On 31/03/2017 09:57, Radim Vansa wrote:
>> 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
>>
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev