perf(export): ignore Java-only changes when deciding whether an export model is affected

[joaodinissf]

For discussion. This stops Java-only changes from re-queuing and regenerating .export files (part of #1545).

What changed

Since #1405, Export is an Xbase language. Its resource descriptions (XbaseResourceDescriptionManager) record the JVM types of the inferred model as imported names, and those include the downstream EMF interfaces that come from genModelUtil.instanceClassName. Any JDT change to those interfaces therefore marks every .export that uses them as affected. The .export is then re-linked, re-inferred and regenerated. That generated Java is recompiled, and the build does another round. Before #1405, .export files imported no Java names and were never re-queued by Java changes.

A new ExportResourceDescriptionManager (bound in ExportRuntimeModule) drops java:/ deltas before the isAffected checks. Deltas from ecore/genmodel resources and from other DSL files are still honoured.

Why this should be safe. The generated Java is built from genmodel data: instanceClassName is a string, and typeRef(String) only prints that name. It does not depend on what the Java type contains.

Trade-off. Suppose a Java interface is renamed or removed without a genmodel change. The .export is then not regenerated, and its generated Java shows a compile error, as it did before #1405. An unresolved-type marker on the .export stays until the file is touched or a clean build runs.

Verification

• Per Java-only branch switch on a synthetic workspace (M, stock builder): .export re-processed 2 → 0, files written 260 → 205 (.java 32 → 22), allocation −9%.
• Control. A branch switch that changes an .ecore / .genmodel still re-processes the dependent .export, .scope and .xtend files (3 / 8 / 16), exactly as on master except the Java-triggered one. 0 errors.
• No effect with DDK's builder runtime (ClusteringModule), which does not re-queue these files to begin with.
• Tests. Full reactor verify green: 366 tests (0 failures, 2 skipped), 0 Checkstyle violations, PMD clean; the 14 export tests pass.
• Pending. A before/after timing on the affected Windows machine. This stays a draft until that is in.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LgVRfQCTxSDwGrN8J5s6fd

[rubenporras]

This is for sure not true, export language can use java classes at will from extensions. For example:

extension com::foo::^export::Bar

and the

export lookup x::TypeN as qualified name [isBlaBla(this.eContainer)]{
object-fingerprint;
}

where isBlaBla is defined in com.foo.exportBar

[joaodinissf]

@rubenporras: you're right that export models depend on Java beyond the EMF model, so the premise of this PR (and its Javadoc) is wrong. I dug into what that means for rebuilds:

• Extensions: the extension class is stored as a plain name and only resolved while the Java is generated, after the builder has recorded what the model depends on. So a change to an extension class doesn't re-queue the .export on master either. A test confirms it: a resolvable extension class is neither an imported name nor a reference, while EClass and the DDK base classes are. This PR doesn't cause that gap, but it's a real one; I've opened Export: classes named in extension declarations are not build dependencies of the export model #1554 for it.
• What this PR actually skips: I instrumented isAffected in the benchmark. The two .export re-queues per branch switch come from EMF model interfaces (Slot, Leg) whose hand-written @generated NOT methods differ between the branches, and the generated export code references those interfaces. That's a real dependency, so this PR's whole saving comes from ignoring it.
• Before Migrate the Scope generator off classic Xtend onto Xbase + JvmModelInferrer #1405 no Java dependencies of export models were tracked at all, which is why the June DDK showed no re-queues here. Migrate the Scope generator off classic Xtend onto Xbase + JvmModelInferrer #1405 made the tracking more correct, at this small cost.

So I'm closing this PR. The merged #1546 and #1547 carry the measurable gains.

🤖 Generated with Claude Code