Changed behaviour of Desktop.browse on Windows

[Christopher Schnick]

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
>>>
>