Draft JEP for discussion: Lint and doclint clean sources

Joe Darcy joe.darcy at oracle.com
Wed May 28 18:33:57 UTC 2014


Hi Martijn,

On 05/28/2014 10:19 AM, Martijn Verburg wrote:
> Looks good Joe,
>
> One quick Q:  In your guide you talk about "Avoid introducing source 
> incompatibilities 
> <http://cr.openjdk.java.net/%7Edarcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#source_compatibility>". 
>  Is there a possibility that adding Generics in order to fix a linting 
> problem would break this guideline?
>

(Basically) not if it is done right :-)

At the API level, the warnings come from raw types. So if the same 
approaches that were used by libraries when they were first generified 
are followed on this remainder, we shouldn't have any more problems than 
were had when the platform was first generified.

A feature of Java's erasure based generics is that libraries can be 
generified before their clients, but there are a few cases were a source 
compatibility can arise. Let's say a method was declared to return a raw 
list:

     List foo() {...}

and a client assigned it it a variable of type List<String>:

     List<String> myStringList = foo();

but in actually foo *really* returns a List<Number>. If the declaration 
is updated accordingly,

     List<Number> foo() {...}

then

     List<String> myStringList = foo();

won't compile any more. However, it is generally preferable for this 
kind of problem to be found at compile time than to suffer a 
ClassCastException at runtime. If the client anticipated the proper 
generification of foo,

         List<Number> myNumberList = foo();

then it would be fine with the change in foo.

Most of the cases I think still need to be generified are raw Class 
types. These are most often changed to Class<?>, which doesn't impose 
any type constraints and this thus very source compatible.

HTH,

-Joe


More information about the jdk9-dev mailing list