Re: RFR 8009517: Disable fatal compiler warning in the old build
On 21/03/2013 22:12, Brad Wetmore wrote: : The codereview is here: http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any objections, please speak now. No objection here but just to mention that since you need to set NEWBUILD=false then it might not be too much extra to also set JAVAC_WARNINGS_FATAL=false. In any case, I think it would be desirable if there was a retirement date set for the old build so that the remaining users (I assume very few at this point) have something to aim for. -Alan.
Re: RFR 8009517: Disable fatal compiler warning in the old build
On 3/22/2013 1:34 AM, Alan Bateman wrote: On 21/03/2013 22:12, Brad Wetmore wrote: : The codereview is here: http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any objections, please speak now. No objection here but just to mention that since you need to set NEWBUILD=false then it might not be too much extra to also set JAVAC_WARNINGS_FATAL=false. At least for me, I'm not using the new build environment at all. (I think RE is doing the same when building the JCE jar files): % cd jdk/make % make381 all That is, NEWBUILD doesn't exist in this build hierarchy. As for adding JAVAC_WARNINGS_FATAL=false, I thought we were keeping warnings fatal here to so that folks running builds in this environment can the developers know they are introducing warnings/crud into their code? In any case, I think it would be desirable if there was a retirement date set for the old build so that the remaining users (I assume very few at this point) have something to aim for. Erik is now more aware of our JCE build problems, so hopefully we won't be far behind. I was surprised to hear deploy still has the dependency. Brad
Re: RFR 8009517: Disable fatal compiler warning in the old build
David, Plugin's integration next week is now also impacted since they also have to use the old build environment, so it's time to resolve this. So here's an update/proposal/webrev. The original bug filed by David Katleman was: 8009517: build-infra: jdk8: -Werror not being applied to nio builds and I filed: 8010434: Old build environment no longer builds. I've closed mine, and will integrate against the former. In my partial (JDK) build using the old mechanism and the current TL JDK/langtools gate, only two changes are now necessary. I propose we disable -deprecation in jdk/makejavax/others, and -overrides in make/com/sun/org/apache/xml. The first *LIKELY* crept in due to a recent change in the Base64 code which no longer implicitly compiles sun/misc/CharacterDecoder.java without -Werror active. The original deprecation issue needs to be addressed sometime by the responsible team, but that will avoid RE having to hand edit to the Makefiles just to build JCE. The second change is due to the compiler change with hashCode/equals. The codereview is here: http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any objections, please speak now. Brad On 3/18/2013 6:29 PM, Brad Wetmore wrote: Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... Your temporary solution, -overrides, is just that. It will enable the old build to complete today, but it could fail at any point in the future, as the code changes. Correct. As it stands today, a recent change now requires *BOTH* overrides/deprecation in order to get a complete MASTER build using the old build system. [brwetmor@flicker-vm1] 222 hg diff common/shared/Defs-java.gmk diff --git a/make/common/shared/Defs-java.gmk b/make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk +++ b/make/common/shared/Defs-java.gmk @@ -127,7 +127,7 @@ endif # TODO: Workaround for CR 7063027. Remove -path eventually. -JAVAC_LINT_OPTIONS += -Xlint:-path +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation JAVACFLAGS += $(JAVAC_LINT_OPTIONS) For example, java.net is currently warning free, in the old it compiles with fatal warnings enabled. Lets say, in a moment of madness, I add a dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or any class that produces warnings when compiled. I run the new build, all is fine. Push the changes. Now someone else sync's up, but need to build using the old build. If the new dependent class is not already compiled before java.net.Socket gets compiled, it will be compiled implicitly. It's warnings will cause the compile to fail, and the old build will fail. Or much simpler, anyone could write sloppy code with warnings, the new build will suppress them, and they won't notice. Push this code, and the old build will fail if is explicitly, or implicitly, compiles this code with -Werror enabled. Exactly. Our formerly clean code now requires disabling of two Lint options, but the new build is happy just to report the warning. The old build crashes on the warning. Our options for the old build system are: 1. disable the warning for overrides/deprecation, keep -Werror (my preferred since these are minor warnings.) 2. Somehow disable -Werror on these new directories that are now failing. (more work to figure out, but also acceptable) 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of deprecated code and/or add missing equals/hashcode that the recent javac changes exposed.) We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. I personally spent several weeks over the past number of years fixing warnings and reviewing warning cleanup webrevs from others. I took much pride in keeping certain areas warnings free. It is with great regret that I propose to disable fatal warnings in the old build, but I felt this the best/safest option. I heard much annoyance and frustration from others about hitting seemingly random errors with the old build recently. This is the only sure way to avoid that. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring. I'm ok with that, if others are. To clarify, I think you are suggesting that we keep the old build as it, with -overrides, and now ,-deprecation :( and use it periodically as a way of tracking new warnings
Re: RFR 8009517: Disable fatal compiler warning in the old build
This looks fine. Get it in before something else changes! Mike On Mar 21 2013, at 15:12 , Brad Wetmore wrote: David, Plugin's integration next week is now also impacted since they also have to use the old build environment, so it's time to resolve this. So here's an update/proposal/webrev. The original bug filed by David Katleman was: 8009517: build-infra: jdk8: -Werror not being applied to nio builds and I filed: 8010434: Old build environment no longer builds. I've closed mine, and will integrate against the former. In my partial (JDK) build using the old mechanism and the current TL JDK/langtools gate, only two changes are now necessary. I propose we disable -deprecation in jdk/makejavax/others, and -overrides in make/com/sun/org/apache/xml. The first *LIKELY* crept in due to a recent change in the Base64 code which no longer implicitly compiles sun/misc/CharacterDecoder.java without -Werror active. The original deprecation issue needs to be addressed sometime by the responsible team, but that will avoid RE having to hand edit to the Makefiles just to build JCE. The second change is due to the compiler change with hashCode/equals. The codereview is here: http://cr.openjdk.java.net/~wetmore/8009517/webrev.00/ I plan to push through the deploy gate, as they have an integration next week. Thomas Ng will do the push for us. Any objections, please speak now. Brad On 3/18/2013 6:29 PM, Brad Wetmore wrote: Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... Your temporary solution, -overrides, is just that. It will enable the old build to complete today, but it could fail at any point in the future, as the code changes. Correct. As it stands today, a recent change now requires *BOTH* overrides/deprecation in order to get a complete MASTER build using the old build system. [brwetmor@flicker-vm1] 222 hg diff common/shared/Defs-java.gmk diff --git a/make/common/shared/Defs-java.gmk b/make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk +++ b/make/common/shared/Defs-java.gmk @@ -127,7 +127,7 @@ endif # TODO: Workaround for CR 7063027. Remove -path eventually. -JAVAC_LINT_OPTIONS += -Xlint:-path +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation JAVACFLAGS += $(JAVAC_LINT_OPTIONS) For example, java.net is currently warning free, in the old it compiles with fatal warnings enabled. Lets say, in a moment of madness, I add a dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or any class that produces warnings when compiled. I run the new build, all is fine. Push the changes. Now someone else sync's up, but need to build using the old build. If the new dependent class is not already compiled before java.net.Socket gets compiled, it will be compiled implicitly. It's warnings will cause the compile to fail, and the old build will fail. Or much simpler, anyone could write sloppy code with warnings, the new build will suppress them, and they won't notice. Push this code, and the old build will fail if is explicitly, or implicitly, compiles this code with -Werror enabled. Exactly. Our formerly clean code now requires disabling of two Lint options, but the new build is happy just to report the warning. The old build crashes on the warning. Our options for the old build system are: 1. disable the warning for overrides/deprecation, keep -Werror (my preferred since these are minor warnings.) 2. Somehow disable -Werror on these new directories that are now failing. (more work to figure out, but also acceptable) 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of deprecated code and/or add missing equals/hashcode that the recent javac changes exposed.) We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. I personally spent several weeks over the past number of years fixing warnings and reviewing warning cleanup webrevs from others. I took much pride in keeping certain areas warnings free. It is with great regret that I propose to disable fatal warnings in the old build, but I felt this the best/safest option. I heard much annoyance and frustration from others about hitting seemingly random errors with the old build recently. This is the only sure way to avoid that. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring.
Re: RFR 8009517: Disable fatal compiler warning in the old build
Brad, I do not build using the old build anymore. This is clearly a blocker for your work. If you want to suppress the warnings for overrides/deprecation, then please push the change ( your patch ). We can revisit this in the future, when it is necessary. -Chris. On 03/19/2013 01:29 AM, Brad Wetmore wrote: Sorry for the delay in response, I've been pulled in yet another direction, and this has come back up in priority. On 3/9/2013 12:11 AM, Chris Hegarty wrote: I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... Your temporary solution, -overrides, is just that. It will enable the old build to complete today, but it could fail at any point in the future, as the code changes. Correct. As it stands today, a recent change now requires *BOTH* overrides/deprecation in order to get a complete MASTER build using the old build system. [brwetmor@flicker-vm1] 222 hg diff common/shared/Defs-java.gmk diff --git a/make/common/shared/Defs-java.gmk b/make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk +++ b/make/common/shared/Defs-java.gmk @@ -127,7 +127,7 @@ endif # TODO: Workaround for CR 7063027. Remove -path eventually. -JAVAC_LINT_OPTIONS += -Xlint:-path +JAVAC_LINT_OPTIONS += -Xlint:-path,-overrides,-deprecation JAVACFLAGS += $(JAVAC_LINT_OPTIONS) For example, java.net is currently warning free, in the old it compiles with fatal warnings enabled. Lets say, in a moment of madness, I add a dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or any class that produces warnings when compiled. I run the new build, all is fine. Push the changes. Now someone else sync's up, but need to build using the old build. If the new dependent class is not already compiled before java.net.Socket gets compiled, it will be compiled implicitly. It's warnings will cause the compile to fail, and the old build will fail. Or much simpler, anyone could write sloppy code with warnings, the new build will suppress them, and they won't notice. Push this code, and the old build will fail if is explicitly, or implicitly, compiles this code with -Werror enabled. Exactly. Our formerly clean code now requires disabling of two Lint options, but the new build is happy just to report the warning. The old build crashes on the warning. Our options for the old build system are: 1. disable the warning for overrides/deprecation, keep -Werror (my preferred since these are minor warnings.) 2. Somehow disable -Werror on these new directories that are now failing. (more work to figure out, but also acceptable) 3. Fix the warnings. (I don't have cycles to drive a rewrite of use of deprecated code and/or add missing equals/hashcode that the recent javac changes exposed.) We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. I personally spent several weeks over the past number of years fixing warnings and reviewing warning cleanup webrevs from others. I took much pride in keeping certain areas warnings free. It is with great regret that I propose to disable fatal warnings in the old build, but I felt this the best/safest option. I heard much annoyance and frustration from others about hitting seemingly random errors with the old build recently. This is the only sure way to avoid that. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring. I'm ok with that, if others are. To clarify, I think you are suggesting that we keep the old build as it, with -overrides, and now ,-deprecation :( and use it periodically as a way of tracking new warnings being introduced into areas that were warning free. That would be a side-effect, as someone would occasionally need to figure out what's changed. The main issue we're hitting right now is that RE has to make several source code changes in order to build JCE jar files without errors. I was able to change the individual LINT options globally and reduce it down to one change, but that's still one change that RE has to make. I feel that RE should not be making any changes, but that ship has already sailed and we're stuck with the results now. That is, if the old build fails because of a fatal warning, so be it. File a bug and fix the source code. Then the old build will work again. This means that at any point in time the old build cannot be guaranteed to be buildable. Everyone seems to agree, a solution needs to be found to allow us to keep certain areas warning free. This issue is too important, and too much time was spent, to allow it to regress to the state it was in a few years ago. It's already started. Brad
Re: RFR 8009517: Disable fatal compiler warning in the old build
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. /Erik 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? Mike 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. -Alan.
Re: RFR 8009517: Disable fatal compiler warning in the old build
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? /Erik 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. /Erik 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? Mike 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. -Alan.
Re: RFR 8009517: Disable fatal compiler warning in the old build
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 to have. 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. Others? -Chris. 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? /Erik 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. /Erik 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? Mike 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. -Alan.
Re: RFR 8009517: Disable fatal compiler warning in the old build
I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... Your temporary solution, -overrides, is just that. It will enable the old build to complete today, but it could fail at any point in the future, as the code changes. For example, java.net is currently warning free, in the old it compiles with fatal warnings enabled. Lets say, in a moment of madness, I add a dependency from java.net.Socket to say java.awt.RenderingHints.Key ( or any class that produces warnings when compiled. I run the new build, all is fine. Push the changes. Now someone else sync's up, but need to build using the old build. If the new dependent class is not already compiled before java.net.Socket gets compiled, it will be compiled implicitly. It's warnings will cause the compile to fail, and the old build will fail. Or much simpler, anyone could write sloppy code with warnings, the new build will suppress them, and they won't notice. Push this code, and the old build will fail if is explicitly, or implicitly, compiles this code with -Werror enabled. We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. I personally spent several weeks over the past number of years fixing warnings and reviewing warning cleanup webrevs from others. I took much pride in keeping certain areas warnings free. It is with great regret that I propose to disable fatal warnings in the old build, but I felt this the best/safest option. I heard much annoyance and frustration from others about hitting seemingly random errors with the old build recently. This is the only sure way to avoid that. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring. I'm ok with that, if others are. To clarify, I think you are suggesting that we keep the old build as it, with -overrides, and use it periodically as a way of tracking new warnings being introduced into areas that were warning free. That is, if the old build fails because of a fatal warning, so be it. File a bug and fix the source code. Then the old build will work again. This means that at any point in time the old build cannot be guaranteed to be buildable. Everyone seems to agree, a solution needs to be found to allow us to keep certain areas warning free. This issue is too important, and too much time was spent, to allow it to regress to the state it was in a few years ago. -Chris. (Ideally it would be nice to warn but not fail on just this one lint option, but don't see how that's possible.) Brad -Chris. Mike On Mar 8 2013, at 05:24 , Chris Hegarty wrote: Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 + +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 + @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris.
RFR 8009517: Disable fatal compiler warning in the old build
Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 + +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 + @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris.
Re: RFR 8009517: Disable fatal compiler warning in the old build
On 08/03/2013 13:24, Chris Hegarty wrote: Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 + +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 + @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris. This seems the most sensible thing to me as it is impossible to keep the old build warning working when warnings aren't fatal in the new build. -Alan.
Re: RFR 8009517: Disable fatal compiler warning in the old build
Looks fine to me. Do we have an issue open for restoring warnings to the new build? Mike On Mar 8 2013, at 05:24 , Chris Hegarty wrote: Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 + +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 + @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris.
Re: RFR 8009517: Disable fatal compiler warning in the old build
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? Mike 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. -Alan.
Re: RFR 8009517: Disable fatal compiler warning in the old build
On 08/03/2013 15:49, Mike Duigou wrote: Looks fine to me. Thanks Mike. Do we have an issue open for restoring warnings to the new build? Not yet, that I am aware of. We really need the ability to set lint options per package/subpackage. -Chris. Mike On Mar 8 2013, at 05:24 , Chris Hegarty wrote: Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 + +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 + @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris.
Re: RFR 8009517: Disable fatal compiler warning in the old build
On 08/03/2013 16:09, Mike Duigou wrote: : Understood. Perhaps we can at least use JDK_FILTER incrementally. Do we have a way to override the warnings used by the makefile? I haven't tried it but Erik suggested in a reply to Dan a few months ago, that is should be possible: http://mail.openjdk.java.net/pipermail/build-dev/2012-December/007427.html Any thoughts towards perhaps disabling -Werror but enabling all of the warnings? I think it would just annoy people and make it impossible to see the errors. We'll need to continue to make progress on the warnings and I think can only enable them when they are down to a manageable number, ideally 0. Stuart lead the last few campaigns and may have ideas or plans. -Alan
Re: RFR 8009517: Disable fatal compiler warning in the old build
I responded in another thread (wasn't aware of this one, sorry), there is an alternate to completely disabling -Werror. On 3/8/2013 7:58 AM, Chris Hegarty wrote: On 08/03/2013 15:49, Mike Duigou wrote: Looks fine to me. Thanks Mike. Do we have an issue open for restoring warnings to the new build? Not yet, that I am aware of. We really need the ability to set lint options per package/subpackage. That would be nice. I agree about warning creeping problems. This is a temporary solution, we should soon be fixing the underlying hashcode/equals problems...but... 1. javac tightened hashcode/equals checks 2. new: -Werror is off in the new builds. (i.e. not failing on any lint warnings) 3. old: -Werror is on for the old builds (i.e. is failing for any lint warnings) The proposal is to turn off all errors in the old builds (remove -Werror), essentially making 3 like the 2. Warn but not fatal. We spent a lot of time cleaning up many directories, seems a shame to start allowing non-fatal warnings to come back into previously clean code because people aren't taking the time to fix new warnings as they are introduced. My suggestion was to turn off just the one warning type in 3 *in the old code only* so we can at least continue to build the old without completely disabling -Werror. The new builds will still warn, but the old builds will still fail for all but these override problems. Yes, you lose the warnings in the old, but seems better than completely shutting off erroring. (Ideally it would be nice to warn but not fail on just this one lint option, but don't see how that's possible.) Brad -Chris. Mike On Mar 8 2013, at 05:24 , Chris Hegarty wrote: Since the new build does not enable -Werror when compiling any java code, and disables quite a few lint options, new changes my inadvertently introduce warnings without even realizing. This can cause problems when building with the old build as many areas do compile with -Werror set. Since the old build is on life support, probably best to just completely disable -Werror, so anyone still needing to use it can. diff -r 48b7295f02f8 make/common/shared/Defs-java.gmk --- a/make/common/shared/Defs-java.gmk Thu Mar 07 10:07:13 2013 + +++ b/make/common/shared/Defs-java.gmk Thu Mar 07 11:10:37 2013 + @@ -122,9 +122,10 @@ ifeq ($(JAVAC_MAX_WARNINGS), true) ifeq ($(JAVAC_MAX_WARNINGS), true) JAVAC_LINT_OPTIONS += -Xlint:all endif -ifeq ($(JAVAC_WARNINGS_FATAL), true) - JAVACFLAGS += -Werror -endif +# Disable fatal warnings, 8009517 +#ifeq ($(JAVAC_WARNINGS_FATAL), true) +# JAVACFLAGS += -Werror +#endif # TODO: Workaround for CR 7063027. Remove -path eventually. JAVAC_LINT_OPTIONS += -Xlint:-path -Chris.
