Divide manifold modules into manifold-xxx and manifold-xxx-rt #181
Labels
Comments
|
This issue is related to #77 |
|
work in progress... |
rsmckinney
added a commit
that referenced
this issue
May 20, 2020
- Toward smaller, faster, static Manifold runtime (and Android support). This is the first pass at dividing manifold modules into manifold-xxx and manifold-xxx-rt. Where, if using Manifold statically, declare a dependency on manifold-xxx with a compile-only scope and declare a dependency on manifold-xxx-rt with both compile and runtime scope. Note you can continue to use Manifold dynamically (resource classes compile and load dynamically at runtime) because manifold-xxx modules declare a dependency on their manifold-xxx-rt counterparts i.e., you don't need to separate dependencies because in dynamic mode all of manifold is there at runtime too. - Since Android's runtime does not provide classes in the `javax.script` package, replaced usage of `javax.script.Bindings` and `javax.script.ParseException` with Manifold versions `manifold.rt.api.Bindings` and `manifold.rt.api.ScriptException`. - A lot of breaking API changes are involved, mostly around moving classes from manifold.xxx to manifold.xxx.rt. These changes are necessary due to Java's JPMS prohibiting package splitting between modules. - Removed `IJsonFormatTypeResolver` in favor of a new runtime-friendly interface `IJsonFormatTypeCoercer`. This was necessary to maintain sharing of JSON format type resolvers with GraphQL.
This was referenced Jun 2, 2020
rsmckinney
added a commit
that referenced
this issue
Jun 9, 2020
|
available in release 2020.1.13 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Divide manifold modules into
manifold-xxxandmanifold-xxx-rtThis division is based on pure static use of manifold especially to support use cases such as Android where dynamic manifold features will not work. As such a
manifold-xxxmodule defines compile-time-only classes and, therefore, has a dependency onmanifold-xxx-rt, where the rt module defines classes necessary for runtime execution. These classes are void of type manifold compilation etc. Only classes executed from manifold-generated code during a project's compilation shall reside in an rt module.This change also enables support for Kotlin and other JVM languages. For instance, Manifold resources such as GraphQL and JSON can be placed in a separate Java module where the types are provided statically to a Kotlin module. Using this technique, the development experience advantages of the Manifold plugin for IntelliJ also apply to Kotlin projects.
Accordingly, a module using manifold statically, such as with an Android or Kotlin project, should declare a compile-only dependency on
manifold-xxxand a normal dependency onmanifold-xxx-rt.Note several manifold modules will not have to be split this way, only the core module and modules having type manifolds such as
manifold-json,manifold-graphql, etc. will be split. Still, some modules having a type manifold don't have any runtime specific to the type manifold -- the code they generate is self sufficient, thus you declare a compile-only dependency on them.In all, the static runtime footprint of Manifold will be significantly reduced, at least 10x smaller given most of manifold core is specific to compilation. Additionally, many submodules, such as manifold-graphql, use libraries for parsing etc. Some of these libraries will be excluded from runtime.
Startup performance will also be significantly improved. Since Manifold's on-demand dynamic compilation is not needed for a static project; all the initialization necessary to bootstrap Manifold is no longer required. Thus, initialization time will be reduced to ZERO.
The text was updated successfully, but these errors were encountered: