Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java 9 / JigSaw? #14

Open
BrunoEberhard opened this issue Jan 18, 2018 · 5 comments
Open

Java 9 / JigSaw? #14

BrunoEberhard opened this issue Jan 18, 2018 · 5 comments

Comments

@BrunoEberhard
Copy link

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

@reportmill
Copy link

reportmill commented Jan 18, 2018 via email

@alexp-sssup
Copy link
Member

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
Copy link

neuronsupport commented Feb 25, 2018

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
Copy link
Member

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
Copy link

pip25 commented Mar 13, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants