RFR: Here are some easy patches
paul.sandoz at oracle.com
Mon Apr 30 21:03:29 UTC 2018
> On Apr 30, 2018, at 11:18 AM, Martin Buchholz <martinrb at google.com> wrote:
> On Mon, Apr 30, 2018 at 10:35 AM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> An obvious optimization:
>> 8202398: Optimize Arrays.deepHashCode
>> http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/ <http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/>
>> https://bugs.openjdk.java.net/browse/JDK-8202398 <https://bugs.openjdk.java.net/browse/JDK-8202398>
> I would prefer that the deeply nested ternary expressions be changed to a more expected if/else if/else
> My brain much prefers code transforming tabular data to "look tabular".
I think you will like expression switch :-) in the interim i would stick with the less eyebrow raising syntax.
> , and the last else throws an InternalError(“Should not reach here”) with some such message if you really want to express the case of an undetected array type.
> I'd hope valhalla engineers will catch it before anyone else. In fact, perhaps it's not too early to add a test as part of the valhalla project now?
I believe in principle it should just work (assuming hash code support for values themselves) because an array of values is currently a subtype of Object.
At some point we do need to investigate the L-world with tests for values and arrays/collections of, that will help test functionality but also expose issues around nulls. The 166 TCK might be a good place to start.
More information about the core-libs-dev