Optional CompileTime dependencies

[kenchis]

My motivation:
I create all versions like JS and WASM using TeaVM, which is a great deal.
My release version is at least about 3.5 MB big. JS and WASM_GC with nearly the same size, which is a great progress thanks to Alexey compared to the old WASM build (>7MB).
And this is not his fault but mine, that it has grown really big to include ereything.
The huge size is due to the fact, that I add 2MB precompiled PAL palette data, which in fact is only required, if video output is enabled using my emulator.
Some people using my release only want to play music without ever activating video screen output.

The Idea:
If compile time dependencies could be defined to be optional and separated from a release, gives more flexibility.
Compile time data and release version would be stored in different files.
At runtime one can decide to combine them to a full release or not by some glue code.
For the java code it would mean, that accessing that data must check the availability first.

The result would be a much smaller release for some people, around 1.5 MB max. And still 3.5 for the full functionality.
And I would provide just different file sets.

Possible problems are:
How to combine them together? Maybe optional data is always JavaScript code and can be imported and for WASM?
I really don't know yet what options we have here, therefore the discussion.
Or is it already possible?

[konsoletyper]

This highly depends on particular case and can be solved using various methods. I guess what you mean is just a resource file, right? Then why don't you just load and supply this file from within (i.e. from JS loader)? You can change your main class to be TeaVM JS module rather than standard Java entry point and you can expose two distinct methods to the outer world (one for setting PAL data, another for actual launching).

which is a great progress thanks to Alexey compared to the old WASM build

This has nothing to do with my efforts. Lack of objects as a first-class citizens in pre-GC WebAssembly did not allow to produce compact binaries, despite all possible efforts.

[kenchis]

Yes you are right, it is just a resource file. And the solution can be implemented individually in my project.
And if it is not a more general concern for other projects as well, there is no need for product support inside TeaVM.

Just thinking, if it is. It could support that case in a standard way. Creating several parts, that can be included at runtime or not.
TeaVM has already the CompileTime annotation and allows me to compute the resource file data.

This has nothing to do with my efforts. Lack of objects as a first-class citizens in pre-GC WebAssembly did not allow to produce compact binaries, despite all possible efforts.

Ah OK, so it was a technical limitation of the old WASM.

[konsoletyper]

Just thinking, if it is. It could support that case in a standard way. Creating several parts, that can be included at runtime or not.

Anyway, I don't understand what you mean. Can you describe what the problem is and what the solution could be?

[kenchis]

Current version:

Metadata is created like that:

@CompileTime
public class PaletteTeaVM {
	@Meta
	public static native Map<String, String> getPalette(boolean b);

	private static void getPalette(Value<Boolean> b) {
		...
		exit(() -> result.get());
	}
}

... and in Java accessed like that ...

Map<String, String> PALETTE = PaletteTeaVM.getPalette(false);

Maven build currently creates:
wasm/jsidplay2.wasm - binary containing palette and emulator combined

Proposal:

Metadata is created like that:

@CompileTime(optional=true, name="palette")
public class PaletteTeaVM {
	@Meta
	public static native Map<String, String> getPalette(boolean b);

	private static void getPalette(Value<Boolean> b) {
		...
		exit(() -> result.get());
	}
}

... and in Java accessed like that ...

Map<String, String> PALETTE = PaletteTeaVM.getPalette(false);
if (PALETTE == null) {
  // optional data is missing
} else {
  // optional data is available
}

Maven build could create:
wasm/palette.js - optional data
wasm/jsidplay2.wasm - binary containing emulator core

Glue Code (I don't know if it makes sense that way):

import palette.js
TeaVM.wasmGC.load(,,,, { palette=...})

[konsoletyper]

So basically what you want is code splitting? It's supported in GWT or in JS tools like webpack. It's quite difficult to implement, and the from user's prospective difficult to use, but I don't see any significant business value in this. It was relevant 10-15 year ago, but now it's not a problem to download extra 2mb even by mobile internet.

In your particular case storing this palette as binary data rather than generating code that fills in the map could perhaps save some space. Also, when we talking about 2mb, is it 2mb before gzipping?

[kenchis]

In your particular case storing this palette as binary data rather than generating code that fills in the map could perhaps save some space. Also, when we talking about 2mb, is it 2mb before gzipping?

In my particular case Its byte arrays stored as Base64 and int arrays stored as hex values. So, I could easily read this data in JS.
It was too time consuming to create it at runtime and therefore it is pre-generated. And yes, its uncompressed.

And the flexibility I wanted to have with splitting is to be able to replace that data later at runtime with different pre-generated palette data.

I don't see any significant business value in this

No problem, it's just a suggestion.

[konsoletyper]

And yes, its uncompressed

Did you try to compress it? Perhaps, sending it as a separate binary file would solve this, since HTTP supports gzip encoding out-of-the-box. Also, did you try to compare TeaVM-generated binary size after gzipping?