Static fields and specialization

[Vitaly Davidovich]

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

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