I'm afraid I don't like "Hibernate". Hibernate, when used incorrectly, can add a massive overhead to your project in terms of runtime efficiency and maintainability.
Imagine the scenario where the architects of an application decide to create the database schema first. This isn't necessarily a bad thing until you add Hibernate in to the equation. EJB3, cool! So let's generate our objects from our database schema... bad mistake.
Hibernate is in an O/R mapping tool. That means it allows developers to map objects to a relational database schema. By generating objects based on a database schema what you are actually doing is creating Relational Database Objects. What I mean is, rather than creating a valid object model which works well, you are simply creating a bad object model that reflects your database schema. This might sound great and handy BUT... what you end up with won't be an object model that is very useable. Hibernate will add annotations to your objects and will assume all kinds of fetching strategies (it SHOULD assume eager fetching as per the JPA spec, but I'm not sure what it does) and may also add associations between classes that are uncessary or undesireable. For instance, when you add new use cases are the fetching strategies still appropriate? Possibly not! So, if you take this approach you need to go through the generated model with a fine tooth comb and check that it supports your all your currently known use cases and try best you can to make sure it can support your unknown future use cases (a very difficult task!).
Personally, I don't like the "database up" design approach. It implies a waterfall approach from the outset as usually once the database schema has been settled on it is very hard to change it. A better approach is to only think in terms of your object model and do not worry about your database schema until you really need to. At this point I can see Hibernate being more useful in that it will be able to generate your schema for you. However, I wouldn't recommend this either as it will most likely design you a schema that is very rigid to your current object model. Not only will you be stuck with your schema, but your object model won't be very flexible either.
I prefer to work with my object model and leave the RDBMS until the last possible moment. Since I do a lot of modular work, my database schema design ends up being very modular as well. This doesn't suit everyone so a suggestion would be to take the object model in small chunks and design the schema at agreed stages during the project lifecycle. You will naturally group objects together in packages where cohesion between classes is high or the classes fall in to a natural domain. Why should your database schema be any different? A lot of the time though, this is hard if not impossible because of referential integrity - and rightly so! But if you want the same flexibility with your RDBMS schema as you do with your objects grouped in to packages (low coupling) you end up with a lot of join tables. I don't have a problem with this, but tools like Hibernate cannot work that out for you.
Another option, if you really must use a RDMBS is to work with an ODBMS until later on in to your project when your object model has settled down and the risk of change in designing a database schema has been reduced. If you were to use something like DB4O for instance, it will encourage you to respect your object model. With the correct, sensible level, of abstraction it is not hard to create a layer to replace DB4O with your data access code for your RDBMS schema.
(Further more, consider using stored procedures in order to further remove the dependancy on your database schema.)
So you may be thinking that it isn't fair for me to dislike Hibernate, but the reason I do is mainly because it allows developers/architects to take certain shortcuts which add complexity and a certain amount of rigidity to a project. In turn this makes it difficult to be agile, encouraging a waterfall approach and makes it really hard to change your project's code at a later date, even if you just want to add something new.
It doesn't have to be that way, but given the availabilty of the tools, I suspect most developers (under project pressures) will take the easy way out just to satisfy their manager's continual (and understandable) desire for reducing timescales, but it is a false economy.
If you're about to embark on something like this, either generating objects based on a database schema or generating the schema based on objects consider NOT using the tools. Continue to use Hibernate, yes, but don't take the shortcuts as in the end they'll only add overhead rather than saving time and money.
Your turn... have you had a good experience with Hibernate generation tools? Did you have to spend a long time tweaking the objects/schema that was generated? Did you use Hibernate but manually annotate the objects/create mapping files? What approach worked best for you? What nightmares have you had?