[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: [External] : Re: Cleaning up warnings in the Mac glass code
From:       Martin Fox <martin () martinfox ! com>
Date:       2021-11-30 21:18:53
Message-ID: 647AD121-1022-475A-8394-A0A6DB97E164 () martinfox ! com
[Download RAW message or body]

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 <kevin.rushforth@oracle.com> wrote:
> 
> 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 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 the public \
> > > portal?
> > 
> > You could create a bug using https://bugreport.java.com/ but in this case I'll \
> > create it for you. 
> > > I don't want to hide deprecation warnings entirely since they do sometimes flag \
> > > issues worth investigating (one is now on my to-do list). It's still a lot of \
> > > warnings so it's probably worth coming up with a strategy for reducing them \
> > > over time.
> > 
> > As long as all of the other warnings are errors, this seems good to me.
> > 
> > -- Kevin
> > 
> > > > On Nov 29, 2021, at 10:10 AM, Kevin Rushforth <kevin.rushforth@oracle.com> \
> > > > wrote: 
> > > > 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 PM, Michael Strauß wrote:
> > > > > 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 <martin@martinfox.com> 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 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 were lost in the sea. 
> > > > > > I turned on warnings-as-errors for the Mac glass code and waded through \
> > > > > > the results. There are a couple of minor coding errors in addition to \
> > > > > > mine which should be cleaned up (like passing NO to a function that \
> > > > > > requires a non-null pointer). There's also a few deprecated calls across \
> > > > > > a small handful of files which have easy replacements and are probably \
> > > > > > worth fixing. 
> > > > > > Unfortunately Apple re-named a bunch of constants in 10.12 and deprecated \
> > > > > > the older forms (I think this was to rationalize the naming with Swift). \
> > > > > > These form the bulk of the warnings and affect multiple files. Not a fan \
> > > > > > of that sort of code churn but the alternative is to live with a slew of \
> > > > > > warnings forever. Apple is not going to un-deprecate those constants. 
> > > > > > You can see the changes I made in my github repository (beldenfox/jfx) in \
> > > > > > the branch ‘macwarnings'. There's multiple commits, the first and \
> > > > > > biggest catching most of the easy stuff like constant renaming. 
> > > > > > In the short term it might be worth disabling deprecation warnings and \
> > > > > > turning on warnings-as-errors. Then at least outright coding errors (like \
> > > > > > mine!) have a chance of being caught. 
> > > > > > 
> > > > > > 
> > > > > > 
> > > 
> > 
> 


[prev in list] [next in list] [prev in thread] [next in thread]