Make the API not filesystem dependent

[Thihup]

Currently, the API uses the java.io.File, making it harder to use for example with a remote JAR without having to persist it on the disk to transform or use as a Java agent.

Would this be possible or there are some major issues with the all in-memory approach?

[ropalka]

Hello @Thihup .

Quick recap:

The Batavia project represents just a facade API with main purpose to hide transformation engine implementation details.
The typical use case is like this:

User ----- uses -----> Facade API ----- delegates -----> transformation engine implementation

At the moment we have three backends:

• ASM based transformation engine
• Eclipse transformation engine (default one used e.g. in WildFly)
• No dependencies based transformation engine

Questions:

Did you consider to use Eclipse transformer directly (see: https://projects.eclipse.org/proposals/eclipse-transformer )?
Or you have an interest to use this Facade API ?
If you want to use this Facade API, what is your proposal to replace java.io.File with?

[Thihup]

Hi! Thanks for the complete answer.

I'll try to explain better. At Piranha, we are trying to do the Jakarta to Javax conversion in the first place and the near future the Javax to Jakarta. However, one of our implementations is all in-memory and would be better if we don't use the java.io.File to do the conversion.

I have tried using the Eclipse Transformer too but it requires the file to be on the filesystem. So I've found the No dependencies based transformation engine and it looked pretty good to me. However, I couldn't use it because we can only access the API.

So, I was thinking about what would be the best replacement for the java.io.File. I guess the most trivial would be using the java.nio.Path, because it allows to add an In-Memory Filesystem and to not break compatibility we can easily convert from File to Path. Using byte[] or InputStream would be better for me, though.

Another approach we would try can be using the transformation as a Java agent, but I didn't really dig into it yet.

[ropalka]

Hi @Thihup

So, I was thinking about what would be the best replacement for the java.io.File. I guess the most trivial would be using the java.nio.Path, because it allows to add an In-Memory Filesystem and to not break compatibility we can easily convert from File to Path. Using byte[] or InputStream would be better for me, though.

Since Batavia facade API needs to support Eclipse transformer (our default engine) and as you properly pointed out Eclipse transformer requires access to the filesystem the only proposal that would be acceptable is java.io.File -> java.nio.Path
API change.