Current implementation of FS in JS keeps everything in memory. In real world cases users may want to keep their files in persistent storage. Filesystem support in TeaVM already relies on interface, which has implementations (in-memory and WASI), so it's only a matter of providing extra implementations as well as a way to pass compiler the name of desired implementation (TeaVM properties can be used for example).
It's reasonable to have two additional implementations for JS BE:
Asynchronous, which keeps everything in memory, but eventually flushes in-memory changes into persistent storage (i.e. IndexedDB). This is necessary, since IndexedDB itself asynchronous and if we want to keep good performance by preventing turning Java methods into state machine, we can use this implementation. This implementation would also require that main method starts asynchronously to make sure that all data read from IndexedDB into memory.
Synchronous, which never keeps data in memory, and all reads/writes all data 'synchronously', from Java's standpoint.
Current implementation of FS in JS keeps everything in memory. In real world cases users may want to keep their files in persistent storage. Filesystem support in TeaVM already relies on interface, which has implementations (in-memory and WASI), so it's only a matter of providing extra implementations as well as a way to pass compiler the name of desired implementation (TeaVM properties can be used for example).
It's reasonable to have two additional implementations for JS BE:
mainmethod starts asynchronously to make sure that all data read from IndexedDB into memory.