5 ms·

To others trying to use this demonstration: Be patient with the page, as it has to download quite a few JAR files in order to be ready to compile and run any te

by jerluc 10y ago

To others trying to use this demonstration: Be patient with the page, as it has to download quite a few JAR files in order to be ready to compile and run any test code. To verify that the javapoly is ready to run your code, open the web developer console and wait for it to say "Java Main started". Additionally, first-time compilation will also need to download additional JARs for the demo code to run. Generally speaking though, the compilation time is a good 5-10 seconds on my computer for the demo code, so be sure to not just spam the compile button like I did :) ---- Just a friendly note to the author of this page: The total download size of this page's underlying Java resources are much larger than I realized (maybe a collective 30-40MB). Given that I waited almost 5 minutes after clicking "Compile & Run!" for nothing to happen (because I had clicked it well before the runtime JARs had fully downloaded), I would suggest to at least add a progress bar or something to let users know when they can actually compile and run the demo code, in addition to some acknowledgement that the code is compiling. This is definitely an interesting project though.

jvilk 10y ago
Yeah, Doppio needs to download the entire JDK to run, since it's a full-featured JVM (JRE for running Java programs, JDK for javac so it can compile them). Compressed, it's ~30MB. The authors of this project can preload the JDK with a progress bar and stash it into IndexedDB, since Doppio's file system, BrowserFS, supports arbitrary backends [1]. [1] https://github.com/jvilk/browserfs https://github.com/jvilk/browserfs
- Touche 10y ago
  Why isn't http caching sufficient?
  - jvilk 10y ago
    If the authors compressed the JAR files into a single bundle, storing the data into a BrowserFS-created IndexedDB file system removes decompression/extraction overhead on subsequent visits. If they didn't.... then it might be sufficient, but I am not sure how well the browser cache handles large files! How long until it evicts them? Is there an upper bound on the size of cached items? etc.
    - sspiff 10y ago
      I am only familiar with Firefox, where the default is 43.75MiB, anything larger than that is not cached. There's a `browser.cache.disk.max_entry_size` setting that defaults to 51200 (50MiB), however the code also has an explicit override that no item larger than 1/8 of the total cache size (as dictated by `browser.cache.disk.capacity`, default 350MiB) is ever cached, hence the 43.75MiB limit. All these settings can be changed, obviously, but I suspect few people ever touch them. I assume other desktop browsers have similar default limits, while mobile browsers probably have a much lower threshold.
- stuaxo 10y ago
  Very nice :). Maybe the Jar could be split so that people don't load things they don't use ?

by jerluc 10y ago

jvilk 10y ago

Yeah, Doppio needs to download the entire JDK to run, since it's a full-featured JVM (JRE for running Java programs, JDK for javac so it can compile them). Compressed, it's ~30MB. The authors of this project can preload the JDK with a progress bar and stash it into IndexedDB, since Doppio's file system, BrowserFS, supports arbitrary backends [1]. [1] https://github.com/jvilk/browserfs https://github.com/jvilk/browserfs

Touche 10y ago
Why isn't http caching sufficient?
- jvilk 10y ago
  If the authors compressed the JAR files into a single bundle, storing the data into a BrowserFS-created IndexedDB file system removes decompression/extraction overhead on subsequent visits. If they didn't.... then it might be sufficient, but I am not sure how well the browser cache handles large files! How long until it evicts them? Is there an upper bound on the size of cached items? etc.
  - sspiff 10y ago
    I am only familiar with Firefox, where the default is 43.75MiB, anything larger than that is not cached. There's a `browser.cache.disk.max_entry_size` setting that defaults to 51200 (50MiB), however the code also has an explicit override that no item larger than 1/8 of the total cache size (as dictated by `browser.cache.disk.capacity`, default 350MiB) is ever cached, hence the 43.75MiB limit. All these settings can be changed, obviously, but I suspect few people ever touch them. I assume other desktop browsers have similar default limits, while mobile browsers probably have a much lower threshold.
stuaxo 10y ago
Very nice :). Maybe the Jar could be split so that people don't load things they don't use ?