Design Studio is the development workspace, TAFJ is the runtime
A reliable Temenos Java change needs a repeatable path from source in Design Studio to compiled/package artifacts, environment configuration, TAFJ runtime loading, and transaction verification. Problems appear when teams treat a successful local compile as proof that the target runtime has the same classes, records, dependencies, and activation state.
Know what is source, generated, packaged, and deployed
- Keep source-controlled Java separate from generated build outputs.
- Build against the same supported Transact/TAFJ dependency baseline as the target.
- Package required code and accompanying data/configuration with a versioned release manifest.
- Deploy consistently to the application-server/runtime locations expected by the environment.
- Restart or reload only the services that require it, then verify both technical loading and business behavior.
Build-to-runtime lifecycle
A controlled promotion preserves the same source, build inputs, package identity, and configuration evidence across environments.
Design Studio to TAFJ runtime
A controlled promotion preserves the same source, build inputs, package identity, and configuration evidence across environments.
1
Source changeStart
2
Compile / testsStep
3
Package artifactStep
4
Deploy code + configStep
5
TAFJ / app runtimeStep
6
Smoke transactionStep
7
Release evidenceOutcome
Promoting one Java hook safely
Lifecycle mistakes that create environment drift
Deployment checklist
- Record source revision and dependency baseline.
- Run compile/tests before packaging.
- Version the deployment artifact and configuration list.
- Verify class/config presence in the target before restart.
- Run one technical load check and one representative transaction after promotion.