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 > >
