And then there were none: -Xlint:all enabled int the build of JDK 9 jdk repo

[joe darcy]

PS I've written up a blog entry with some more detailed advice about 
clearing javac lint warnings:

     https://blogs.oracle.com/darcy/entry/warnings_removal_advice

Cheers,

-Joe

On 1/21/2015 4:59 PM, huizhe wang wrote:
> Thanks Joe for the guidance!  I'll give it to shot as soon as I have 
> time. I need to kick start some planned works first so that they can 
> get into people's busy schedule.
>
> Hope it's "easy" to fix :-) Also, as you referred to JDK 5, time to 
> move the jaxp code base to beyond JDK 1.4 that the upstream source 
> still supports, a bit inconvenient for future update, but maybe not 
> much so.
>
> Cheers,
> Joe
>
> On 1/21/2015 3:24 PM, joe darcy wrote:
>> Hi Joe,
>>
>> On 1/21/2015 1:46 PM, huizhe wang wrote:
>>> Hi Joe,
>>>
>>> Lance reminded me to see this email thread. Looks like jaxp made it 
>>> to top 3, a plenty of warnings cleanup work indeed :-)
>>
>> Plenty of warnings, but each one is generally very easy to fix :-)
>>
>> Some comments / guidance on the different warning categories:
>>
>> [cast]: These are redundant casts. Since they are in method bodies 
>> and checked by javac they are safe and easy to remove, an essentially 
>> zero-risk change.
>>
>> [fallthrough]: Indicates a switch has a fall-through condition. If 
>> such a code path is not intentional, it can be a serious bug. All 
>> such cases should be examined for correctness.
>>
>> [static]: Accessing a static member through an instance variable. 
>> Misleading code that should be corrected.
>>
>> [dep-ann]: When @Deprecated annotations aren't properly paired with 
>> @deprecated javadoc tags; should be fixed.
>>
>> [serial]: A serializable class without a serialVersionUID defined, 
>> often a problem for the serialization contract we maintain the in 
>> JDK. The fix is usually just to add a serialVersionUID set to the 
>> serialver of the already-shipped version of the class. Extra care 
>> must be taken of the class has actually evolved over different releases.
>>
>> [deprecation]: Use of deprecated code. If a rigorous examination is 
>> not possible, the warning should at least able to be successfully 
>> suppressed now in JDK 9.
>>
>> [rawtypes] & [unchecked] Symptomatic of incomplete generification of 
>> APIs. Generics shipped in 2004 with JDK 5; Java code today should be 
>> generics aware!
>>
>> I'd be happy to advise and code review warnings fixes in jaxp, jaxws, 
>> and corba.
>>
>> Thanks,
>>
>> -Joe
>>