Status of StrataCode features

Status of various StrataCode components based on current testing:

code-processor

frameworks

management ui:

intellij plugin:

Java to Javascript

The Java to Javascript converter is a healthy beta. Because most Java code depends on runtime libraries that may not be available, it's not a seamless way to run any Java code in the browser. The test suite contains over 100K lines of Java that's converted without workarounds, JDK classes added as needed. Currently it uses the Apache java utilities which support only Java 1.6. Java 1.8 Lambdas have been implemented in the code-gen by converting to inner classes, but that conversion has not been tested due to the missing libraries.

The converter uses a relatively high level of emulation of native Java classes to keep download size manageable. It's easy to replace any class with a native version using an annotation. Right now, the code is still readable and no optimizations to remove unused code so lots of future optimization potential even though performance is not bad.

Currently, your entire JS app is downloaded after the page is rendered but the layered organization would be a perfect way to separate subsets of layers to be progressively loaded. Just mark layers in your stack as 'download layers' and the rest could be automated. For large client applications, you'll be able to start interacting with the app with the base layers, while successive layers are downloaded. The static type system would help manage the dependencies to be sure each individual stack defined a valid application and framework hooks installed to help provide a smooth transition from one to the next.

Futures

These are a few ideas for how StrataCode might evolve:

It will dispatch requests to the right process and coordinate the update of the child processes in a distributed system. The router will leverage both code-gen to generate fixed assets for 'static typed' routing configuration, and dynamic layers for reloading and on-the-fly updates to cluster config. During the build process, it can use the entire the layer stack to build the system routing map: all processes, URLs, apis, requests, etc and which process handles which ones, along with security constraints. Plugins will allow it to parse out session ids, or whatever it needs. It will generate the config and code necessary to do the dispatch, compile and run sub-processes, oversee remote installs, deploy updates, start/stop servers etc. The goal is that scalability is just a set of layers added on to the stack. For a new install, these layers can guide the initial config and deployment and build the management UIs required to update and maintain it. From one declarative assembly of processes and APIs, we can support both HTTP and message style dispatch and easily switch back and forth.