Idea how to implement VT/VO compatibility in JVM

[Vitaly Davidovich]

But value types (and reified generics) are a fundamental change to the
language - even if compiler allowed compiling this stuff, things will break
if you call code that never expected value types - they have fundamentally
different behavior.  Do you want things to *just* compile or to also have
some sense that they'll work? Haven't you ever made breaking changes to
your libs for the betterment of it in the long term?

Also, if you expose ? methods to the users, can you not add new ones taking
any T and deprecate the old ones? If this reflection stuff is internal to
the framework/lib, then user just has to upgrade the JDK.  Can you give a
concrete example where any of this would be too burdensome?

sent from my phone
On Jan 22, 2015 9:49 AM, "Stephen Colebourne" <scolebourne at joda.org> wrote:

> On 22 January 2015 at 14:14, Maurizio Cimadamore
> <maurizio.cimadamore at oracle.com> wrote:
> > I think both Stephane (and you) and Vitaly have a point; such dynamic
> > frameworks have two alternatives:
> >
> > * keep working the way they do now - which implies List<val T> is
> related to
> > List<?>/List
> > * let them be generified, and then use reflection (on steroids) to let
> the
> > right thing happen at runtime
>
> Most frameworks are OSS and will be coded to work today on JDK 8 (or
> 9, assuming value types are in 10). Saying that those frameworks
> should use reflection on steroids is a non-option. You cannot write a
> library today (or in 9) that will work in 10. This would force each
> OSS library to release a dedicated version for 10, effectively asking
> each project to have a pre-10 version and a post-10 version. This is a
> terrible incompatibility in the eco-system, with huge knock-on effects
> for years (such as jar-hell).
>
> So, yes I *really* think if those are the only two options, then it
> must be option 1, relating List<value> to List<?>.
>
> Stephen
>