Java Actions and Extensibility
Java actions and extensibility
A Java action is declared in the model and implemented in a .java file under javasource/. The generated class extends UserAction, receives its parameters as instance fields assigned in the constructor, and implements executeAction(); a generated static overload lets microflows invoke it with an IContext plus the parameters. Parameters can be primitives, strings, dates, decimals, enumerations, entities (arriving as IMendixObject) and lists (java.util.List).
The Core API is the bridge back to the model: Core.create, Core.retrieveXPathQuery, Core.retrieveId, Core.commit, Core.delete, Core.rollback. Proxy classes generated for each entity give typed getters and setters, while IMendixObject generically exposes getValue/setValue with the current context.
Traps
- Changes made to an object in Java are not automatically committed. If the caller does not commit, the change is lost when the transaction rolls back.
- The Java action runs inside the caller's context and transaction, so it inherits the caller's user and entity access - it is not a privileged escape hatch.
- Throwing a CoreException surfaces its message to the user; throwing a raw RuntimeException gives an unfriendly error page unless the caller handles it.
- Building XPath constraints by string concatenation invites injection and broken quotes; use XPathBuilder (Core.createXPathQuery) with its eq/and-style methods.
- A list parameter is a live list; returning a modified list requires constructing and returning a new one.
Rule of thumb
Use a Java action only for what the model cannot do (a library, a file operation, heavy computation). Everything else stays in microflows, where it is visible, testable and maintainable.