Java 9 / JigSaw?

[BrunoEberhard]

Does cheerpj support Java 9 especially JigSaw? Would be nice to reduce the needed runtime.

[reportmill]

I’ve also wondered about this. Apparently there’s a tool in Java9 called jlink that builds minimal runtime jars. I’ve also wondered whether there would be any benefit to using webpack to turn the initial downloads for any given app into a single .js file, to potentially get slightly better compression. Having all the files broken up seems like it gives the browser the opportunity to download things in parallel - but when I watch the network tab, it shows everything loaded one-by-one. It would be interesting to hear thoughts on what optimizations are possible in the short and long term. jeff

…

On Jan 18, 2018, at 4:57 AM, Bruno Eberhard ***@***.***> wrote: Does cheerpj support Java 9 especially JigSaw? Would be nice to reduce the needed runtime. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#14>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJP8StlqZipwi5ZYnPZQ0pE0mu0orcBEks5tLyOsgaJpZM4RivXx>.

[alexp-sssup]

Java 9, including JigSaw, will be supported down the line. There is no definite plan yet due to little customer demand so far.

To an extent, CheerpJ already implements a solution to split the runtime into multiple packages which can be independently downloaded as required. CheerpJ could even download just the needed classes 1-by-1 in principle, but that is not a good idea due to network latency. There is an inherent tradeoff between execution pauses to download needed packages and minimizing download size and we think the current solution strikes a good balance. Moreover the packages are distributed by CDN and cached at the HTTP level, so after the first execution, no additional download is usually required.

Parallel download cannot happen by default as it is not possible, in general, for the application to predict which packages are going to be required. Needed packages are downloaded on demand as their classes are used. In the future we plan to expose an API to let users specify a set of packages or classes that they want to preload.

[neuronsupport]

As oppose to splitting into pieces. Can we create a single JS file preferably compressed, or a webpack bundle? Our system requires in some use cases a single JS file to load. Can we also encapsulate native Javascript methods into the code in annotations (inline Javascript) so that we do not need to include an external Javascript file for native implementations?

[alexp-sssup]

The cheerpjfy.py tool, which is uses to convert a JAR file into a JAR.JS file, supports including native JS methods in the final output. See here for details: https://github.com/leaningtech/cheerpj-meta/wiki/Implementing-Java-native-methods-in-JS

About using a single JS, please refer to this other issue: #17.

[pip25]

Perhaps not everything is retrieved at once, but the runtime and especially the converted application code is still downloaded in huge chunks, a whole multi-megabyte JAR at a time, potentially containing hundreds of classes in libraries that the program will never use. Yet those classes still take up network bandwidth and slow everything down.

Preloading could help, but in my opinion only if the list of classes to preload is compiled into the JS code automatically (the converter already inspects the bytecode, so why not utilize that step to analyze the classes used?) and if some server side functionality can be implemented which provides these classes as bundles which contain nothing else (except maybe transitive class dependencies as an optimization). Of course, these bundles would have to be created at runtime, since the needed classes are impossible to predict. There would still be things like Class.forName calls that would require downloads in the middle of class code execution, but the performance benefits I feel would still be substantial.

EDIT: I found in the release notes of the latest beta that there should be a way to split converted JARs to several smaller files, but haven't been able to find any documentation on this. Where can I find some information about this feature?