RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

Rezaei, Mohammad A. Mohammad.Rezaei at gs.com
Wed Nov 25 03:52:46 UTC 2015


Value based things make a lot of sense for types that don't belong to well established reference hierarchies. I can even see great uses for a value based List implementation, so long as it's preferentially referenced as the exact type (e.g. private ValueBasedList someList = ...) and rarely cast to the interface type (List).

But I've been scratching my head about the empty collections (of()) and I can't figure out why value based would be a good idea. Currently, there is only one instance in the entire VM, so it's unlikely to get any memory benefits. The most likely use for the return value is either a variable/member of type List or something that can hold a List (like a Map<K, List>), which will likely cause an immediate boxing. In some cases this can be elided (lots of inlining and optimization), but that's the less likely case.

What's the rationale for the value based spec for the empty implementations?

Thanks
Moh

>-----Original Message-----
>From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf
>Of John Rose
>Sent: Tuesday, November 24, 2015 9:08 PM
>To: Stuart Marks
>Cc: core-libs-dev
>Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-
>8139232)
>
>On Nov 23, 2015, at 10:26 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
>>
>> Please review these API and implementation changes that comprise the first
>integration of JEP 269. I intend to push this under the "initial API and
>skeleton implementation" subtask, JDK-8139232.
>
>Please strengthen the specification to assert that the new immutables are in
>fact value-based.
>
>http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html
><http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html>
>
>This will prevent people from relying on their identity (acmp) and
>synchronization (monitorenter).
>It will allow optimizations more freedom to use flatter storage formats and to
>reuse list values.
>
>If we don't do this now, then we will not be able to retroactively make or
>enforce the claim,
>and the optimizations will be impossible.
>
>— John


More information about the core-libs-dev mailing list