RFC: java.awt.Desktop methods should accept Path in addition to File

[Markus KARG]

Thank you, David. Understood your opinion.

In fact, it would be MY sole time and effort to add and maintain that 
Path-based API variants (not yours or anybody else's), so why NOT 
allowing me to do that? In this area, will do THAT or nothing at all, in 
fact. This thread is NOT about what to ask me for alternatively. So you 
finally chose NOTHING? Can't see the benefit of that for my or anybody 
else's community.

-Markus


Am 16.03.2025 um 04:02 schrieb David Alayachew:
> Hello Markus Karg,
>
> I spend a lot of my time making Swing apps. I can certainly relate to 
> the pain of your compatriots.
>
> Truthfully though, I don't see any significant benefit, other than 
> writing one less method per situation. A vast majority of my IO work 
> is already pretty specialized, so, while annoying, it's not really 
> something that I do so much of that this method would benefit me greatly.
>
> Essentially, I would like to avoid adding more to the API than there 
> already is, barring any fairly powerful new additions. I'd like to say 
> that Pattern-Matching will be an example of something that justifies 
> adding to the API.
>
> If it were me, I would actually turn it around and find situations 
> that are worth perturbing the API, then strongly suggest that those 
> new API's use Path, encouraging this since there is that little 
> translator method toFile(). Turn your opponent's argument against 
> them, basically lol.
>
> Granted, that's still not an easy task, but I suspect that you will 
> have momentum in your favor that way.
>
> On Sat, Mar 15, 2025, 2:26 PM Markus KARG <markus at headcrashing.eu> wrote:
>
>     Since Java 7 there is java.nio.file.Path as a modern alternative to
>     java.io.File. Many APIs in OpenJDK make use of Path already, but not
>     java.awt.Desktop. This forces authors of new desktop applications to
>     convert to File explicitly. While it is understood there are not
>     masses
>     of such applications newly authored, still there are some, and their
>     authors contacted me regarding this.
>
>     I would be happy to provide a PR which adds alternative signatures
>     allowing to pass Path directly. The change would be very small hence
>     quick to review, mostly cheap to maintain, and at most risk-free,
>     as it
>     simply internalizes code that otherwise would exist externally.
>
>     Comments appreciated!
>
>     Regards
>
>     -Markus Karg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20250316/5b9f2d03/attachment.htm>