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.rushfo...@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 <mar...@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.
