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
