Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Modern Java Platform – 2021 Edition

jamesward.com

Post reply on HN
Print view View original

181–190 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#181

Post by nwatson »

simmerup wrote: post #143
lmm wrote: post #67

Earlier quoted context omitted.

Spring proper is (relatively) fine; you can make applications with it that are more-or-less maintainable. Spring Boot is very different. It's a write-only framework, and while businesses may have enthusiastically adopted it, it's new enough that they haven't (yet) had to pay the maintenance costs and realise how bad they are.

What do you mean by write-only framework?

WOF == you understand your software while you're writing/developing it but give it a rest for a Trump's "two weeks" and you'll have no clue what you did.

Re: The Modern Java Platform – 2021 Edition

#182

Post by phillipcarter »

holografix wrote: post #135
jlward4th wrote: post #125

Earlier quoted context omitted.

Author here. Yeah, the Go language feels very archaic when using more modern languages. Some things I miss when I use Go: immutability as a default, monadic error handling, type classes, higher-kinded types, high-level collection operations (map, flatmap, filter, etc), ADTs, extensive pattern matching, expression-orientedness, and explicit null handling.

Guess that’s why kubernetes and so many other CNCF projects were written in Go. It’s archaic enough that everyone can get things done instead of worrying about esoteric new features.

Some of the world's most incredible software is written in C and JavaScript and both are languages with incredible deficiencies from a language design standpoint. This doesn't take away from the software that was written in them.

Re: The Modern Java Platform – 2021 Edition

#183

Post by laurent92 »

selfhoster11 wrote: post #138
lmm wrote: post #21

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…

I read a comment once, saying that Spring is a lot like the COMEFROM statement [0]. You are in a class, but you have no idea how you got there, or how to get somewhere else. Your IDE is no help, because everything is "decoupled". [0] https://en.wikipedia.org/wiki/COMEFROM

I’m just learning about the COMEFROM statement, this exactly captures my reluctance with very modern apps. I especially despise checking permissions or caches using annotations, because you are never sure they are applied. I hope one day COMEFROM is as forbidden as GOTO.

Re: The Modern Java Platform – 2021 Edition

#184

Post by jacques_chester »

geodel wrote: post #149
lmm wrote: post #64

Earlier quoted context omitted.

I'm no fan of regular Spring, but it offers some legitimate value and has relatively comprehensible behaviour. It doesn't break grep: when a class is instantiated by Spring you can find a reference to that class, and most IDEs can also follow those references. Adding a new dependency doesn't change its behaviour. Spring Boot is real a step change in comprehensibility, in the wrong direction. It's on a similar level t…

Good to see another big fan of Spring Boot as me. > Spring Boot is real a step change in comprehensibility, in the wrong direction. With VMWare's Tanzu crap for containers and Spring native initiatives, the idea is complete lock-in in VMWare ecosystem from developer desktop to running service. The goal seems that no one should have any visibility on their own systems except VMWare consultants.

I work for VMware, so I am not disinterested, and of course we want it to be easy to use stuff we sponsor or contribute to.

But what exactly about stock Kubernetes and the fully-OSS-for-nearly-two-decades Spring Project strike you as "lockin"?

This is a bit like accusing Red Hat of lockin for shipping a Linux kernel.

Re: The Modern Java Platform – 2021 Edition

#185

Post by zokier »

lmm wrote: post #21

There's some great stuff on the JVM today, but Spring Boot is recapitulating all the problems of J2EE. Everything is extremely "decoupled" to the point that you have no idea where anything comes from or why, and just adding a new dependency to your classpath will radically change the behaviour of your application (oh, you added a dependency on a library that has a transitive dependency on the MongoDB client? Guess th…

I feel like spring got leapfrogged by plain javaee a bit; I can imagine that in early '00s Spring was big improvement over Java EE 1 .4 or whatever but modern Java EE to at least some degree caught up, JEE 8 and 9 being relatively pleasant to work with, along with Microprofile, while Spring feels more stuck in the 00s feel.

Re: The Modern Java Platform – 2021 Edition

#186

Post by EvilEy3 »

mwcampbell wrote: post #164

With Project Loom coming soon, I think it's a mistake to write new application code in the reactive style. The imperative style is much more straightforward, gives access to a wider world of libraries, and (IIUC) will be just as efficient when Project Loom reaches production.

Reactive style is written for reactive style, not to somehow bypass concurrency limitations.

Re: The Modern Java Platform – 2021 Edition

#187

Post by evilduck »

simmerup wrote: post #143
lmm wrote: post #67

Earlier quoted context omitted.

Spring proper is (relatively) fine; you can make applications with it that are more-or-less maintainable. Spring Boot is very different. It's a write-only framework, and while businesses may have enthusiastically adopted it, it's new enough that they haven't (yet) had to pay the maintenance costs and realise how bad they are.

What do you mean by write-only framework?

Write-only in this context means that the cost of maintaining something vastly exceeds the cost of rewriting that something from scratch.

I don't know Spring and Spring Boot well enough to pass judgement, but this situation generally arises in software when you have a language or framework that's reasonably expressive, where the language has a lot of sigils or keywords and it has "shortcuts" that you have to grok before you can really understand codebases that use those shortcuts (like annotations or heavy/excessive use of design patterns). It leads to software solutions that are only well understood by the original authors due to their specific knowledge and problem solving approach and anyone who comes along later must have the exact same overlap of knowledge and skills otherwise they'll find it easier to start fresh. This includes the original authors if the time lapse has been long enough.

This often then leads to the next phase of miserable software jobs, the second-system effect.

Re: The Modern Java Platform – 2021 Edition

#188

Post by jacques_chester »

selfhoster11 wrote: post #142
oweiler wrote: post #59

Earlier quoted context omitted.

I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.

You know what should be taking care of all of these things? Java! For a language that bills itself as the "enterprise language #1", it's abysmal in supporting actual enterprise features like you listed above in a lightweight fashion. Instead, a whole third-party framework has to be tacked on just so you don't have to reinvent the wheel. Java doesn't even support dependency injection, something that I would consider a…

Jakarta (née Java EE) has CDI, which bears a striking similarity to the Spring's dependency injection capability: http://cdi-spec.org/

Re: The Modern Java Platform – 2021 Edition

#189

Post by Pet_Ant »

ta988 wrote: post #174
ubertoop wrote: post #50

Earlier quoted context omitted.

This is true in most languages really. It starts with people just wanting to speed up their development by turning common tasks into some macro, or annotation, or even library. But where does it end? It ends in a convoluted mess of dependencies, weird syntax, and hopeless stack traces. So much work can be done with plain old Java. Or plain old JavaScript. Or plain old C + stdlib.

And you end up writing yet another custom framework for yourself when you realize you are writing the same things over and over...

But you and up writing just the bits you need so that you end up with a framework that serves your use cases, that you grew so you understand and unencumbured by the use cases of others. It'll make you more productive... but not necessarily the person you hand it off to.

Re: The Modern Java Platform – 2021 Edition

#190

Post by EvilEy3 »

lenkite wrote: post #122
TheGuyWhoCodes wrote: post #110

Earlier quoted context omitted.

I had the opposite reaction. They decided to reimplement almost everything and pushing hard on reactive stream, but their documentation is horrendous and the API is super complicated. After a month of tinkering I just gave up and used spring boot.

Please don't use Reactive in Java. Stick to plain imperative - and you'll be compatible with Project Loom in the future.

I don't see how using Reactive makes you incompatible with Project Loom.
Post reply on HN