Status of StrataCode features

Status of various StrataCode components based on current testing:

  • Note: we'd love your feedback on anything but particularly better names for things, missing features, api changes or suggestions for improvements or what license we should use for StrataCode, and the IntelliJ plugin.

Code-processor

All Java 9 language features should work in the .sc formats. The 'var' keyword is not yet supported. The scc command can be run with either Java 8 or Java 11 and generates apps using Java 8 class file format.

  • beta: parselets, java support, sc, sct, schtml formats
  • alpha: process-constraints, maven emulation, modelCache (may need to clear modelCache directory from time to time)
  • pre-alpha: incremental compilation (beyond using it to run an app with no file changes)

Dynamic runtime

Beta quality for basic Java features when all code is dynamic or when dynamic code sits on top of compiled code. No real effort has been made to test lambdas expressions and Java8+ features in dynamic mode.

Compiled classes extending dynamic ones are not supported. Some compile time references to dynamic classes are implemented by changing the field or method call during code processing.

Refreshing changes made to source code on the fly only works for simple cases like property changes, add field, add/remove class, and method changes.

Frameworks

  • beta: data binding, components, properties, sync, server tags, java-to-js web framework (let us know if it's missing a useful api!)
  • alpha/pre-alpha: cross-scope bindings for collaboration, web security, request scope, merging layers of schtml

Program editor

  • alpha support for existing features
  • missing 'find' page, delete, more refinement overall and more customizability

Intellij plugin:

  • beta except for: find-usages/refactoring (misses somes references across inherited types, and getX/setX mapping). Editing of layer definition files (often requires an IDE restart or flush caches), debugger sometimes breaks in generated code, messes up source mapping for some block transitions, and anonymous class breakpoints only work when setting in the generated code, editing of 'scr' files has some problems showing false errors.

Java code processing

The test suite for the parser and type-system validation is run against more than 1M lines of Java code from various open source projects, including one that heavily uses Lambdas. This aspect of the system has also been run in a commercial product on a number of commercial code bases. It does not detect all errors but does validate the type system mostly accurately. Some bugs with parameterized types missing errors.

Java to Javascript

The Java to Javascript converter is beta quality for Java 6 features. Many of the typically used JDK classes are supported (ArrayList, HashMap, LinkedHashMap etc.), more can be added as needed. The test suite contains over 200K lines of Java that runs in the browser. The Java utilities source are lightly modified copies of the Apache java classes from 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.

Anonymous classes that use variables from the enclosing method are not yet supported.

The converter uses a relatively high level of emulation of native Java classes to keep download size manageable. It's possible to replace a class with a native version using an annotation. Right now, the code is still readable and no optimizations to remove unused code, or write native JS in a condensed way so there is lots of future optimization potential, particularly for download size.

All number types in Java (int, float, Integer, etc) are converted to Javascript's single number type. A cast to an int type will insert a call to Math.floor, the most important features of BigDecimal are supported (requires the js.math layer) and it's possible to wrap those integers that really need to be integers but that works is not complete.

Currently, the entire JS app is downloaded after the init HTML is rendered. The layered organization would be a great 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.

DB framework

Alpha/Beta. This is the most recent framework integration. It has not been tested under load or at scale. There is a fairly complete store builder using the DB framework using relationships, schema-migration, transactions, caching, simple rule-based queries, and basic queries using a custom API. There are a few tests and one example of using stored procedures in the GeoIpInfo class used for mapping remote-ip address to a city database using a bit-mask indexed query.

More features are required for managing cache sizes and more testing needs to be done to ensure the transaction isolation works properly in multi-threaded environments.

Android

There's a prototype of an android framework that supported the unit converter and simple applications but has not been tested in a while. The android apis integrate very cleanly with the data binding system and so can be used with minimal wrapping code.

Get in touch if you'd like to use android and Jeff will update the framework to use an up-to-date version of the SDK.

Futures

These are a few future ideas we have for ways to leverage StrataCode and layers:

  • Complete the program editor: build an editor for HTML UIs from UI to form view and code view, new tag, new attribute, resize for fixed position elements, etc. Direct manipulation of UI controls - e.g. setting styles, alignment rules, etc. right from the widget.

  • Enhance the DB framework: add additional data sources and in-memory joins: efficient document/binary/column-oriented storage and secret store are the two that are needed for a complete implementation. Still need to finish the 'staging mode' implementation, where we generate a 'staging schema' that can be used to store changes made as part of a workflow. Those will be seamlessly merged into queries and other apis for testing purposes. This schema won't have the integrity constraints since it will be just a layer on top of the main database. More management UI integration, particularly with schema manager. Or maybe new properties are just marked as dyn columns so they go into the dynamic part of the tables? Need to add 'find panel' to the management UI based on the DB findBy features.

  • Framework layers for systems management: Add new framework layers to abstract system's management: setup of machine images, setup and management of virtual machines, deployment and update of code. The idea is to wrap existing tools with one system that supports a universal layered configuration. This will remove the overlaps and gaps that existing when these systems are configured and managed without a single unified configuration system based on 'systems feature layers'. This will help us build systems in a way that keep application code and deployment features separate but still have a unified set of admin and management interfaces to deal with each custom system.