"Model 2" prototype status

[Brian Goetz]

Depends what you mean by out.  We are fully aware that this is a 
desirable and useful thing to be able to express, and intend to find a 
way to do so.  But we don't think that complicating the semantics of 
statics is necessarily the right way to get there.  It has been 
suggested (thanks Peter) that borrowing the "object" notion from Scala 
would be a far better way to achieve this (and other things) than to 
change the semantics of static, and I'm inclined to agree.

So the code below is probably "out" as written -- but that doesn't mean 
we've given up on solving the underlying problem.




On 8/7/2015 12:46 PM, Vitaly Davidovich wrote:
> I'd like to be able to express the following:
>
> class Foo<T> {
>      static final T _t = ...;
>      static final Foo<T> _ft = ...;
> }
>
> I guess that's out?
>
> On Fri, Aug 7, 2015 at 12:37 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     I don't see that there's any other sensible choice.  Asking users to
>     reason about the partially-heterogeneous translation (where some
>     instantiations share a class and some do not) in the context of an
>     existing language feature like static fields would be silly -- and
>     counterproductive.
>
>     (There are other places where the translation will necessarily
>     intrude; ideally, we want to keep those to reflective features,
>     those that cut across the language-level type system and the runtime
>     class system, such as class literals (Foo.class), instanceof,
>     casting, and reflection.)
>
>
>         I think keeping static fields per-class (in the sense of "the
>         class the user
>         wrote down in code", not "some random class artefact the runtime
>         happened to
>         emit") would be the most sensible and simple thing to do. No
>         explanation or
>         learning necessary, because everything works exactly like it has
>         the last 15
>         years in Java.
>
>
>