Java: Add test for a JavacTool-based compiler that doesn't use standard JavaFileObjects

[smowton]

This tests the situation where a JavacTool-based compiler doesn't just refer to standard files on disk, but rather directly refers to source files in a JAR or other archive, or as in the case tested here, uses an in-memory file object backed by a buffer, not a file.

The Java agent previously couldn't deal with this, but should now read such files out as text and write them to a temporary directory before extracting them.

Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.

Files not reviewed (2)

• java/ql/integration-tests/java/javac-tool-custom-file/test.expected: Language not supported
• java/ql/integration-tests/java/javac-tool-custom-file/test.ql: Language not supported

Tip: Turn on automatic Copilot reviews for this repository to get quick feedback on every pull request. Learn more

[igfoo]

Should this get some kind of location based on https://nonesuch.imaginary/somedir/Main.java?

[smowton]

Currently the loc seen will be inside the db's scratch dir where the temporary is created. Almost necessarily the loc given by toURI or similar is going to be something vscode etc won't understand, like a jar-relative URI or the like; at least this location will be clickable, though considered outside the source-root. I haven't exposed it in this test because it isn't stable from test run to run (contains a temporary dirname).

I suggest we don't tackle this one at this juncture, since I'm not clear how we can give it a more useful location that makes sense to VSCode / another client, or the user.