"Model 2" prototype status

[Vitaly Davidovich]

I agree that I don't consider it a goof up either.  The generic type is a
recipe/template, and specialization should create its own state.  If that's
an issue, then create a base non-generic class and move static fields you
don't want to replicate there.

sent from my phone
On Aug 5, 2015 7:55 AM, "Timo Kinnunen" <timo.kinnunen at gmail.com> wrote:

> Hi,
>
> What is the goof-up? I can see duplication of static members having
> several benefits. Off the top of my head:
>
> 1) It makes it possible to implement a statically type-safe
> Collections.emptyList().
> 2) Adding language support for type-safe generic constants becomes a
> relatively small addition.
> 3) It means specializations can have the same lifetimes as their consumers
> have, meaning they can live within the caller’s classloader rather than
> being associated with some global registry.
>
> That last point means more opportunities for class unloading, for
> instance. It also prevents a whole category of bugs -- those triggered when
> the order classes are loaded changes invisibly -- from arising for
> specialized types or methods or fields.
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
> *From:* Simon Ochsenreither <simon at ochsenreither.de>
> *Sent:* ‎Wednesday‎, ‎August‎ ‎5‎, ‎2015 ‎12‎:‎43
> *To:* Vitaly Davidovich <vitalyd at gmail.com>
> *Cc:* valhalla-dev at openjdk.java.net
>
> But at least IDE support can help in the case of mutable structs, while the
> duplicated-static-members goof-up is "by design" and can never be fixed
> anymore.
> I would consider that issue to be much worse.
> (We are planning to to this in the JVM, right?)
>