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

41–50 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#41

Post by midrus »

mustardo wrote: post #33
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…

Totally agree, why i use https://www.dropwizard.io/en/latest/ with guice, generally waaayyy more explicit about whats going on

I used Dropwizard many, many years ago. It was what made me like Java. Such an awesome tool.

I'm happy to see so many years later it is still alive and kicking and powering so many systems.

We definitely need more of this.

Re: The Modern Java Platform – 2021 Edition

#42

Post by shipp02 »

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…

This. I tried to bootstrap an web flux application without spring boot or kofu or anything and you have to move thorugh so many different classes to get to the appropriate bean for the handlers that I just gave up. Also multiple simmilarly named classes like ``WebHandler``, ``HttpHandler``.

I don't have much other experience so I thought it was just me.

DI is also a pain and you never know where something is comming from unless you are familiar with what every single functions adds to the ``CONTEXT``.

Re: The Modern Java Platform – 2021 Edition

#44

Post by avodonosov »

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…

That`s not spring boot, that`s whole spring (and google guice, etc), starting from the idiotic XML for bean wiring, to equally idiotic anntations, and finally, after 15 or how many years, they realized that plain java can be used for object creation. What a discovery! Still, they introduced @Configuration bullshit, etc.

(There are cases when such features may be useful, e. g. systems that are extended by 3rd party plugins, like Maven, although may be done without that as well).

For normall applications that´s nothing more than bloat and limitations. The problem that the majority of users follow cargo cults without understanding what are they doing. In result the ecosystem is full of bad practices.

AbstactArgumentBuilderFactoryFactory were in fashion for the same reason.

Otherwise Java is a neat little language and a good platform.

Re: The Modern Java Platform – 2021 Edition

#45

Post by shipp02 »

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 would like to draw you attention to vertx[1] its an eclipse project with well thought out API's and documentation and no magic.

[1]https://vertx.io/

Re: The Modern Java Platform – 2021 Edition

#46

Post by augusto-moura »

akhilcacharya wrote: post #43

What’s the modern standard for a full stack JVM app these days? Something rails-esque, or is it still just a split between Play and Spring Boot?

You have Grails p. P p a Rails alternative, I don't recommend it though Grails has come a long way but still has a lot of inconeniences and is becoming obsolete by the day, it became a monster with tangled and twisted code, everything (views, models, queries) has 2 or 3 reimplementations that don't quite work and are not finished. I used to develop more than 5 services in it and frankly I don't know how I managed to stay sane or sleep at night

Re: The Modern Java Platform – 2021 Edition

#47

Post by bosswipe »

andrewstuart2 wrote: post #40
kylecazar wrote: post #3

Go? Archaic? I suppose you are referring to the paradigm it employs...

Maybe the author isn't a fan of explicit pointers? Because yeah, though it's obviously c-like (as is Java), I can't think of anything else one might consider archaic that isn't also in the java language or virtual machine.

There are sooo many nice language features that have proven themselves over the last 3-4 decades and have become popular but are missing from Go that I think archaic is appropriate.

Re: The Modern Java Platform – 2021 Edition

#48

Post by nerdponx »

The_rationalist wrote: post #16
jxy wrote: post #6

Earlier quoted context omitted.

I'll believe it when I see the performance.

He were are, mostly one developper in only a few years has managed to create ~the fastest R runtime thanks to the graalVM infrastructure https://github.com/oracle/fastr + it get polyglotism for free. See also graalphp: https://github.com/abertschi/graalphp/blob/master/results.md Oracle has managed to create a language framework that enable unprecedented performance and polyglotism but there are no human resources all…

Last I checked (years ago), FastR was a one-developer research project that was way behind GNU R in terms of feature availability. Has that changed?

Re: The Modern Java Platform – 2021 Edition

#49

Post by _ivvf »

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 in mindset.

Re: The Modern Java Platform – 2021 Edition

#50

Post by ubertoop »

avodonosov wrote: post #44
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…

That`s not spring boot, that`s whole spring (and google guice, etc), starting from the idiotic XML for bean wiring, to equally idiotic anntations, and finally, after 15 or how many years, they realized that plain java can be used for object creation. What a discovery! Still, they introduced @Configuration bullshit, etc. (There are cases when such features may be useful, e. g. systems that are extended by 3rd party pl…

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.

Post reply on HN