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 objecti
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 her
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
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
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, Bra
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.
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 ot
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 o
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
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
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 th
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
On Mar 8 2013, at 07: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
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 He
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 s
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
>
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 are
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
18 matches
Mail list logo
