On Fri, 2 Feb 2024 19:47:17 GMT, Martin Fox <m...@openjdk.org> wrote:

>> Turning on warnings-as-errors for the macOS glass native code. Deprecated 
>> declarations are excluded and still appear as warnings.
>> 
>> In the code that tries to locate the application's dock icon there were 
>> three instances where `NO` was being passed into a method that required a 
>> pointer to a `BOOL`, not a `BOOL`. I suspect the intent was to check that 
>> the path pointed to an existing file but not a directory. Since JavaFX has 
>> gone this long without screening out directories correctly I decided not to 
>> fix that behavior except at the very end.
>> 
>> The only other changes of note are sending some NSNotification objects to 
>> delegate API's that require them even though we know they're ignored on the 
>> other side. It was the easiest way to get rid of the warning.
>
> Martin Fox has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Added OS version guard for NSApp activate call

> We're targeting a minimum macOS version of 11.0 but `[NSApp activate]` is 
> only available on 14.0 and above. Xcode 15 should issue a warning about this 
> but doesn't _if this is the only version warning in the file_.

Sigh. I'm not much a fan of how Apple handles runtime version checks, and this 
seems like one more indication of that.

> Adding an `@available` check around this is the right thing to do but not 
> enough to appease the pre-submit bot which is building with the 13.3 SDK.

Technically the `@available` check is redundant (the only place that 
`requiresActivation` is set to `YES` is already in an `@available` check), but 
I can see how the compiler wouldn't know that. Adding it around the use site 
seems fine; too bad it is insufficient.

> To clean this up either the bot needs to be upgraded

Definitely not. This matches our production build environment. We use Xcode 
14.3.1, which includes `MacOSX13.sdk`.

> or I need to add a localized pragma to disable this check.

So basically, a pragma to workaround a limitation of Xcode. This might be the 
best option if it isn't too ugly.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/687#issuecomment-1924693909

Reply via email to