[crac] RFR: Move more FD tracking to java layer [v4]

[Radim Vansa]

On Mon, 12 Jun 2023 13:45:26 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> The existing claiminig code in the RandomFileAccess does nothing in the current code state, as FileInputStream manages its own FileDescriptor. Reverting FileReader in the test would require a new implementation in FileInputStream and extending the test, as that does not cover FileInputStream created with fd. So test was not adequate to the implementation, but now it is. FileReader/FileInputStream are better to be done separately, without bloating this PR.

I can't parse what you're trying to say. The test was never about RandomFileAccess. The purpose was to validate that if a FD is left open:
- some exception is thrown from checkpoint
- this exception has sufficient information to help the user identify the cause (file path)

Both the past and new implementation are sufficient to accomplish this, the reduction of specificity from CheckpointOpenFileException to CheckpointOpenResourceException is acceptable.

> Yes, this is a design. Repeating code is abstracted into utillity classes, e.g. JDKFileResrouce, but a more specific File class can implement something different compared to the default.

This is highly impractical, and introduces more space for errors, hunting down unhandled cases. I don't oppose having extra information through claiming ownership on resources, but the for the policies it means that we'll need to invent new ways to obtain necessary info for every higher-level resource, as opposed for just 2 platforms (POSIX and Windows).

> but anyway should not be handled by FileDescriptor

It should not be handled at all in the ideal case, and it does not need to be handled by FileDescriptor at all, when the information is read straight from OS. This is introducing significant complexity for no clear gains.

-------------

PR Comment: https://git.openjdk.org/crac/pull/79#issuecomment-1587505879