1

There doesn't seem to be any cached objects of type Optional<Boolean> for the true and false values available in the standard library. Am I missing them somewhere?

It would surprise me if there were no such objects because it seems to me like this would be so useful, for both clarity and performance.

If there really are no such objects, why is that?

Konstantin Yovkov
  • 62,134
  • 8
  • 100
  • 147
Lii
  • 11,553
  • 8
  • 64
  • 88
  • Related: http://stackoverflow.com/questions/23922134/is-java-8-missing-an-optionalboolean – Maroun Feb 26 '15 at 09:08
  • @MarounMaroun: Yeah, I just added an answer there which made me start thinking about this. – Lii Feb 26 '15 at 09:09

2 Answers2

2

In Java 8, they have improved the optimisation of object creation, especially for short lived objects such as Optional. What the JIT can do is use Escape Analysis to eliminate short lived objects by placing their fields on the stack. In the case of Optional<Boolean> this can most likely be turned in no more than boolean

See the following article on object elimination, how to detect it is not working and what you can do about it. Java Lambdas and Low Latency

The converse question, is why have OptionalInt, OptionalLong and OptionalDouble? These are likely to be useful, just not as useful as you might think. Unlike Boolean not all Integer, Long and Double values are cached, and while Escape Analisys can eliminate objects, it is expensive and can take a while to kick in, possibly never for code not run long enough.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • Escape analysis is of course a very good think but I have read many warnings about relying on it, e.g. from Stuart Mark on other topics relating to Project Lambda. EA only works reliably in simple, intra-procedural cases. – Lii Feb 26 '15 at 09:15
  • 1
    @Lii correct, though Optional is generally used in simple, intra-method cases. It is rarely assigned to fields I would imagine. – Peter Lawrey Feb 26 '15 at 09:16
  • 2
    @Lii: the intended use case of `Optional` perfectly fits into EA, i.e. created and returned by an operation (e.g. `find`), then queried and dropped by the direct caller. – Holger Feb 26 '15 at 09:17
  • @Holger: Well, maybe, I'm not sure. Can the EA system really return objects on the stack? Or would it only kick in if the called method is inlined? I suspect the latter. The stream library also has much indirection and deep call stacks, I suspect EA is of little use there. – Lii Feb 27 '15 at 07:12
  • @Lii AFAIK the method needs to be in lined though this may happen more than you might think. – Peter Lawrey Feb 27 '15 at 07:36
  • @Lii in lining can occur with deep call stacks too. – Peter Lawrey Feb 27 '15 at 07:37
  • @Lii: HotSpot may inline fairly deep if code is really “hot”, however, to elide the `Optional` creation, it doesn’t need to inline the entire stream operation. It only needs to inline the part where the `Optional` will be created which usually happens at the end, right before returning it. – Holger Feb 27 '15 at 08:51
  • 1
    I guess the bottom line here is that it might manage to remove the object creation, but you really can't count on it. – Lii Feb 27 '15 at 09:34
1

There is no reason to fix a particular optimization strategy into the API. Optional instances are acquired via a factory method and it’s behavior regarding returned object identities is intentionally unspecified.

So implementations can have a caching facility internally but it may also be the case that the JVM’s optimizer takes care about such things. Today’s JVMs already elide instance creations in hotspots when possible, but future JVM implementations may also inject caching or de-duplication facilities for “value based classes”.

See also “Why should I not use identity based operations on Optional in Java8?”

Community
  • 1
  • 1
Holger
  • 285,553
  • 42
  • 434
  • 765
  • On the other hand, to implement caching of `Optional` in the factory method `Optional.of` the type of the argument would have to be tested in _every_ case. If there were specific constants for `Optional` the client could choose those directly. – Lii Feb 27 '15 at 07:04
  • Although a definitive answer to this question would have to reference the dev mailing lists of come from one of the designers this one seems to me as the more likely. – Lii Feb 27 '15 at 07:05
  • As a side note, compiling code with autoboxing of `boolean` values also generates code calling `Boolean.valueOf` instead of accessing the constants `Boolean.TRUE` and `Boolean.FALSE` directly. Treating all cases uniformly makes things easier… – Holger Feb 27 '15 at 08:42
  • Maybe we'll have autoboxing of `Optional` some day. Or even [user defined autoboxing](https://msdn.microsoft.com/en-us/library/vstudio/z5z9kes2%28v=vs.100%29.aspx). – Lii Jun 16 '15 at 07:52
  • @Lii: that linked C# feature is just defining how conversion will be handled in source code. For JVM side optimization such thing is not needed. All it needs is the knowledge that certain factory methods have that value type semantics and may be treated specially (there are plenty of them, even today). There might be an annotation based solution for marking such factory methods but actually, when you obey the contract that you should not care for the identity of the returned objects, the JVM has already everything it needs to determine the value based nature of these objects by code analysis. – Holger Jun 16 '15 at 08:34