JPA is just an API (hence Java Persistence API) that requires an implementation to use.
An analogy would be using JDBC. JDBC is an API for accessing databases, but you need an implementation (a driver jar file) to be able to connect to a database. On its own, without a driver, you cannot do anything with a database.
With JPA, as I said, you need an implementation, a set of classes that lie “below” JPA, and such an implementation will do what you want.
Your application uses the JPA API (this wording is a bit cubersome, but I hope you get the idea), which then communicates with the underlying implementation.
Popular implementations include Hibernate, EclipseLink, OpenJPA and others.
Every one of them implement the JPA API, so if you use only JPA, every implementation should act the same.
But! The functionality provided by these implementations might go beyond the standard JPA API.
If you want to use this particular functionality, you will have to use vendor specific API that will not be compatible with others.
For example, even though JPA defines the @Id annotation with ID generation options, when using Hibernate, you can use also @org.hibernate.annotations.GenericGenerator for Hibernate specific generation strategies.
Using this annotation will not work unless you’re using Hibernate as the underlying implementation.
The bottom line is: JPA is the “least common denominator” which every vendor implements, and every implementation might have some more advanced features that aren’t standard.
If you want your application to be portable, use only JPA. If you are sure you won’t change your mind later on and switch implementations, use JPA + vendor specific features.