Static fields in specialized classes

[Vitaly Davidovich]

The issue is that since java doesn't reify generics, users know that
there's just one type.  My argument is that if there's reification, then
generic classes take on a different meaning (to me) -- they're just a
blueprint, and don't represent any concrete type (a program never actually
runs a generic type, only specializations, even if some bytecode/machine
code can be shared).  Once someone instantiates a generic with some type,
then to me that's a distinct type (i.e. Foo<String> and Foo<Integer> are
two different closed types, who happen to share the same generic
definition).  Also, once you allow declaring static fields of the generic
type, then it's a bit clearer that Foo<String> and Foo<Integer> are
distinct types and don't share the same static field, right? In that case,
it seems more natural to "unify" this and say that all static fields,
irrespective of their type, belong to the concrete type and not the generic
type.

I sympathize with trying to preserve backwards compatibility and designing
within the confines of an existing mature language.  However, it may be the
greater good to possibly break away from legacy and advance the language
with a forward-looking hat on, rather than dragging the historical elephant
behind forever.  It's a hard problem though ...


On Mon, Oct 13, 2014 at 6:38 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

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