/j2cl-devmode-strawman

Experiments in building a "dev mode" for J2CL, incrementally building changed java files in a project with dependencies into a single unoptimized js file

Primary LanguageJava

Last modifications (ver. 0.3):
Class/methods have been split.
The **SingleCompiler** now actually executes a single compilation. It also contains the code required for that wrapped in different methods; a specific method
has been implemented to retrieve the list of files changed from a given time.
**ListeningCompiler** just starts a continuos loop to invoke a single compilation from **SingleCompiler** if some file has been changed.



Rough attempt at some build tools:

 * DevMode.main() - Java strawman for dev mode. Keeps the JVM hot between builds, dramatically improving the performance
 of J2CL versus running it from the command line, and leverages a PersistentInputStore for jscomp to avoid re-reading
 all JS from disk each time. It supports a jszip cache directory to precompile source jars to JS, and will soon have a
 matching bytecode cache as well.

The first two scripts assume that everyone loves maven, and that you plan to build the
https://github.com/vertispan/connected/tree/j2cl project, with just part of elemental2, and no other dependencies

Prerequisites:
 * Project that can be compiled in J2CL
 * .native.js in that project to either export symbols, or start the app. Running in BUNDLE mode is differently finicky, we're
 going to want to standardized this...
 * List of jszip and jar entries for their respective classpath. The java classpath list probably should contain the
 jre.jar, and the js classpath should probably contain the bootstrap.js.zip and jre.js.zip.



---

Build process, and assumptions:

Assuming:
 * No globally consistent version of j2cl (requires local cache clearing as needed)
   * No or partially distributed `.j2.zip`s (would require versioning by j2cl, re-releasing by entire ecosystem for any incremental release)
 * In contrast, preprocessor is _not_ expected to change (though the steps below don't currently leverage this)
 * Closure will continue to error on duplicate declared modules
 * External (not in jre.jar) "supersource" still matters (i.e. gwt will not accept any arbitrary emulation)
 * Dependencies which supersource themselves still are permitted to be used


Steps:
 * unpack all .js.zip that are provided (may be as little as jre.js.zip and bootstrap.js.zip)
 * precompile all source jar dependencies (possibly checking a cache and skipping some if up to date)
   * this includes preprocessing, since the preprocessor is tied to the compiler and may change
   * (not done today) javac those sources, so we have bytecode to speed up later j2cl calls which actually matches the js
     * note that annotation processors shouldn't be re-run, so we're processing those generated sources too
   * (FUTURE?) this also requires de-duping "self-supersourced" js classes, as j2cl doesn't allow dups
 * (not done today) unpack all upstream .js.zips to a single dir in order of java classpath (in order to allow
 "classpath hiding")
 * (not done today) discover, skip any types which are "self-supersourced" within the project
 * preprocess current sources - note that this happens _before_ running processor, as opposed to how it happens to dependencies
 * (if incremental, or if we don't assume already javac'd for apt) javac current sources
 * preprocess any generated sources? this isn't done yet, but would need to be in order to be more consistent with how
 we handle dependencies
 * transpile current sources and current generated sources to the same dir as dependency output
 * (missing) resolve properties, permutations
 * Run closure on all generated js, with entrypoint and `--define` statements
 * (missing) link permutations