We didn't really add any new type of identifier in JPA 2.0 since an id class and embedded id pretty much covers what you could ever want to reasonably do, I think, but we did add a lot of options for more easily mapping these types of identifiers. See
this thread for some examples. There are lots more, particularly when you get to mixing embedded ids with id classes, and multiple composite PKs. I spend a fair bit of time in the book going over the gory details of these and other cases.
In terms of the best strategy, well, that is mostly a matter of personal taste and application use. Paul mentioned some of the commonly held opinions about the synthetic or provider-generated PKs. He is right that they can indeed impose a simple uniqueness that is easy to manage and efficient to use. I thought I should add a few more perspectives, though, for your consideration.
It turns out that there is almost always one or more attributes that is/are unique in your data set. If two records could have the same data but a different generated key, from an application domain perspective they are the same thing and there would be no reason for there to be two records in the first place. So you have to be careful that you are not just covering up the uniqueness problem. You usually do need to know what is unique about the data in any case, and often additional database constraints ensuring that uniqueness will need to be in place.
One of the problems with generated primary keys is that from the client perspective, an artificial PK has no domain relevance. If you are looking for a particular domain object and you know the domain-specific unique aspect of it, you can't use the prototypical PK lookup operation (find) because you have no idea what its generated PK is. You know the practical domain key, but since you are using a generated PK you are forced to do a query instead of a simple cache lookup by PK. What you end up doing is putting indexes on the actual unique domain fields in the database, anyway, to make these types of queries more efficient. At that point you might just as well have used the application attribute as the key. If course, when the key is composed of multiple fields you get back to the complexity, management and efficiency arguments again...
So generated keys can really be helpful, but
you should understand what you are giving up, and not use them if you don't need them.
I should also mention that although it is possible to take these generated keys out of the user view, when the entity is mobile, or just for client management and entity differentiation, having the unique id in the entity itself is a real advantage.
Again, as is commonly the case, the answer is "it depends on the application".