Static fields in specialized classes
brian.goetz at oracle.com
Thu Oct 16 00:11:51 UTC 2014
> 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
> 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.
More information about the valhalla-dev