On Wed, 25 Jun 2025 07:03:33 GMT, Dmitry Kulikov <d...@openjdk.org> wrote:

>> Added an on-demand installation of the native OpenURL event handler to the 
>> `Application.setOpenURIHandler()`.
>> 
>> This does not break the specification for the affected API, since the 
>> requirement of the application being bundled and containing 
>> `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither 
>> launch nor send OpenURL events to an application that does not declare such 
>> capabilities it the bundle.
>> 
>> Running tests on macOS showed no regressions after this patch. Other 
>> platforms are not affected.
>
> Dmitry Kulikov has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Update copyright years

Let me try to understand this. 

[1] On startup, if it is a bundled application (per macOS rules) JDK will 
currently install a *native* handler,
even though [2] nothing in the Java code may actually be installed to handle it 
?
ie the startup code, does it "just in case" ...
[3] And unless the native handler is installed, macOS will never ask the app to 
handle the URL.

Now the Java app doesn't actually care about no native handler ie [3] unless it 
calls setOpenURIHandler(), unless macOS has some built-in default that might be 
useful - but I doubt that.

Once the Java app does call setOpenURIHandler() it would clearly like to have 
its handler called - although according to what you say - macOS will still only 
do that if it is a bundled app.

At this point if no native handler is installed by [1], your change will 
install it, so from then on macOS will - for a bundled app - start sending it 
messages.

What I am getting out of this is that 
(a) the installation of the native handler during startup is arguably pointless 
and we should always just install it when we know its needed - as in this change
(b) the checks that start up does are pointless
I'm guessing for "safety" you decided to leave those alone ?
But I'm not sure if these are really equivalent. 
I don't know how  [bundle _hasEAWTOverride:@"URLHandler"] is accounted for or 
whether it matters.
I am probably missing a key piece, but it seems to be an alternative way to get 
macOS to send messages,
but if that's the case, I don't know why it matters at all whether we check and 
whether Apple still support it.
Is there a possibility of a regression test here ? I'm guessing it would be 
might hardy but I've got to ask.

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

PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3033810216

Reply via email to