JEP 186: Collection Literals

[Remi Forax]

On 01/14/2014 11:48 PM, Per Bothner wrote:
> On 01/14/2014 02:34 PM, Remi Forax wrote:
>> We need new constant pool entries for arrays (like MSIL does), it's
>> currently possible to encode arrays as a String (by example by
>> uuencoding the values) but it's awkward.
>> Then a collection literal can be encoded using invokedynamic.
>> By example,
>>     int a = ...
>>     { 1, 2, a} as ArrayList (or any other syntax :)
>
>>
>> can be encoded like this:
>>     iload 'a'
>>     invokedynamic (int)ArrayList
>
> I don't understand your proposal - it's a bit too vague/incomplete for 
> me.

Ok, let me try again :)
There are two different parts when you have a collection literal,
one part is constant the other is dynamic.
by example with, { 1, 2, a },
   {1, 2, place_holder } is the static part. and a is the dynamic part.

The static part can be stored in the constant pool using a compact form.
The dynamic part has to be copied from the stack when creating the
data structure.

If a literal has no dynamic part, then the collection literal can be always
the same object if that object is immutable, so it can be seen by the JIT
as a true constant. That's why I think like Kevin that collection literal
should be immutable.

If a literal has a dynamic part, you can say that all bets are off,
and as you said use 3 methods, make_builder(), add() and build()
or you can say that you can always initialize a collection
from an array of constants, an array of indexes (a constant too)
that indicates where the holes are and at runtime the values
that comes from the stack.
The idea is that you can prepare the immutable data structure in
most of the cases (by example, if the keys of the map are constants)
and just insert the values where needed.

Now, you just have to link the different parts together and you can
use invokedynamic for that using a code similar to the code used
to initialize a lambda.

cheers,
Rémi