Frequently Asked Questions

How does StrataCode integrate with other software programs?

StrataCode leverages standard Java patterns like Java Beans to layer on top of existing Java projects. It's possible to annotate even compiled classes to to customize the generated code when those classes are used. To support the object keyword, change the object template to make the appropriate API call to add the child to the parent.

StrataCode's core infrastructure is based on a flexible parser/formatter that makes it easy to read and incrementally update any format, from simple data files to full languages like Java or JS.

It becomes the ultimate integration engine when combined with the synchronization library. Whereas most integrations use somewhat disconnected import and export operations, this model allows change propagation and incremental updates between formats and across processes and databases.

Use layers of code, files, and data to buffer changes, implement workflow for review, and approval or auditing. Use layers to model the overlap between systems, for better code sharing and an abstraction that models that entire system for better automation of the full lifecycle of the system.

By supporting the entire lifecycle from build, test, deploy, update of a multi-process system it's possible to greatly simplify the tool chain required to build and manage a system.

Use the management UI framework to support a unified set of management UIs that track application features, enabled layer-by-layer for a finer-grained way to deploy customizable systems.

How does StrataCode speed development times?

There are several ways StrataCode speeds development. First of all, it offers high level, readable, code and configuration based on Java syntax that's transformed before running. Developers can do more with less code. By making code more declarative, it's easier for others to make changes. Jeff's experience helped him choose the patterns he has observed make for the most solid, efficient applications. StrataCode avoids software patterns that make code harder to read, and that create untraceable code paths.

Secondly, StrataCode eliminates the need to replicate your domain model's logic throughout the application. For each property in your domain model, most frameworks and platforms require you to replicate the logic behind that property several times, once for each layer in your system. With StrataCode, you specify the properties and domain logic that goes with just once. If you need more control, you annotate those properties with layers and get precise control over how the framework treats those properties. When there's only one copy of your domain model, you can change it rapidly as your business requirements change.

Thirdly, StrataCode offers live programming with code-patching in a client/server environment. This lets you build applications incrementally, and make changes without length recompile and restart sequences. Customization, plugins and other features are built in - available as needed by simply supporting modifications to existing APIs. Plugins can extend both end-user UIs and management UIs.

Why are layers better than just plain inheritance?

Of course lots of times object inheritance is what the design requires, but other times it's better to modify an existing type. It's fairly common to find this pattern implemented in adhoc ways like mixins to existing classes, use of dynamic languages, plugin frameworks but these approaches do not preserve the traceability that comes with inheritance and statically typed languages.

When you use inheritance, e.g. "A extends B" you always create a new type name, in this case "A". Because inheritance is our only way to refine a component, creating a new type is design-wise expensive. It's generally a bad idea to create lots of classes, one per feature as it can make code more verbose, harder to read and manage. A layer however can group multiple related and interdependent refinements with a single name. The layer may represent a feature, or an aspect of behavior like user-interface, persistence. It helps you break up large files and navigate code. It's easy to merge them for viewing and debugging when they are used judisciously and according to well defined boundaries. One great rule of thumb is to create new layers to separate out major dependencies. All database aspects of a given class are in one layer, the mobile UI in a second, the web UI in a third.

Compared to dependency injection, layers reduce the number of class names, use a single name space rather than separate ones for components and types, and delay the decision as to when code should be configuration or vide versa. With layers, there's less planning up front and flexible changes that preserve compatibility.

Layers provide a more powerful and flexible, in-language mechanism for customization. One name-space, statically-typed references - find-usages, refactoring all work reliably just as in Java. You can change things and customize things without refactoring and without breaking compatibility. They work at compile time and/or at runtime depending on how you configure them. There's one integrated language model for seamless tooling - where the program can edit the program in a nice contained sandbox.

And when you don't want to use layers to modify types, they act just like modules. You can only use layers to make your build system more powerful.

The ability to modify types is not unique to layers. Some languages support mixins, extension points, delta oriented programing, or dynamic languages like Javascript let you modify anything at any time. When you let any piece of code modify any other piece of code, it makes tooling and tracing the origin of the code more difficult. Layers give you the right flexibility with the right structure to make code modifications maintainable, even as the code base grows large.

What would make a good pilot project?

A Java based platform that needs a faster, more efficient management UI and customization framework, or SaaS platform looking to build a management UI that's highly customizable. Really it's appropriate for anyone building Java/Javascript applications and who is intrigued by layers. Or just use it as a build, customization, deployment tool. If you need to process Java code, or build a new parser or IDE, you might find StrataCode has the right APIs. We have some cycles to do custom platform development for you, or you might want access to the code to improve it yourself. You'd like to invest and benefit from what StrataCode potential for building a better software engine.

What about IOS?

There are a number of robust Java translators and UI frameworks out there that could be developed quickly but we don't have any prototypes yet.

What about Python, .NET, Php and more languages?

It's very feasible to convert StrataCode, Java, and really any supported language to any other supported language. It could be useful in a heterogenous Java/.NET system given that layers can tease apart platform dependencies and synchronize overlapping parts. Converting the code is a much smaller problem than converting all of the APIs and made easier with Parselets. Using layers, it's then possible to tease apart platform independent pieces of a code base that can be converted to another language. These classes typically make up the domain and view models for your system - the parts shared by multiple processes, and so convertable from one to the next. Perhaps it's just the class names and properties with validation logic that's shared.

Open source?

We don't yet have financial support to test that strategy, or the confidence there's a developer base that's large enough. Maybe a crowd funding campaign would make sense to solve this problem? In the meantime, get in touch with Jeff for access to the source. If there's a good use, we'll make it affordable for you long term as long as you only need to redistribute applications in binary form.

We'd love to find a way to compensate all developers who contribute to StrataCode's success. One vision for StrataCode is a marketplace of layers where we track major developer contributions, and manage subscriptions and payments for software run in the cloud or on-prem in source form.