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

[David Alayachew]

By all means, try your luck. I only suggest to provide an alternative path.

As a minor correction though, the primary purpose of this mailing list (and
this thread, by extension) is to give feedback on existing features,
including their pain points. If someone suggests an API change in response
to a pain point, it is, in fact, the goal of this thread to evaluate those
ideas, and suggest alternatives if the proposed idea doesn't appear to be
the best fit. It may not have been your intention when making this thread,
but that is how this mailing list works.

Try not to take this response or my original one as a complete dismissal of
your idea. It's simply me giving feedback on how well your idea meets
certain needs.

I feel like there are better alternatives, but I don't think your idea is
bad. I bring all of this up because I have been involved in this community
for about 5 years now, and I've seen ideas like yours (in fact, your idea
exactly! Now that I think about it...) get rejected for the reasons I
stated, and more.


On Sun, Mar 16, 2025, 5:18 AM Markus KARG <markus at headcrashing.eu> wrote:

> 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/c9874630/attachment.htm>