Java 25 File API changes could break uses of File.exitsts()

[uckelman]

Java 25 changed the behavior of some methods in the File class, not because of a bug, but to align them with the behavior of some other file APIs, rather than taking the responsible approach of adding methods which have the new behavior.

Code using File can now behave differently depending on whether it's running on Java 25 or some earlier version.

This is a great example of how bankrupt Oracle's stewardship of Java has been.

We worked around this in Vassal 3.7.20:

vassalengine/vassal#14427

vassalengine/vassal#14433

As VASL has some calls to File.exists(), you might also want to address this.

[derimmer]

Thanks for this, Joel.

To All: having looked at the two Vassal PR, I think I need some guidance on this before proceeding, as it does not seem to be just a simple cut-and-paste solution.

I did a search for instances of .exists() in my local dev project and it came back with 13 results:

Do we need to address all of these or do we only need to worry about those explicitly referencing File objects?

Given the range of different solutions applied in Vassal, including some that continue to use f.exists(), how do we determine what to do in each VASL instance. To be honest, I could not discern a pattern in the Vassal changes, although I am sure it exists.

@zgrose ? @geezer09 ?

[uckelman]

Do we need to address all of these or do we only need to worry about those explicitly referencing File objects?

Yes. Every single one of those is a File object.

The problem is that File.exists() returns true for empty strings in Java 25, and you might (entirely reasonably) have been relying on that to return false like it always had.

If you want a test that behaves like pre-Java 25 f.exists() for all versions, then you'd need to do !f.getPath().isEmpty() && f.exists().

[zgrose]

In at least one of those examples (BoardBuilder), you're just exchanging one error message for another.
@derimmer I can take this item since I can read the intent of the code and there's only 13 entries.
If only Java had extension methods. :)

[zgrose]

@derimmer give this branch a peek. I inlined the class name to cut down on the diffs you need to look at. Probably merge that into whatever you're active in and see if everything is behaving.

https://github.com/vasl-developers/vasl/tree/bugfix/file-exists-rework

[derimmer]

OK, I have looked at this and while it all looks neat and tidy to me, using the new class to handle all the actual changes, I can't tell more than that.

I would certainly be willing to merge your changes into my local dev environment and test it but how best to do that? After 10 years using GitHub I still manage to screw things up royally!

I have a branch on GitHub called 672b3. This branch is checked out on my local device. So when I want to commit local changes to github, I push them to 672b3 on GitHub and then pull them into develop.

In the case of your changes, should I pull them into 672b3 from bugfix/file-exists-rework, and then merge them into my local dev project using IntelliJ? Is there a better way? Your branch is missing commits that I have pushed to 672b3 and then pulled into dev. Will those commits get overwritten if I pull your branch into 672b3?

[zgrose]

Merge my branch into your local dev. That should get all the updates over.
Then you just keep doing what you always do.

[zgrose]

Your branch is missing commits that I have pushed to 672b3 and then pulled into dev. Will those commits get overwritten if I pull your branch into 672b3?

When you merge commits, it will take what's changed in file A and apply that to file A, it doesn't replace your A with my A. That's why it's called a merge. If git can't figure out how to merge files, it will halt the process and put up a merge conflict that you have to manually resolve.

You should be able to "inject" my changes right into your branch unless you happened to make changes to the same files in the same places.

[derimmer]

that is what I have always understood. But I had a nasty surprise recently when it didn't work that way so I appreciate the confirmation that in should.

In my ealier case, I suspect there were a lot more changes in the incoming project than I realized and tons of stuff ended up in merge conflicts that I could not sensibly resolve. So I am being cautious. But I will proceed as you say.

[zgrose]

If you use the GitHub UI, it should tell you up front if it thinks you can merge automatically or not before you even do it. Super handy.

[derimmer]

Successfully merged your branch into my current dev project. Built the project, ran the .vmod and opened a game. So far so good.

I will watch for any problems as I continue my dev work. If all good I will push the changes to dev and get them into 672beta4.

@uckelman thanks for flagging this.

[derimmer]

these changes have worked fine in my dev environment. I have now pushed them from my dev environment into develop and they will be added to the 672beta4 build that I hope to create this week.