Is JPA really that good?

Question

Java

Good afternoon.
I must say right away that I do not want to offend anyone and I do not want to offend. I recently started diving into Java EE and want to figure it out.
Now I understand with JPA. It seemed to me that this method gives more problems than advantages. Once upon a time, when I did not yet know about Java EE, I implemented some kind of JPA. I remember the eternal torment with addictions. In one place, loading is needed, in another it is not, in the third it is not clear right away. Some of the fields are needed, some are not, and even lazy loading did not save.
To learn EE, I bought the book Learning Java EE 7 by Anthony Gonçalves . I was delighted with CDI, I didn’t “enter” EJB (I’ll ask a separate question), but JPA disappointed me most of all because it didn’t give concrete solutions to problems, but only created the impression of a crutch wrapper around JDBC.
Let's try to compare. To begin with, pluses:
1) Of course, it is more convenient to use objects in the code, and not, for example, Maps (although you can still compare with type inference and a metamodel for the latter).
2) Base-independence. This is, of course, a controversial issue. I didn't go into it much, but I'm afraid, for example, a full-text index and the search on it will not be base-independent. If at all possible. Correct me if I'm wrong somewhere.
3) Lack of SQL in the code. Of course, someone will say that this is a matter of taste, but many will support me.
4) Experience with JPA in resume.
I ask readers to complete the list.
Now the problems I see.
1) Non-optimal queries to the database are possible. I have not come across this, I read it in some article about the experience. Perhaps this is the most problematic issue.
2) Problems with dependent strings that I described above.
3) In reports all the same, most likely it is necessary to "go down" to sql.
4) Some limitation. To do, for example, someField += 1 in the database for several rows will not be easy. And what in return?
I ask readers to complete this list.
I would be grateful for a real long-term experience with JPA, explanatory books. Those that describe not the technical work, but the method of application (in which cases which methods to use).
# According to "experience with JPA" there are vacancies :)
Thank you.

Answer 1

JPA is a specification, and the problems you describe, I think, should be considered on its specific implementation.

Answer 2

In some cases, JPA is quite suitable, where you do not need to build complex queries and where you do not need to squeeze all possible performance out of queries, for example, some not very complex admin panel. And, on the contrary, if you want to squeeze everything that is possible out of the database, you cannot do without sql, and screwing JPA may not give any advantages in ease of access to the database, but will only create confusion and complex interweaving of JPA and native queries.