Valhalla EG notes November 21, 2018
brian.goetz at oracle.com
Fri Nov 30 16:22:55 UTC 2018
> 2. Substitutability
> Remi: lambda examples use ==. None use == followed by .equals, in fact
> none use .equals.
> Karen: other searches have found 10-50% use == followed by .equals
> Remi: Hard to find cases with static Object/Interface and dynamic
> Lambda today
Code that knows what it is dealing with generally uses either `==` or
`.equals()` but not both.
Generic code (including dynamically typed code, like pre-generic
collections) generally use `==` followed by `.equals()`, but sometimes
just uses `.equals()` (which is OK). Just using `==` is, of course,
dangerous, unless you know that you are dealing with constrained
instances (enums, interned strings, etc.)
The historical route by which we got here is:
- In the interpreted days, `==` was a fast filter for `.equals()`,
since when crawling a list, most things are not equal to what you're
- Because `==` was historically fast, it is harmless as a pre-check.
Now, method invocation got faster, and `==` is going to get slower, so
obviously the equilibrium will change.
> Karen: Challenges:
> component-wise substitutability
> - primitives - usual check (floating point extra care)
> - pojos - non-Object/Interface - reference comparison
> - value type - static or dynamic (Object/Interface) - requires
> recursive check
> performance - due to lots of fields or depth or both
> could get StackOverflowError from unbounded links
> e.g. for a valid use case - tree-node
> Is it appropriate for acmp to perform a substitutability check? It was
> intended as a short circuit pretest to a longer test.
I am still preparing my armaments for this assault :)
> 3. Nullability
> Editor’s note: LW2: QPoint; null-free reference to Point. LPoint;
> nullable box for Point.
I would prefer to reframe this as "opting into protection against
More information about the valhalla-spec-observers