Hacker News new | ask | show | jobs
by sitta 1618 days ago
Spring is certainly a divisive topic, and I think it's hard for people on different sides to fully understand each other's experiences.

I have used Spring for years. Yes, there are some things I don't like about it, for instances Spring Boots overeager auto configuration, but it provides an unparalleled level of flexibility and productivity. I have never encountered a behavior in Spring that I have not been able to read the source and figure out what's going on and then change the behavior to be what I want. Spring is absurdly flexible and you only need to use the parts that you want.

A few years ago, I decided to try an alternative and wrote an app in Vert.x with no Spring. It worked fine, but it was a hell of a lot more work than leveraging the Spring ecosystem. I later rewrote it using Boot, and it works better, is easier to understand, and uses less code.

Have you seen Spring Data JDBC? It's such a good idea that saves so much boilerplate and I'm not aware of anything else like it. It threads the needle between rolling your own SQL and descending into the hell of a full on ORM.

Anyway, the closets I can come to understanding why people hate Spring so much is to consider my own opinion of Rails. I don't like Ruby and I don't like Rails. I hate all of the magic and I don't want to learn it. But, I'm sure, like Spring, it's enormously productive if you do understand what it's doing and how to use it.

2 comments

I think you hit the nail on the head with your reflection on your attitude with respect to Ruby on Rails.

From my point of view, Java is an anemic language, and the "cure" appears to be to introduce a bunch of annotation-magic frameworks (Spring + JacksonXML + Hibernate/JPA/JDBC/whatever + Lombok?) that each have their own magic and inconsistencies, to the point that your Java code is more of a configuration file than actual logic (which sounds great), but with the downside that you don't actually know where anything is actually implemented and have little idea about what can fail and where.

As a "polyglot" dev, I just don't have the time or patience to learn all of the magic on top of the language itself.

On the topic of Vert.x, it's definitely a different philosophy than Spring, as you experienced. I'm honestly not sure what domains Vert.x would be superior in, but it seems like it's way overkill for your typical mostly-crud backend app. Vert.x is less of a framework and more like a "build-your-own-framework" toolkit.

Spring Data JDBC is, by default I believe, backed by a full on ORM, that being Hibernate.

I'm open to different opinions on this, but I dislike Hibernate because of the complexity and the pains it causes when trying to do simple things. Hibernate, and Spring's use of it, is a leaky abstraction. When running into bugs, just trying to use a flow like, read sql row to POJO -> update POJO -> Save POJO to DB, using Spring JPA repository interfaces, I find myself needing to know about Hibernate internals, like the persistence context, how it relates with transactions, when objects are merged vs saved vs are they already in the persistence context or not? Plus Hibernate docs suck in my opinion.

One time we hit a bug in Hibernate. This was within the last two years, using a newer version of Spring Boot. We read a row from SQL in a transaction. Later in time, in a whole different Transaction, we read the same row. We read it with an annotation on the query method, "@LockType(PESSIMISTIC_WRITE)". We were using MSSQL and this sends table hints like "(updlock, rowlock, holdlock)". So essentially we wanted exclusive access to this row for the length of the transaction. But the data we were getting in the row didn't make any sense? We could see the sql query with the table hints hitting the sql server, but Hibernate was giving us a cached POJO!? If we "evicted" the pojo before we queried then it worked right. Again, this was at the very beginning of a fresh transaction. Wtf.

This is not correct. You're thinking Spring Data JPA [1]. Spring Data JDBC [2] does not use any Hibernate nonsense.

[1] https://docs.spring.io/spring-data/jpa/docs/current/referenc...

[2] https://spring.io/projects/spring-data-jdbc

Ah, I see. Thank you!