6

Hi my question is not technical. I want to know if hibernate 5 supports XML based entity mapping or not.

My requirement is like below :

I want a backend on Jersey-Hibernate. My front end is Android application. I want to keep my Entity POJOs in a common project such that they will be shared by both app and server. Gson will serialize/deserialize both side. But because android application doesn't support all java library in compilation, I don't want my common(POJO) depending on some library; In this case hibernate annotations. So I am planning to use XML based configuration.

Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911
Kuldeep Yadav
  • 1,664
  • 5
  • 23
  • 41

2 Answers2

13

Hibernate 5 supports both the legacy HBM mappings as well as the JPA XML mappings too. However, HBM mappings are no longer the recommended approach to map entities. As illustrated in the new User Guide, all examples make use of annotations.

There are more features provided by Hibernate-specific annotations than it is the case with HBM mappings. In Hibernate 6, it is planned to add an extension mechanism to the JPA XML mappings, therefore HBM mappings are deprecated.

Since you are migrating to Hibernate 5, it's a good idea to migrate from HBM to annotations too.

Vlad Mihalcea
  • 142,745
  • 71
  • 566
  • 911
  • 6
    I want to keep my POJO independent of all dependencies, but if I use annotations then I will have to set dependency on maven Hibernate annotation. Thats why I want hbm. Can you please tell me some other way if there is any? – Kuldeep Yadav Aug 14 '16 at 05:58
  • You can depend only on JPA annotations. Therefore, javax.persistence is the only dependency. But you need it anyway. – Vlad Mihalcea Aug 14 '16 at 08:00
  • But android doesn't comple with JPA annotation library. So hbm.xml is my best option. – Kuldeep Yadav Aug 15 '16 at 16:31
  • Hello Vlad, is the statement still valid that hbm will be deprecated? And are there time schedules when it will be removed? – GreenRover Jan 11 '19 at 10:56
  • Yes, HBM been deprecated for a long time, but there is no timeline for when it will be removed. Anyway, annotations are better supported than HBM, so you are better off migrating anyway. – Vlad Mihalcea Jan 11 '19 at 11:55
  • I'd rather stay on older versions of Hibernate than migrate to annotations. Eh, younger generation doesn't appreciate clean code.. Anyway, I don't see any official news about `hbm.xml` deprecation. Is this being done silently? So far I can't see any problems in Hibernate 6. – Stanislav Bashkyrtsev Feb 22 '23 at 16:28
  • As a top Hibernate committer, I know that many features have not been ported to HBM for over 10 years. None of the new features are tested against HBM. So, other than the old tests that were written between 2002-2007, there aren't many guarantees that a certain new feature will work just fine on HBM. When I rewrote the Hibernate manual, why do you think I didn't add any HBM example in it? All examples use the JPA or Hibernate annotations because they are much more convenient than the pre-2006 legacy HBM mappings. – Vlad Mihalcea Feb 22 '23 at 19:52
  • Annotations may be accetable when you use Anemic Model and you don't have much going on in the entities. When you start doing OOP, you tend to think more carefully about what you put into the Entities - as they quickly bloat. Hopefully the basic functionality will keep working with the XML. Advanced functionality usually isn't needed anyway - complicated querying is better be left outside of ORM purview. – Stanislav Bashkyrtsev Mar 04 '23 at 16:53
  • JPA entities are not the Domain Model per se, so the Anemic Model paradigm has nothing to do with JPA entities that are strictly related to the Persistence Layer. As for the legacy XML mappings you're still using, good luck with that. – Vlad Mihalcea Mar 04 '23 at 18:11
  • "_JPA entities that are strictly related to the Persistence Layer_" - seems like you're suggesting using ORM Entities as dumb DTOs and wrap "Domain Entities" around them? Do you have any literature that goes into more details on this? I can imagine situations where this could be useful, but I can't imagine that the amount of additional efforts could pay off overall. Curious to see an example. – Stanislav Bashkyrtsev Mar 04 '23 at 21:11
  • The goal of an ORM tool is to deal with the [O/R mismatch](https://en.wikipedia.org/wiki/Object%E2%80%93relational_mapping). That's it. That's what JPA entities are for. More, there is no such thing as "dumb DTOs" or "Anemic Models". Those are just fancy terms that were invented to justify the DDD illusion, which, by the way, doesn't work nicely with relational databases. But, when you learn about DDD, they kinda omit the fact that it only works for Document stores only. [This tutorial](http://scabl.blogspot.com/p/advancing-enterprise-ddd.html) explains why DDD and RDBMS don't play well. – Vlad Mihalcea Mar 04 '23 at 21:22
  • I never mentioned DDD.. DDD is just one possible approach to Rich Model, but it only works for projects with simple business logic. In complicated projects we need to use full-blown OOP. I don't want to discuss all the weird assumptions and problems that the articles present.. But I do have successful (and _very_ complicated) projects that marry OOP and ORMs nicely within the _same entities_ (there are some annoying things that are needed just for the persistence, but we can survive that). Anyway, do I understand correctly that the solution that you suggest is resorting to Anemic Model? – Stanislav Bashkyrtsev Mar 05 '23 at 00:54
  • I've used the Keep It Simple approach on every project I've built, no matter how complex it was, and, unlike your approach, I never have to do any annoying or strange things related to anything because it's all simple and straightforward. Your implementation, no matter how OOP-ish you try it to be, will always be an Anemic Model. That's because, in reality, everything from the Service Layer to the DB and back is the Domain Model. The Domain Model is not just a bunch of OOP classes, it's everything that defines how the business will operate in reality and how real value is created. – Vlad Mihalcea Mar 05 '23 at 06:04
  • "_I never have to do any annoying or strange things related to anything because it's all simple and straightforward_" - if you mostly work on simple/straightforward projects, then it makes sense that we don't understand each other. I too work on such projects from time to time - and I agree that it doesn't matter which approach we choose there. But there are also excruciatingly complicated projects too - those are _complicated no matter which approach we choose_. It's just they become completely unmanageable with AnemicModel+TransactionScript. – Stanislav Bashkyrtsev Mar 05 '23 at 07:00
  • I worked on some of the largest projects developed in the EU and I have many Forbes 500 clients as well. Projects never become unmanageable if you Keep It Simple. They become unmanageable when things are overly complicated because the devs forced "patterns" they found in books or conf videos without understanding the trade-offs and the cost of those tech choices. If you take a look at [StackOverflow architecture](https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/), you will understand what I mean when I say to Keep I Simple. – Vlad Mihalcea Mar 05 '23 at 08:04
  • Curious to hear how you compared the size of projects given that most projects in the world are held private :) Also size != complexity. There are lot's of huge but simple projects. SO is an awesome software, I love how they set things up. But it's also a project with simple business rules. Another example of beautiful KISS-in-action is Git. But the fact that you think that _all_ projects can become simple if you follow KISS means (in my mind) that you shy away from complicated ones. Try taking Linux kernel and make... I don't know... its TCP/IP stack simple. – Stanislav Bashkyrtsev Mar 05 '23 at 13:34
  • You are still confusing Simple with Easy. In software, the opposite of Simple is Tangled. [Rich Hickey says it best](https://www.infoq.com/presentations/Simple-Made-Easy/). – Vlad Mihalcea Mar 05 '23 at 17:07
1

Yes, according to documentation (where authors recommended using annotations for mapping) is said that xml mapping is still possible: docs

So on - you can still us *.hbm.xml for entity mapping.

EDIT: ofc I mean *.hbm.xml

ByeBye
  • 6,650
  • 5
  • 30
  • 63