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 <mar...@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
