Thanks. I wasn’t sure how an internal “clean up the code” bug would fare coming
through the public bug reporting portal.
> On Nov 30, 2021, at 12:33 PM, Kevin Rushforth
> wrote:
>
> https://bugs.openjdk.java.net/browse/JDK-8278021
>
> -- Kevin
>
> On 11/30/2021 12:24 PM, Kevin Rushforth
https://bugs.openjdk.java.net/browse/JDK-8278021
-- Kevin
On 11/30/2021 12:24 PM, Kevin Rushforth wrote:
On 11/30/2021 12:18 PM, Martin Fox wrote:
I can set this up to exclude deprecation warnings. When I turn on
warnings-as-errors and exclude deprecations there are only a handful
of
On 11/30/2021 12:18 PM, Martin Fox wrote:
I can set this up to exclude deprecation warnings. When I turn on
warnings-as-errors and exclude deprecations there are only a handful of changes
needed in glass. I think they could be handled in a single pull request. I’ll
need an issue number;
I can set this up to exclude deprecation warnings. When I turn on
warnings-as-errors and exclude deprecations there are only a handful of changes
needed in glass. I think they could be handled in a single pull request. I’ll
need an issue number; will I be able to enter a bug for this through
I agree that this would be a good thing to aim for as long as we exclude
deprecation warnings (given Apple's penchant for deprecating large API
surfaces such as OpenGL or the older accessibility APIs we really can't
have the use of deprecated APIs be an error).
-- Kevin
On 11/24/2021 7:44
That's a good idea. In general, warnings should always be treated as errors.
On Thu, Nov 25, 2021 at 2:01 AM Martin Fox wrote:
>
> The Mac glass code generates a lot of compiler warnings. I tried cleaning
> this up and discovered that two of the warnings are brand new, courtesy of
> me. One
The Mac glass code generates a lot of compiler warnings. I tried cleaning this
up and discovered that two of the warnings are brand new, courtesy of me. One
of the headers in PR #651 has a typo that I didn’t catch and neither did the
two reviewers. The compiler generated two warnings but they
