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