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