This section describes both the basics around importing existing Java code, and at a language level, the compatibility between StrataCode code and Java code.

Importing compiled Java libraries

StrataCode is designed to make it easy to work with large Java code bases. As a first step, you can simply import pre-compiled Java libraries and use them from StrataCode. You cannot modify these types using the modify operator, bind to property change events (unless the compiled code uses the Bind.sendEvent api through some hook you can register), or use other features with them that require that StrataCode generate the code for these types.

A layer definition file can append to the class path as needed to add compiled libraries to the system. These types are automatically treated as JavaBeans by StrataCode using the get/set pattern. You can attach metadata to individual classes using "annotation layers". This metadata can affect the compiled code which uses that type, e.g. turning any use of a class into a component automatically. You can mark properties as constant to eliminate data binding warnings and overhead listening for events on properties that do not change. You can add code templates to a type used for defining object instances or component definitions.

To automate installs and updates, StrataCode has a repository package management system. There are RepositoryManagers for git, http, and maven. During the runtime, these package managers can ensure all dependencies are met before loading the Java code and do any installation or updates necessary.

Compilation of Java and StrataCode

To use more StrataCode language features, you can also copy your source files into layers and have StrataCode pre-process them.

Each layer can contain a mix of Java and StrataCode files. For Java files, you can use either the '.java" extension or ".scj'. You should .scj when you'd like to use the StrataCode IntelliJ plugin for this file. StrataCode will translate all files to vanilla Java files before compiling. If your layer has Java files and you don't use any extensions, these files are passed through unmodified to the compilation phase. By default both .java and .scj files are processed as source files but it would be easy to configure it so .java files are copied without processing to save some overhead.
The only changes made to Java files are cosmetic - add a missing "package" tag from the layer's package, add a missing public or private modifier when you mark your layer as public or private, or certain annotations you use can still be processed in the generated code. When dealing with pure Java files, StrataCode will still maintain class dependencies, compiling only files required to ensure your .class files are always up to date. This makes it easy to incrementally add StrataCode to an existing Java project a file at a time, replacing Java's ant build tool.

Compatibility with Java

You can simply rename a .java file with the .sc suffix and it should continue to compile and most likely will work without any changes. StrataCode classes use and produce standard Java types. A few changes made in the conversion from StrataCode to Java though could change the behavior in some edge cases. The biggest change is that fields and references in StrataCode may be automatically converted to getX and setX methods using the JavaBean naming convention.. So if you rename a .java file to a .sc file, when it gets compiled the resulting .java file may be different. If you don't happen to use any of the modified features though, the generated .java file will be the same. Get/Set conversion is performed when you use data binding, or annotate a property with an annotation. When changes are made to a source file, they are incremental because of the parselets framework.

Another difference between StrataCode and Java is that in a Java interface, a non-static field is treated the same as if you added the static keyword. But in StrataCode an interface's non-static fields are treated as "instance fields", and automatically added to all implementing classes during code-preprocessing. It also adds getX and setX methods for that property to the interface and changes the code which references that field to a getX/setX call. It's a simple form of multiple inheritance but works great, especially with default methods.

If you do not want this behavior for a given interface, do not rename it to have the .sc suffix or add static/final modifiers.

There are a few other minor compatibility problems where Java code might not compile as StrataCode. With the object operator classes and instances are defined in the same name space. But Java allows types and variables to have the same names - the context always determines whether the language expects a type or a variable and can determine which to use based on the context. To remove the ambiguity that results, StrataCode will treat types and variables of the same name as an error unless the variable is of that type. So in StrataCode, if you have two classes named "foo" and "bar", this code compiles: "foo foo; bar bar;" but this code gives errors: "bar foo; foo bar;"