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