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(a)redhat.com
> <mailto:rvansa@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(a)redhat.com <mailto:rvansa@redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:infinispan-dev@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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat