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

161–170 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#161

Post by Koshkin »

jrochkind1 wrote: post #151
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…

> 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 What does "decoupled" even mean anymore? That sounds like the opposite of "decoupled" to me. (/not a Java programmer).

I guess it means that dependencies are hidden now.

Re: The Modern Java Platform – 2021 Edition

#162

Post by dmux »

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…

>Java doesn't even support dependency injection, something that I would consider an absolute minimum for even a small project.

For small projects, DI is easy done by passing things via the constructor. If multiple things need to get wired together, pull that wiring logic out into its own class or method (FooBuilder.buildDefault()). If things start to get tedious, that's a really good time to stop and reflect on the design choices. That stop-and-reflect opportunity if often lost when things can be simply AutoWired together.

Re: The Modern Java Platform – 2021 Edition

#163

Post by rowland66 »

wiradikusuma wrote: post #37

Quarkus (and its dependent techs) has been in my radar for a while, and recently I've started using it, and I must say I'm impressed. Code in modern Java (lamba etc) -> build native Linux exe -> package as Docker image -> deploy in Google Cloud Run. All wiring from CLI so CI/CD friendly (next is to use Google Cloud Build). Since it's native, memory usage small and boot time negligible. Since it's managed, it auto-sca…

I think that you have the option with Quarkus to use the traditional JVM with byte code for development, and only generate exe's for stage or production deployment. Best of both worlds.

Re: The Modern Java Platform – 2021 Edition

#164

Post by mwcampbell »

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.

Re: The Modern Java Platform – 2021 Edition

#165

Post by dmux »

aww_dang wrote: post #82
codr7 wrote: post #23

Earlier quoted context omitted.

This. I spent so much time this week chasing magic buttons in that over engineered piece of stink. I'd rather do raw HTTP servlets at this point.

Plain servlets, jetty, haproxy for TLS, jstl, postgres, apache dbcp. Add in whatever specialty libraries for the project and you can pull away with 1/100th of the dependencies.

You can even pair that down a little further if you use the built-in HttpServer that's been in the JDK since 1.6.

Re: The Modern Java Platform – 2021 Edition

#167

Post by pjmlp »

eitland wrote: post #63
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…

It is telling that today modern JavaEE is in many ways a breath of fresh air compared to Spring :-|

One of the best decisions I have done, when I need to use my Java hat, is to have kept using JEE.

Spring even needs a web app to help configure its pleothora of behaviors.

Re: The Modern Java Platform – 2021 Edition

#168

Post by pjmlp »

_ivvf wrote: post #49
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 felt strongly enough about this topic to write a full blog post: http://sreque.blogspot.com/2019/08/the-autumn-manifesto-why-... . TLDR: so-called DI frameworks are really just frameworks for creating and consuming global variables and have very little to do with the actual principle in of DI. That said, I think the jvm and java the language are in a great spot. It's the frameworks and community that need a shift i…

The mindset that Java is often blamed for was already in full swing when other technologies ruled the enterprise.

Architecture astronauts will produce the same designs regardless of the programming language.

Re: The Modern Java Platform – 2021 Edition

#169

Post by pjmlp »

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.

Kubernetes was prototyped in Java and rewritten in Go due to Go bias of some team members, which forced a rewrite into Go.

Source: A couple of talks at FOSDEM.

Don't attribute to technology the outcome of political decisions.

I also used to get things done in TASM.

Post reply on HN