Static fields and specialization

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 13 15:12:21 UTC 2015


I don't consider generic type param as being instance scope (or any scope
for that matter).  In your Holder example, the effect would be that each
specialization of the class would have its own normalField static member.
The upside here is this doesn't require any special handling of static
generic fields and is intuitive (to me at least).

Sent from my phone
On Jan 13, 2015 10:00 AM, "Peter Levart" <peter.levart at gmail.com> wrote:

> 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
>>>
>>>
>>>
>


More information about the valhalla-dev mailing list