public @interface Entity

Marks a POJO or PropertyBusinessObject as a persistent entity, in the app and on the Codename One backend alike.

At build time the Codename One Maven plugin generates a reflection-free Dao next to the class with createTable, insert, update, delete, findById, findAll, and find(where, params) methods. Application code reaches the generated dao through com.codename1.orm.EntityManager:

@Entity(table="users")
public class User {
    @Id(autoIncrement=true) public long id;
    @Column(name="full_name") public String name;
    public int age;
}

EntityManager em = EntityManager.open("MyDB");
Dao<User> users = em.dao(User.class);
users.createTable();
users.insert(new User());

The dao uses the same prepared-statement protocol as the existing com.codename1.db.Database; no Class.forName lookups, so the binding survives ParparVM rename / R8 obfuscation in shipped builds.

An entity is the one kind of class both halves of an application own: the app stores rows of it in its local SQLite file and the server stores rows of it in PostgreSQL, MySQL or SQLite. The backend runtime compiles this very annotation (it is marked SharedWithBackend), so the entity class can be a single file in a module both sides depend on. What differs is what the build GENERATES from it: against the core the processor emits a dao over com.codename1.db.Database, against the backend one over com.codename1.backend.Database, whose SQL is built for whichever engine the connection turns out to be. On the server the class needs public fields and a public no-arg constructor, because the generated dao reads and writes them directly.