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

List:       openjdk-openjfx-dev
Subject:    Re: Cleaning up warnings in the Mac glass code
From:       Martin Fox <martin () martinfox ! com>
Date:       2021-11-30 20:18:01
Message-ID: 9BBE23C4-B913-454C-AF47-A5C1150B1E59 () martinfox ! com
[Download RAW message or body]

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?

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. 

> 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]