Static fields in specialized classes

[Brian Goetz]

> Not quite. It is not possible to write code in Java 8 that still works
> in Java 10.

Here's an idea: let's hold off on the "it is not possible" claims until 
you've actually seen the whole story.

Addressing your concern, though, we do care deeply about migration 
compatibility; it was a huge goal of generics to allow codebases to 
generify gradually without requiring a flag day across maintenance 
domains.  (This is why we still have raw types.)  Gradual 
any-generification poses a similar requirement, and we will not ignore 
the situation of migrating old generic code that didn't know about 
any-generics.  (We have this very problem with our own Collections, 
which are full of leftovers from 5-migration-compatibility like 
removeAll(Collection<?>)).

> While a private closed code base can potentially make the
> change you propose when migrating to 10, an open source library can't.
> As an open source author, I need the code I publish to be equally
> usable across multiple Java versions. I can't write <any T> today, so
> it won't work as desired in 10. The "refactor and you're fine"
> argument doesn't work here.

Yeah, this is a problem with every nontrivial new language feature; 
that's pretty much independent of anything we've been discussing here.

The good news is that we're working on a separate initiative to ease 
this pain, which is felt by all libraries.  Historically the approach 
libraries have taken is a least-common-denominator one; this was 
generally OK because the platform had not been evolving all that fast, 
so 5 was a reasonable least-common-denominator for a while.  But now 
that things are actually evolving again, and people want to actually use 
the new features, this becomes important.  We see this with libraries 
that want to use lambdas as well, but also want to maintain a single 
binary artifact.  So, stay tuned.