RFR 8009517: Disable fatal compiler warning in the old build
chris.hegarty at oracle.com
Mon Mar 11 15:00:46 UTC 2013
Thank you for trying this Erik.
I did think of this "workaround" myself, but felt if might not be
acceptable due to the performance penalty. But this information is great
I wonder if we should try to get all alternatives/proposals on the
table, then make a decision. I know of two other possibilities.
1) Leave things are they are, and use another tool to investigate
warnings. From Jon.
2) Explore supporting Package level SuppressWarnings. Then apply
to the relevant packages, and enable -Werror in the build.
On 11/03/2013 14:20, Erik Joelsson wrote:
> I tried implementing a PoC for this. Without sjavac, it works, except
> that the first pass must be run without -Werror and the second with.
> Since we use -implicit:none, this is fine.
> With sjavac I had to let it compile the full set of classes first and
> then run a second time (into a different output directory) with just the
> warning free set of packages. The overhead on my machine was 5 seconds
> for the second pass. This solution also works without sjavac, but then
> the overhead is 37 seconds on my machine.
> Now the question is, do we want to pursue this or not?
> On 2013-03-11 10:30, Erik Joelsson wrote:
>> I have a suggestion for how to at least partly enable -Werror in the
>> new build. The penalty is slightly longer compile time, but the
>> difference should be negligible.
>> We split the big java compilation in jdk in two. The first pass with
>> -Werror and all warnings turned on, the second without. We make a list
>> of packages that are passing -Werror and use as include list for the
>> first and exclude list for the second. As you make more packages
>> warning free, we add them to the list.
>> This solution is not as fine grained as a per package configured set
>> of warning flags, but it's much better than we have today.
>> On 2013-03-08 16:56, Alan Bateman wrote:
>>> On 08/03/2013 15:49, Mike Duigou wrote:
>>>> Looks fine to me. Do we have an issue open for restoring warnings to
>>>> the new build?
>>> I don't know if there is an issue for that yet but as the new build
>>> compiles thousands of classes in a single compilation unit then it
>>> means we will need to make significant inroads on the warnings before
>>> more can be enabled. The approach with the old build was by area and
>>> good progress had been made but with the new build, then it may have
>>> to be by warning type as all areas are compiled together.
More information about the core-libs-dev