Changed behaviour of Desktop.browse on Windows

[Christopher Schnick]

Edit: I meant the behaviour for *Desktop.browse* is now platform 
specific and the javadocs are wrong for it.

Furthermore, a good solution to solving this issue properly if security 
constraints disallow the normal Desktop.browse method to be used for 
arbitrary URLs, would be to add a new method to the Desktop class which 
supports this.

On 16/02/2026 22:38, Christopher Schnick wrote:
> There are plenty of applications on Windows that use URL schemes to 
> allow for a unified way of launching applications with some arguments. 
> In our main app, one application we call via Desktop.browse is the 
> Warp Terminal that requires URLs to be properly launched with 
> arguments with the warp:// scheme. Other apps we call in some internal 
> tools are GitHub Desktop with x-github-client:// and msteams with 
> msteams://. But there are plenty more of those URL schemes for all 
> kinds of applications out there, and someone is probably going to rely 
> on them.
>
> The URLs are manually constructed in the code, e.g. when the user 
> wants open a certain session to a system. The use case here is for AWT 
> as the FX desktop integration does not have all the features that AWT 
> has.
>
> Regardless of specific apps, the change in handling the file:// URLs 
> is also a problem. Before, in the code you didn't really need to care 
> whether a URL was of a specific type, Desktop.browse launched the 
> right application for any URL. Now, I have to check whether it is a 
> file URL and use the Desktop.open method instead with the URL path. 
> For other types of custom URLs, we resorted to manually calling new 
> ProcessBuilder("rundll32", "url.dll,FileProtocolHandler", url) on 
> Windows.
>
> The behaviour of Desktop.open is now also platform-specific as this 
> does not behave the same way on Linux or macOS. Technically, the 
> javadocs for Desktop.browse were already wrong, now they are still 
> wrong for the Linux/macOS behaviour.
>
> I also don't see the huge security issue with allowing applications to 
> open URLs how they like. If a JVM-based application opens a malicious 
> URL from user input without verifying it, the JVM shouldn't prevent 
> that as that is an application issue. You could block ProcessBuilder 
> from spawning arbitrary programs with the same reasoning if you go 
> down that route.
>
> On 16/02/2026 21:43, Philip Race wrote:
>> Can you explain specifically what you used this for and how you 
>> obtained the URL passed to the API,
>> and whether it was a user-initiated action ? The specific URL and 
>> scheme will help.
>> Also is your specific case FX or AWT ?
>>
>> If any of this is something you consider private/proprietary to your 
>> application, you can send me off-list if that works.
>>
>> I'm not promising anything, but it will help if we understand the use 
>> case in detail.
>>
>> -phil.
>>
>> On 2/12/26 9:55 AM, Christopher Schnick wrote:
>>> Does anyone have input on this? I had to revert all deployments I 
>>> made with JDK 25.0.2 back to JDK 25.0.1 due to it breaking various 
>>> different features that relied on opening URLs of specific 
>>> applications. The same will probably also apply to many other 
>>> applications out there.
>>>
>>> Is there a supported way in JDK 25.0.2 to open an URL with the 
>>> associated application instead of the web browser on Windows?
>>>
>>> On 10/02/2026 16:45, Christopher Schnick wrote:
>>>> Hello,
>>>>
>>>> We recently upgraded our application to JDK 25.0.2 and saw a 
>>>> changed behaviour in the Desktop.browse method when opening any 
>>>> non-http URLs on Windows. Previously, those URLs were opened with 
>>>> the default application associated with that URL scheme, now it 
>>>> always opens the URL in the web browser, even though it shouldn't 
>>>> really do that. Even stuff like file:// URLs are opened in the 
>>>> browser.
>>>>
>>>> I saw there were PRs for both the AWT and JavaFX implementation for 
>>>> opening URLs, but the related JBS issues are private. So I'm 
>>>> guessing some kind of security issue?
>>>>
>>>> Is this the expected behaviour now due to security constraints or 
>>>> is this a bug?
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
>>