jmix-ide-static-analysis: the false-positive table has no ERROR-severity entry, and one exists

[glebfox]

Found while following the skill on a Jmix 3.0.1 project.

Problem: silent — the table lists only WARNING-level noise, so an ERROR reads as necessarily real.

Task

Running Gate 1 over an increment whose listeners and tests load entities with dataManager.load(X.class).query("e.ref.id = ?1", id).

Where

"Known false positives — do NOT chase these", read against "Surface WARNINGS, not just errors … treat Jmix-inspection / unresolved-reference warnings as blockers".

What happened

The inspection reports 'e' unexpected with severity ERROR on every condition-only query(...) call — its JPQL parser reads the argument as a complete statement and fails on the leading alias. Every entry in the skill's false-positive table is a WARNING about unused methods or local variables, so the natural reading is that an ERROR is always a true positive and the code must change.

It must not: FluentLoader.query(String, Object...)'s own Javadoc gives "e.name = ?1 and e.status = ?2" as the example and says "Always use e as the entity alias", FluentLoader.ByCondition builds the select e from <entity> e prefix itself, and Jmix Studio's own generated UI test tearDown uses the same form — so the inspection flags the generator's output.

Settling it meant reading FluentLoader in the framework sources, and the pressure was to rewrite working idiomatic code into full JPQL purely to silence a tool. Caught by IDE inspection.

Suggested fix

Add the entry to the false-positive table with its severity called out, and add one sentence above the table saying that severity is not a reliable guide — the Jmix plugin reports some correct code as ERROR, so an ERROR on a query(...), a msg:// or a property path still has to be checked against the framework before any code changes.

[glebfox]

Seen again in another Jmix 3.0.1 project — a second false blocker in the same family, on the same table.

Running Gate 1 over tests that assert a Bean Validation message by name — messages.getMessage("com.company.app.validation", "SomeConstraint.message") — against an application bundle whose keys carry the group as a prefix, com.company.app.validation/SomeConstraint.message, which is the shape jmix-add-i18n-keys itself prescribes. The inspection reports Message not found for key <group>/<key> on every call site that passes the group and the key as two inline string literals, for keys that are present in every locale bundle and resolve correctly at runtime.

Two things prove it is the tool and not the code: the same warning appears on an already-shipped test whose assertions pass — and they can only pass if the key resolves, since the interpolated constraint message is compared against getMessage's return, which would be the bare key if it were missing — and the call sites that pass the key through a local helper variable draw no warning at all, so the difference is whether the literal is inline rather than whether the key exists. Settling it meant running the inspection over an unrelated, known-good file for comparison, which is exactly the detour the false-positive table exists to prevent. The skill's own rule makes this a Gate-1 blocker, so the natural response is to "fix" resolvable keys — or to switch every assertion to the one-argument form, losing the group. Caught by IDE inspection.

Suggested addition to the same table: Message not found for key <group>/<key> on a two-argument Messages.getMessage(group, key) call with inline literals, when the key exists in the bundle under exactly that prefixed form. The confirmation step that settles it in seconds is worth naming: run the inspection over any existing file that uses the same form and passes its tests. Two false blockers of this shape now suggests the table would be more useful organised by "the Jmix plugin does not understand this idiom" than by severity.

[knstvk]

@glebfox - this should be fixed in Studio. Could you reproduce these false warnings?

[glebfox]

Created a Studio issue.