On Fri, 7 Aug 2026 23:38:06 GMT, Sergey Bylokhov <[email protected]> wrote:
> Just an overall feedback about this and that old changes:
>
> 1. I wonder that the usage of standard dispatcher API from the OS was
> considered legacy way to open the urls. And a direct usage of any registered
> app as browser is better(isBrowseInsecureAllowed!!!).
>
> 2. The current and the patched versions of the code are actually
> contradicts the spec of the Desktop.browse(), which was mirror the
> "Runtime.exec()" as a wrapper for OS dispatcher.
>
>
> > ```
> > * Launches the default browser to display a {@code URI}.
> > * If the default browser is not able to handle the specified
> > * {@code URI}, the application registered for handling
> > * {@code URIs} of the specified type is invoked. The application
> > * is determined from the protocol and path of the {@code URI}, as
> > * defined by the {@code URI} class.
> > ```
>
> The change feels like changing "Runtime.exec()" to always run the path in
> browser.
I dont think it contradicts the spec..The implementation is that, by default,
the URI opens in a browser and if allowList is set and associated app exists,
then "the application registered for handling {@code URIs} of the specified
type is invoked" which still stands..
Desktop.browse() should be used, as it is meant to be, to open URI in browser.
It is not to be thought of another gateway to Runtime.exec() or ProcessBuilder
to launch executables arbitrarily.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32247#issuecomment-5364936247
