The standard library is the set of modules that ships inside the
Aussom interpreter. Every Aussom runtime - the CLI, Aussom Server,
Aussom-Script - has access to these modules out of the box. Some are
pulled in automatically; others you include when you need them.
Pulled in automatically. Every other module relies on it.
lang defines the built-in classes that wrap Aussom's primitive
types (Bool, Int, Double, string, list, map), the JSON
helper (json), the console (c), and the security manager
(secman).
You almost never include lang; explicitly. But every time you
write c.log(...), json.parse(...), or myList.add(...), you
are using it.
These modules ship with the interpreter and become available with a
single include.
System helpers - paths, environment, process info, and the
println / print shortcuts.
include sys;
c.log(sys.getCurrentPath());
sys.println("hello, system!");
Standard math functions and constants.
include math;
c.log(math.sqrt(2.0));
c.log(math.pi);
Inspect classes at runtime. Read class names, member definitions, and method signatures, including any annotations attached to them.
See the Annotations Guide for the most useful patterns.
include reflect;
cls = reflect.getClassDef("MyController");
for (methodName : cls.getMethods()) {
// ...
}
reflect is sometimes restricted by the security manager in
sandboxed environments. Some functions are gated; see the guide for
specifics.
A lightweight unit-test framework. Annotation-driven, with @Test,
@Before, and @After. Run a test file with aussom -t.
include aunit;
@Test(name = "math tests")
class mathTests {
@Test(name = "add positives")
public testAdd() {
test.expect(1 + 2, 3);
}
}
The modules in the previous section work in every runtime that ships Aussom. Beyond that, each runtime exposes its own extras: things that only make sense in that environment, or wrappers around APIs that only the host has access to.
The lists below are examples, not a complete catalog. The exact
set of modules a script can include depends on the runtime, the
host application, and the security manager configuration. Aussom
Base, in particular, ships only the universal modules listed
above - host applications choose which extra modules to expose. The
authoritative list is always the API reference for that product in
the sidebar.
The CLI is the broadest. A script run with the aussom command
typically has:
file - filesystem read, write, listing, and metadata.http - synchronous HTTP client.jdbc - relational database access.lucene - full-text search index.markdown - Markdown to HTML.xml, yaml - structured config and data parsers.firebase - Firebase Admin SDK access (auth, Firestore, FCM).sendgrid - email through SendGrid.ssh - shell out to remote hosts.Aussom Server has the same family of integration modules as the CLI, plus the server-specific surface for HTTP applications:
AppBase - the base class your routing class inherits from.Handlebars - server-side template rendering.The browser has a different mix - no filesystem or JDBC, but a DOM and a browser-flavored HTTP client:
Doc, Element, HNode and friends - the DOM.Http - a browser HTTP client with synchronous and async
variants (get, getAsync, post, postAsync, ...).thread - browser timers and microtask scheduling.html - HTML helper utilities.aussomBs - Bootstrap component wrappers.highlighter - syntax highlighting for displaying Aussom source
in a page.The language itself - syntax, types, classes, control flow - is identical across all runtimes. Only the surrounding modules differ.
include finds these modules.