Static fields and specialization

[Peter Levart]

On 01/13/2015 03:29 PM, Vitaly Davidovich wrote:
> Why not just keep the existing static init block? If you have a static
> generic field, I think that field should have the same T as the enclosing
> class, and not some other T (i.e. it's not like generic methods that can
> take arbitrary  type parameters).

Huh, so you would propagate type variable from instance scope to static 
context. So you could write the following:

public class Holder<any T> {

     static final List<T> specializedField;
     static final int normalField;

     static {
         specializedField = new SomeList<T>();
         ...
         normalField = specializedField.size();
     }


...see where this is going to? You cant "split" the single static 
initializer block into meaningful parts.


Peter

>
> Sent from my phone
> On Jan 13, 2015 3:32 AM, "Peter Levart" <peter.levart at gmail.com> wrote:
>
>> On 01/12/2015 05:11 PM, Brian Goetz wrote:
>>
>>> You probably misunderstood me (again) :(
>>>> Richard suggested that you can keep speed of Optional.empty() by
>>>> creating separate layers for <ref T>, <int T>, etc...
>>>>
>>> Remember, for value types (hopefully Optional will be one), instantiation
>>> is essentially free, and in most cases where this idiom is used, it is the
>>> allocation that we're trying to optimize away.  So the idiom of "cache one
>>> and return the same instance", in these cases, can be retired.
>>>
>>> I realize this still doesn't help us for reference types, like
>>> Collections.emptyList(); this point got made a while ago (so it didn't
>>> occur to me we were still talking about it.)
>>>
>>>
>>>
>> Hi,
>>
>> "generic" or "specialized" static fields are a concept I have been
>> thinking of too, but their initialization presents a lot of challenges and
>> consequently possible irregularities in language. The example we 1st
>> imagine is of course the following:
>>
>> On 01/12/2015 01:51 PM, Palo Marton wrote:
>>
>>> private static final <any T> Optional<T> EMPTY = new Optional<T>();
>>>
>>> This will compile initializing expression to generic static method:
>>>
>>> private static <any T> Optional<T> EMPTY$init() {
>>>      return  new Optional<T>();
>>> }
>>>
>>>
>> ...but we know that classic static fields can be initialized in
>> hand-crafted static initializers too:
>>
>> static final int x;
>> static {
>>      ...
>>      x = ...
>> }
>>
>> So the next logical thing we consider is "generic" or "specialized" static
>> initialization blocks:
>>
>> On 01/12/2015 02:26 PM, MacGregor, Duncan (GE Energy Management) wrote:
>>
>>> That sounds fundamentally okay, but probably also requires a typed static
>>> initialiser syntax for fields that could throw an exception during
>>> initialisation.
>>>
>>> Something like
>>>
>>> static final <any T> MethodHandle mh;
>>>
>>> static <any T> {
>>>          try {
>>>                  // Do MethodHandle lookup
>>>          } (catch e) {
>>>                  Throw new Error();
>>>          }
>>> }
>>>
>> ...but we can argue that above syntax is unsound. Currently there's no
>> construct in Java language that would associate two lexicaly independent
>> scopes together just by the name of generic type variable. Above two "any
>> Ts" are distinct type variables. So we might need a top-level static scope
>> that would allow declaring anything - from static fields to static
>> initializer blocks and/or static methods.
>>
>> We already have all that. Just remove the word "static" - it's the class!
>> So what Java might need is singleton objects (similar to Scala's):
>>
>> public object Singleton<any T> {
>>
>>      final T specializedValue;
>>
>>      Singleton() {
>>          ...
>>          specializedValue = ...
>>      }
>> }
>>
>> Before you argue that such specializedValue can not be constant,
>> hold-back...
>>
>> The @java.lang.invoke.Stable annotation has shown that VM already has
>> support for constant-folding such final instance fields. Voila, here's the
>> syntax to make this functionality "public".
>>
>> Serialization can be extended to support such singleton objects in a
>> special way (like enums), reflection can be special-cased for such classes
>> (don't allow setting final instance fields), so @Stable attribute can be
>> apppied to them...
>>
>>
>> Regards, Peter
>>
>>