Architecture & Core Concepts

The Intuitive DSL Engine (iDSL) is engineered to bring database-grade rigor to modern Java command interfaces. Unlike traditional solutions, it prioritizes a deterministic and lightweight model, ensuring maximum security without sacrificing performance.

1. The "Zero Code Generation" Paradigm

Most grammar parsers (such as ANTLR or JavaCC) rely on generating thousands of lines of complex source code that must be compiled and maintained.

iDSL takes the opposite approach: the grammar is compiled once, at application startup, into an immutable Symbol Graph (AST) residing in memory.

  • Rapid Deployment: No external .g4 files or additional compilation cycles required.
  • Simplified Maintenance: The grammar is defined "inline" directly within the @DslCommand annotation.

2. AST Structure (Sealed Hierarchy)

The syntax tree is built using Sealed Interfaces introduced in Java 17. This architecture allows the AstNavigator to use Pattern Matching to traverse nodes exhaustively and safely.

public sealed interface SyntaxNode permits
        KeywordNode,
        ParameterNode,
        DelimiterNode,
        GroupNode,
        AlternativeNode,
        MacroNode {
    boolean isRepeatable();
}

Each node in this graph is an immutable record, making the AST natively thread-safe and ready for high-concurrency environments.

3. Injection via MethodHandles (GraalVM Friendly)

To bind values extracted from input to your Java class fields, iDSL avoids standard reflection (java.lang.reflect), which is often slow and problematic for native compilation.

The DslBinder resolves and caches MethodHandles during command registration.

Hardened Architecture: Using MethodHandles allows data injection performance close to native code while guaranteeing full compatibility with GraalVM Native Image (AOT).

4. Command Lifecycle

The engine operates with a strict distinction between two phases to ensure near-zero parsing latency at runtime:

  • Initialization Phase: The GrammarCompiler transforms the iBNF syntax into a graph, and the DslBinder pre-caches injection targets.
  • Execution Phase: The Lexer segments the input, the AstNavigator validates the path within the graph, and the DslBinder injects converted types before invoking the run() method.

Next Steps

Learn how to secure your interfaces against malicious input in our guide on the Zero-Injection Promise.