Problems with JPA/Hibernate
stemlaur.com
Problems with JPA/Hibernate
1–10 of 195 posts
Re: Problems with JPA/Hibernate
#2What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point
Re: Problems with JPA/Hibernate
#3What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point
A huge developer base and eco system? What specifically, can't be achieved in Java, that you think node is needed for?
Re: Problems with JPA/Hibernate
#4What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point
Far ahead in what sense?
In my previous job we used Java and the benefits were a huge ecosystem of libs and tools, plenty of monitoring tools, a ton of expertise and people who understood its memory model and quirks and were able to troubleshoot production problems. The JVM is rock solid and has great performance for backend with lots of transactions.
I'm not experienced with Go, Python doesn't seem particularly suitable, and server-side javascript looks like a nightmare to me.
NodeJS seems crippled to me.
Re: Problems with JPA/Hibernate
#5> This loop has to stop, what defines the value of the projects we are working on has nothing to do with technologies and frameworks.
> I WANT to solve business problems, I do not want to keep solving technical issues.
It is interesting how emotionally invested we become with our tools. Yet we don't have infinite time to become productive with all possible frameworks. So we have to specialize at least somewhat.
As to JPA itself, I agree that it's generally a bad fit for most uses. Circa 2010 I used it with Java Enterprise in the hope that an failed bean could be recovered by a parallel worker, but the technical costs were crazy high. And often I had to drop to raw SQL anyway. Less invasive ORMs can still be more generally useful, and remove some tedium.
Re: Problems with JPA/Hibernate
#6This article is... Questionable at best. I don't think any of this is an argument against JPA, except that the author doesn't like how it works? I also suspect the author doesn't know hibernate that well.
For instance selecting just the fields you need is relatively simple with JPQL:
SELECT i.url FROM Image i WHERE i.id = ...Re: Problems with JPA/Hibernate
#7What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point
Far ahead in what sense? In my previous job we used Java and the benefits were a huge ecosystem of libs and tools, plenty of monitoring tools, a ton of expertise and people who understood its memory model and quirks and were able to troubleshoot production problems. The JVM is rock solid and has great performance for backend with lots of transactions. I'm not experienced with Go, Python doesn't seem particularly suit…
One benefit I've been seeing with server side JS is from FAAS like Lamba which can serve unpredictable loads very inexpensively.
Re: Problems with JPA/Hibernate
#8The underlying problem is one of O-R impedance mismatch. Going full SQL and getting rid of the ORM is a possible answer, but it has tradeoffs and is not a silver bullet. It might mean re-creating from scratch an in-house, bug-ridden ORM, or ditching OOP idioms from your language, or both.
The author of TFA seems to be going through one of the stages described in "ORM is the Vietnam of Computer Science", an article that should be mandatory reading before one claims to know the solution to this decades old problem.
Re: Problems with JPA/Hibernate
#9From my experience ORMs are good time savers when you have relatively simple query needs, but fall down when things get really complex.
Re: Problems with JPA/Hibernate
#10What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point
Far ahead in what sense? In my previous job we used Java and the benefits were a huge ecosystem of libs and tools, plenty of monitoring tools, a ton of expertise and people who understood its memory model and quirks and were able to troubleshoot production problems. The JVM is rock solid and has great performance for backend with lots of transactions. I'm not experienced with Go, Python doesn't seem particularly suit…
The JVM is rock solid, and recent improvements in garbage collection have reduced tail latencies dramatically.
But I find that most people who say that it has "great performance" have not built a parallel implementation in JS, Go, Rust, or even .NET Core. I'm omitting memory unsafe languages by default and Python here, because I think that's the domain Java competes in, and Python lacks the investment these other languages have in performance.
The lack of value types and the amount of pointer chasing that JVM languages do as a result, the way generics are implemented via type erasure (which the JIT then has to re-optimize), and so on usually mean that CPU and memory usage for the same throughput is much higher than a competing implementation in a different language. And on older JVMs, tail latency will be orders - plural - of magnitude worse.
It is absolutely true though that for most workloads that efficiency isn't necessary and the ability to reuse that ecosystem reduces time and cost to develop. But it's just definitely not true that Java has "great performance" and I don't think that's ever really been true.