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

Sat Feb 14 02:05:36 UTC 2015

Hi Joe,

I have been putting together steps to be able enable both C++ and Java
build warnings when build OpenJDK9, with the help of the link you provided
below and other resources I have managed to get the Java and  C++ warnings
to appear with one of the methods but not with the other.

Here's the two methods I have resorted to

1) using Make command and tried the below two make commands:

$ make clean JAVAC_WARNINGS="-Xlint:all,deprecation,rawtypes,unchecked
-Xmaxwarns 10000" DISABLE_WARNINGS="-Xlint:all" LOG=debug images

or

$ make clean JAVAC_WARNINGS="-Xlint:all -Xmaxwarns 10000"
DISABLE_WARNINGS="-Xlint:all" LOG=debug images

In *debug* mode I get to see the warnings but not in *info* or *warn*
modes. Also which of the above two methods are recommended ?

2) using JavaLintSummary

$ java -cp
[path-friday-stats]/dist/lib/javacLintSummary.jar:$JAVA8_HOME/lib/tools.jar
\

javacLintSummary.Main -Xlint:all \

-html report -Xdoclint \

jdk/src/**/*.java

.
.
.
Analyzing 8415 files
Exception in thread "main" com.sun.tools.javac.util.ClientCodeException:
java.lang.NullPointerException
at
com.sun.tools.javac.api.ClientCodeWrapper$WrappedDiagnosticListener.report(ClientCodeWrapper.java:597)
at com.sun.tools.javac.util.Log.writeDiagnostic(Log.java:616)
at
com.sun.tools.javac.util.Log$DefaultDiagnosticHandler.report(Log.java:591)
at com.sun.tools.javac.util.Log.report(Log.java:562)
at
com.sun.tools.javac.util.AbstractLog.mandatoryWarning(AbstractLog.java:199)
at
com.sun.tools.javac.util.MandatoryWarningHandler.logMandatoryWarning(MandatoryWarningHandler.java:255)
.
.
.

$ java -cp
[path-friday-stats]/dist/lib/javacLintSummary.jar:$JAVA8_HOME/lib/tools.jar
\ javacLintSummary.Main -Xlint:all -html report -Xdoclint \
com.sun

Lint Report
No warnings found
Analyzing 0 files

The above only worked when individual files were passed but if I passed in
a folder or package name, it would either return no warnings or throw
exceptions (attached stacktrace). And the html report it generates would
have "No warnings found" in it.

I must be doing something wrong with the second approach - could you please
throw some light.

Cheers,
Mani
PS: I also found a minor issue in the documentation and will send along a
contribution later on.

On Sun, Jan 25, 2015 at 10:55 PM, joe darcy <joe.darcy at oracle.com> wrote:

> 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
>>>
>>>
>

-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2015:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*