SQL to Java Entity Generator
Turn one MySQL or PostgreSQL CREATE TABLE statement into a reviewable Java persistence entity with explicit mapping choices and notes.{{ summaryTitle }}
{{ summaryLine }}
{{ copyStatus }}
{{ computation.values.java_entity_source }}
{{ sourceExportStatus }}
The chart renderer is unavailable. Exact mappings remain available in the ledger.
{{ chartExportStatus }}
| SQL column | Java field | SQL type | Java type | Constraints | Copy |
|---|---|---|---|---|---|
{{ row.sqlColumn }} | {{ row.javaField }} | {{ row.sqlType }} | {{ row.javaType }} | {{ row.constraints }} |
{{ ledgerExportStatus }}
A database table and a Java persistence entity describe related data from different sides. The table defines storage types, nullability, keys, defaults, and vendor-specific behavior. The entity defines Java fields and persistence annotations that an object-relational mapper uses to read and write rows.
Turning one into the other is a mapping task, not a literal translation. SQL has unsigned numbers, generated columns, collations, table options, native JSON, enum types, identity rules, and time types whose meaning may not fit one Java class exactly. Java adds identifier rules, package names, accessor choices, imports, and persistence API versions.
| SQL concern | Entity consequence | Review question |
|---|---|---|
| Primary key | At least one field must carry identity metadata; composite keys need a separate key class. | Does the Java identity match the database key used for updates and equality? |
| Column type | The SQL type maps to a Java wrapper, time class, string, byte array, or other supported type. | Can the Java type represent the database range, precision, time-zone meaning, and vendor behavior? |
| Default or generated value | Database-managed behavior may need annotation settings rather than a Java initializer. | Which side owns the value before and after an insert? |
| Foreign key | A scalar key can be mapped without guessing an object relationship. | Should the application add a reviewed association, fetch policy, and cascade policy? |
A generated entity is most useful as a starting point for review. It can remove repetitive typing and make mapping choices explicit, but it cannot discover domain invariants, relationship ownership, validation annotations, repository behavior, converters, lifecycle callbacks, or the project's equality strategy.
The safest handoff compiles the generated source, validates the persistence mapping, compares it with the real schema, and exercises reads and writes against a disposable database before the class reaches production code.
How to Use This Tool:
Begin with the database dialect because it changes how identifiers, comments, identity columns, and several SQL types are interpreted.
- Paste exactly one CREATE TABLE source statement with an explicit primary key, then select MySQL 8.4 or PostgreSQL 18.
- Enter an optional Java package and class-name override. Leave the override blank to derive an upper-camel-case class name from the table.
- Choose Jakarta Persistence 3.2 or the Javax Persistence 2.2 compatibility imports, then select standard members or Lombok annotations.
- Set the Java 17, 21, or 25 target and decide whether SQL names become lower-camel-case fields or stay unchanged when they are already valid Java identifiers.
- Correct unsupported types, invalid names, missing keys, extra statements, or column-limit errors until Java entity source appears.
- Review every mapping and note before copying the class. Compile it with the chosen persistence API and any explicit Lombok dependency, then validate it against the destination schema.
Interpreting Results:
The class name and mapped-column count confirm the basic scope. The mapping ledger is more important: it pairs each SQL name and type with the Java field and type, marks primary-key and nullability facts, and lists choices that need manual review.
Pay particular attention to unsigned integers, MONEY, JSON, XML, MySQL ENUM, SET, and YEAR. These types receive usable scaffolds with explicit cautions rather than claims of perfect semantic equivalence.
A result with no review notes still needs compilation and schema validation. The generator does not connect to the database, inspect migrations, execute the DDL, or discover framework conventions outside the supplied statement.
Technical Details:
The transform accepts a bounded subset of MySQL 8.4 and PostgreSQL 18 CREATE TABLE syntax. SQL comments are removed outside quoted values and identifiers, the table body is split only at top-level commas, and quoted or unquoted names are read according to the selected dialect path.
Transformation Core:
| Stage | Transformation | Review boundary |
|---|---|---|
| Statement parse | Read one optional schema-qualified table name, its column list, supported constraints, and trailing table options. | Additional statements and an unclosed table body are rejected. |
| Column map | Convert each supported SQL type into a Java type, imports, length, precision, scale, nullability, uniqueness, identity, and generated-column flags. | Unsupported or dialect-mismatched types stop generation instead of falling back silently. |
| Name map | Derive a class name and unique Java field names while avoiding reserved words and collisions. | Renamed columns are recorded as review notes and retain their SQL names in annotations. |
| Persistence scaffold | Emit package and imports, entity and table annotations, fields, column annotations, accessors or Lombok annotations, and a nested key class when required. | The chosen API changes imports; Lombok output requires that project dependency. |
| Audit | Return a field-by-field mapping ledger and deduplicated review notes. | The ledger explains generated choices but does not validate a live schema. |
Type Mapping:
| SQL family | Java type | Mapping detail |
|---|---|---|
BIGINT | Long | PostgreSQL big-serial aliases also mark identity generation. |
INTEGER / INT | Integer | PostgreSQL serial aliases also mark identity generation. |
DECIMAL(p,s) / NUMERIC(p,s) | BigDecimal | Precision and scale are copied into the column annotation. |
| Character and text types | String | A declared character length is copied when present. |
DATE, local time, local timestamp | LocalDate, LocalTime, LocalDateTime | Types without time-zone semantics use local Java time classes. |
| Time or timestamp with time zone | OffsetTime or OffsetDateTime | The offset-bearing Java type preserves the declared distinction. |
UUID | UUID | The Java utility type and import are added. |
Binary, blob, or BYTEA | byte[] | A one-bit BIT maps to Boolean; wider bit fields map to bytes. |
JSON / JSONB | String | A note recommends a converter or vendor type for structured access. |
Rule Core:
- An explicit primary key is required. An identity column must be part of that key.
- A composite primary key becomes a nested serializable
IdClasswith matching key fields. - Single-column and multi-column unique constraints become column or table mapping metadata.
- Generated columns are marked non-insertable and non-updatable.
- Foreign-key columns remain scalar fields because relationship ownership and cascade behavior cannot be inferred safely.
- SQL defaults do not become Java field initializers, and trailing table options are recorded as ignored.
Worked Mechanism Path:
For a MySQL table named customer_account, an auto-increment BIGINT primary key becomes a Long id field with identity generation. A non-null unique VARCHAR(255) named email_address becomes String emailAddress with name, nullability, uniqueness, and length metadata. A nullable JSON column becomes a nullable String field plus a review note that structured JSON access needs a converter or vendor type.
Limitations:
The output is a persistence scaffold for one table, not a complete domain model or database migration.
- Input is limited to 50,000 characters, 100 columns, and one
CREATE TABLEstatement; generated source is limited to 200,000 characters. - Only the declared MySQL 8.4 and PostgreSQL 18 paths are supported. Other dialects and unsupported vendor types are rejected.
- Checks, indexes, collation, table storage options, relationship annotations, validation rules, converters, constructors with business meaning, and repository code need separate review.
- Compile against the selected Java and persistence API versions. Javax compatibility imports do not make a Jakarta-only project compatible, and Lombok output is not self-contained without Lombok.
References:
- MySQL 8.4 CREATE TABLE statement, Oracle.
- PostgreSQL 18 CREATE TABLE, PostgreSQL Global Development Group.
- Jakarta Persistence 3.2 specification, Eclipse Foundation.
- Java Language Specification, lexical structure, Oracle, Java SE 25.