The Ecstasy compiler's "isNoOp()" constructor optimization produces non deterministic bytecode.

[lagergren]

The Java XTC compiler's isNoOp() constructor optimization in
TypeCompositionStatement.generateConstructor() produces non-deterministic bytecode
that depends on the order in which source files are compiled. Two structurally identical
programs can produce different bytecode depending on filename ordering, because the
optimization checks whether a super-constructor's bytecode has been generated yet — a
property that depends on compilation order, not program semantics.

The optimization is also incomplete across module boundaries: cross-module no-op
constructors are never optimized at compile time, even when they are provably trivial.

These are code-size issues only — the runtime has a safety net in Construct_0.process()
that skips no-op constructors at execution time. But the compiler should not produce
order-dependent output.

One argument could also be that it is not meaningful to do these kind of operations
at the bytecode level, in a modern runtime, but I guess it may make the interpreter
slightly faster, or something.

[ggleyzer]

You are correct that there is a possibility of false negative - if the code for a "no-op" super constructor has not been generated yet we would assume it is not a no-op. It behaves exactly as it was designed - an opportunistic size optimization.

The "cross-module" argument is much more serious, however. If the super class belongs to another module that can be independently changed after "this" module is produced this optimization can produce erroneous behavior. The corresponding check should definitely be added.