Static fields and specialization

[Peter Levart]

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