←back to thread

257 points pmig | 2 comments | | HN request time: 0s | source
Show context
time4tea ◴[] No.43099396[source]
The jvm is a pretty insane beast. It will do usage based recompilation, escape analysis for memory, so non heap allocation is super fast, has great memory safety... But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware software in the late 90s and early 2000s. It's cargo cult programming of the highest order. In the OP, the author is comparing apples with oranges, with a bit of misunderstanding that java/jvm means spring boot, and while that is true for a lot of people and certainly a lot of stuff on the internet implies that 'this is the way', it's not required. Startup times of ~100ms are absolutely standard for a big program, similarly unit tests taking 1ms. I prefer to write kotlin rather than java, as it's a nicer language ,IMHO, but still those bytecodes run on Jvm and same stuff applies.

Edit: im not advocating writing 'ls' in java, and I would also agree that java uses more memory for small programs, so its not a systems programming language probably.

Just use new() it's pretty fast.

replies(12): >>43099426 #>>43099935 #>>43100071 #>>43100330 #>>43100562 #>>43101034 #>>43101071 #>>43101189 #>>43101914 #>>43102326 #>>43102666 #>>43143349 #
okeuro49 ◴[] No.43099935[source]
> But a lot of people use it with spring/spring boot, a technology designed to work around the complexities of a particular type of middleware...

No, people use it because we don't want to reinvent the wheel.

Spring is well documented and Spring Boot gives you a set of dependencies that all work together.

Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

replies(5): >>43100066 #>>43100145 #>>43100618 #>>43100650 #>>43112249 #
anthropodie ◴[] No.43100066[source]
> Then you don't have to spend time messing around with things like OAuth and authentication, you can just write the application.

It sounds good but in reality people end up spending time messing around with config files and annotations.

replies(3): >>43100632 #>>43103416 #>>43109133 #
gf000 ◴[] No.43100632[source]
Like, what other option is there? There is either a proper, battle-tested solution which requires some configuration so that it works as you want, or you start from scratch and create something specifically for your own usecase.

In the latter case, it may actually mean a significant amount of development orders of magnitude more than looking up how to configure stuff, constant maintainance, etc.

replies(2): >>43100698 #>>43101582 #
whstl ◴[] No.43100698[source]
> Like, what other option is there?

For this specific case there's plenty...

You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little.

You can use other frameworks that also have those features, in Java or in other languages.

You can use a paid authentication services.

You can use an open source authentication services.

replies(2): >>43100960 #>>43101574 #
1. okeuro49 ◴[] No.43101574{3}[source]
> You can use the battle-tested libraries wrapped by Spring directly. For OAuth specifically, Spring does very little.

Then you have to work to make the libraries all work together. And deal with updates. Spring Boot allows to to update all libraries together, and know that they work together.

replies(1): >>43111105 #
2. whstl ◴[] No.43111105[source]
For this you setup tests and a CI, which is basic stuff that you can't really skip with Spring.

If you don't want or know how to do this, then there are all the other solutions.

Either way: authentication in a Spring app is the definition of "reinventing the wheel".