0

From another thread

By definition, an entity is a class that can be persisted to a database, so having a final field would make no sense in the context of something that will end up being a record in your database.

Could someone elaborate on why having a final field would make no sense?

Community
  • 1
  • 1
xrdty
  • 886
  • 2
  • 10
  • 22
  • The answer you quote elaborates quite nicely. What part did you not understand? And why aren't you asking there, where the author can see and reply? – Erick G. Hagstrom Dec 22 '15 at 14:06
  • 1
    Possible duplicate of [Persistence provider for Java that supports final fields](http://stackoverflow.com/questions/2455906/persistence-provider-for-java-that-supports-final-fields) – Erick G. Hagstrom Dec 22 '15 at 14:11
  • @ErickG.Hagstrom I don't seem to get the connection between an immutable variable/field and a record/tuple in a database – xrdty Dec 22 '15 at 14:14
  • 1
    But that's the whole point. Instances of the entity class are object representations of database relations. They exist to allow create/read/update/delete (CRUD) operations on the database to be performed on Java objects without having to write SQL statements. – Erick G. Hagstrom Dec 22 '15 at 14:20
  • But what is wrong with a tuple being read only? Is it absolutely necessary for database records to support CRUD operations? – xrdty Dec 22 '15 at 14:23
  • I can imagine being able to do that, but then why would you want it to be an entity? There's a lot of extra machinery attached to an entity to make the database connection transparent. You'd be better off IMO to just read the table rather than go through JPA. So it's conceivable that one _might_ be able to do that, but in practice it just doesn't make a lot of sense. – Erick G. Hagstrom Dec 22 '15 at 14:29
  • 1
    You should have asked in a comment on the original answer; then the author could have expanded on the answer. – Erwin Bolwidt Dec 22 '15 at 15:06

2 Answers2

5

Generally, persistence providers make proxies of objects using some library like CGLIB or javassist. These proxies are creating runtime subclasses of the entities. That's why they should not be final.

Detailed Explanation:

You can make an Hibernate Entity class final, but that's not a good practice. Since Hibernate uses proxy pattern for performance improvement, so, in case of lazy association, by making an entity final, Hibernate will no longer be able to use proxy, because Java doesn't allow extension of final class, thus limiting your performance improvement options. Though, you can avoid this penalty, if your persistent class is an implementation of interface, which declares all public methods defined in Entity class.

Proxies are created dynamically by sub classing the object(For example Student entity class) at runtime. The subclass overrides all the methods of the parent, and when any of the methods are accessed, the proxy loads the real object from the DB and calls the actual method on that object. If we make entity class as final then that entity class can´t be subclassed because final classes can´t be inherited.

Naveen Singh
  • 184
  • 1
  • 11
4

You can have them, but they will be excluded from the persistence as a "Transient" field. So they won't be loaded or saved. That's just how JPA works.

static int transient1; // not persistent because of static
final int transient2 = 0;  // not persistent because of final
transient int transient3; // not persistent because of transient
@Transient int transient4; // not persistent because of @Transient

So then because JPA requires a parameterless constructor, you must set the final in that constructor or it's declaration, to a fixed value or something from a static. So it has little value, and would be smelly if it were used like this.

weston
  • 54,145
  • 21
  • 145
  • 203