Diagnosing JHipster Entity Generation Errors from Unsupported JDL Field Types

Recognizable Condition

Running a JHipster entity sub‑generator with a JDL file that contains an unsupported or misspecified field type will immediately abort with an error similar to:

jhipster entity Foo
Error: Invalid field type: Stringz
Entity not created.

When this happens the entity class, repository, service, and Liquibase changelog are not generated.

Cause / Diagnostic Table

Possible Cause	Typical Symptom
Typo in the field type (e.g., Stringz)	"Invalid field type" error
Using a type not in JHipster’s supported list (e.g., BigInt)	"Invalid field type" error
Custom type defined only as a field, not as an enum or entity	"Invalid field type" error
Invisible whitespace or non‑ASCII characters in the JDL	"Invalid field type" error

Ordered Checks

1. Verify the JDL field type spelling. Open the .jdl file and look for obvious typos.
2. Cross‑reference with the supported type list. Run jhipster info and check the Supported field types section. The list includes:
   • String, Integer, Long, Boolean, Float, Double, BigDecimal
   • LocalDate, ZonedDateTime, Instant
   • byte[], Blob, ImageBlob, AnyBlob
3. Confirm custom types are properly declared. If you need a custom type, create an enum or a separate entity and reference it as a relationship.
4. Check for stray whitespace or hidden characters. Use cat -A (Linux/macOS) or a hex editor to reveal non‑visible characters.

Fixes Tied to Findings

• Typo: Replace the misspelled type with the correct one (e.g., String).
• Unsupported type: Substitute with the nearest supported type or add a custom enum/entity and change the field to a relationship.
• Custom type without declaration: Add an enum or entity definition in the JDL, then reference it.
• Hidden characters: Remove them or re‑type the line manually.

After making the change, re‑run the sub‑generator with the --force flag to overwrite any partial artifacts:

jhipster entity Foo --force

Escalation Criteria

1. The error persists after correcting all field types.
2. The JHipster version is older than 7.x, which introduced support for certain types (e.g., Instant).
3. Running jhipster info shows that the project is using an incompatible JHipster version for the JDL syntax.

In these cases, verify the JHipster version, upgrade if necessary, or open an issue on the JHipster GitHub repository with the full JDL snippet and stack trace.

Concrete Example

Suppose the JDL contains:

entity Product {
  name Stringz
  price BigDecimal
}

Steps:

1. Run jhipster info to confirm the supported types list.
2. Correct the typo: name String.
3. Re‑run the generator: jhipster entity Product --force.
4. Verify that Product.java and product.xml (Liquibase) are created.
5. Start the application (./mvnw spring-boot:run) and run the unit tests for the new entity.

Verification Checklist

• Entity class exists in src/main/java/.../domain/Product.java.
• Liquibase changelog contains addColumn for name and price.
• Running ./mvnw test passes for tests that involve the Product entity.
• Database schema matches the expected column types (e.g., VARCHAR for name, DECIMAL for price).

Limitations and Caveats

• Direct edits to generated classes will be overwritten on subsequent generation runs.
• Even if the generator succeeds, using a type that maps poorly to the underlying database can cause runtime errors.
• Custom types must be fully defined in the JDL; otherwise the generator will still fail.

Practical Check

After fixing the JDL, run jhipster entity Foo --force and immediately open the generated files to confirm no Invalid field type messages appear. If the files compile and the application starts, the issue is resolved.