Static fields in specialized classes

[Maurizio Cimadamore]

Interesting discussion, although I wonder how much we are being biased 
by how the current implementation works; let's imagine a world where 
type specialization is not needed - we can have a single 
erased/templating format that suits all parameterizations (of course 
you'd need an expressive enough instruction set) - if that's the case, 
you'll have a single *class *generating multiple *types* with no need 
for specialization. Would that change the perception of statics when it 
come to generic classes?

The key thing about generics is that they change the relation between 
classes and types in a fundamental way - before JDK 5 for each class 
you'd get one type (1:1). After JDK 5, one class can be instantiated to 
multiple parameterized types (1:N). In the Java language, the word 
'static' is typically used to denote 'class'-wide properties. Think 
about locks - locking on a static field F means locking on the class 
instance representing the class defining F. I think the meaning of 
programs should be preserved as much as possible before/after 
reification; it might seem that, as primitive/values in generics were 
never allowed before, we have more freedom here - but we must think 
about reference types in the back of our head: do we really want to 
change the meaning of programs accessing static fields on Foo<String> 
vs. Foo<Integer> ?

Maurizio

On 13/10/14 20:20, Vitaly Davidovich wrote:
> Sure, I don't dismiss the historical aspect of this.  However, I don't
> necessarily think this should be a barrier if generics were to be reified
> or specialization introduced.  In that case, people should become aware of
> what's happening with their static fields, and once they do, I don't think
> they'll find it unintuitive given the new context.  I think it's intuitive
> to think of generic types (in a specialized/reified world) as
> recipes/templates/"super macros" for concrete instantiations, and given
> that, it makes sense (to me, at least) that the static fields are
> replicated across the actual instantiations.
>
> On Mon, Oct 13, 2014 at 3:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>
>> As a user, I would *not* expect that there's just one fooCount field for
>>> all Foo<T> instances.
>>>
>> Except that's how generics have worked in Java since 2004.  Do you propose
>> that existing generic code with statics should change how it behaves?  Or
>> are you suggesting that the existing behavior is also counterintuitive?
>>