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