Programming model¶
J7M lets an application expose ordinary Java interfaces, exchange typed values and references, and delegate distributed execution to explicitly installed middleware capabilities. Use annotations to describe the application contract; use host configuration to decide which capabilities are available and authorized.
The distinction matters. @DurableJob describes a job entry, but a trusted host still supplies its execution backend. @ServiceRef requests a binding, but the host still supplies discovery and authorization. This keeps application code compact without hiding operational decisions.
| Your task | Read next |
|---|---|
| Publish an interface and obtain a usable reference | Services and references |
| Construct components with explicit ownership | Dependency injection |
| Start, admit, drain and stop an application | Lifecycle |
| Read configuration or current caller context | Configuration and context |
| Define safe data contracts and JPMS adapters | Schemas and modules |
| Understand asynchronous calls and physical completion | Invocation semantics |
| Consume bounded remote streams | Remote streams |
| Schedule local asynchronous work and multi-target calls | Workload API |
| Choose candidates and reduce remote-call overhead | Selection and performance |
| Append and replay local durable records | Durable log |
| Use local durable CAS, leases and membership | Local coordination |
| Relate requests, callers and application activations | Contexts and identities |
| Implement and evaluate a resource adapter | Adapter SPI and TCK |
| Assemble JPMS modules and providers | Module dependencies |
| Choose an application architecture | Distributed patterns |
The examples use Java 25. Code fragments show the relevant application contract; complete executable examples and their verification commands are collected in Verified examples.
Two complementary entry points¶
Explicit APIs are useful for embedding J7M, assembling a trusted host and controlling resource ownership directly. Annotated components remove repeated dependency resolution, dispatch metadata and lifecycle wiring from application classes. Both use the same security, transport and resource boundaries.
An ordinary Java call to another method on the same object remains an ordinary Java call. It does not establish a new authorization, transaction, retry or managed invocation boundary merely because the target method has an annotation.
Four questions before writing a handler¶
- Who owns its dependencies and when may they be closed?
- What is the stable identity of the operation across retries or restart?
- Which outcomes can be known after a timeout or lost reply?
- Which resource actually enforces the fence, transaction or idempotency key?
Answer these questions at the application boundary. An annotation can make that answer visible in code; it cannot manufacture a guarantee that the underlying resource does not provide.