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

101–110 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#101

Post by guggle »

oblio wrote: post #99
guggle wrote: post #87

Earlier quoted context omitted.

> Not having a compiler means I have to have unit tests doing what a compiler would do or finding out I have syntax errors or other errors at runtime. Nope, it's not the only way. In practice you'd have type hints all over your code and a linter to perform static analysis. Of course this can be integrated in you IDE, so it's easy to do. > Not having strong types and limited type hinting. I have no idea what things ar…

The thing is, type hints are optional. The vast majority of existing projects don't use them. Third party dependencies don't use them. Python is a toddler in terms of typing system support. Probably a 2 year old.

Indeed. But way to go... third party dependencies wont support Python < 3.6 forever. And it's still very useful for the application code alone.

Re: The Modern Java Platform – 2021 Edition

#102

Post by mustardo »

MrBuddyCasino wrote: post #88
mustardo wrote: post #33

Earlier quoted context omitted.

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

And it starts a lot faster. We used that combination at the last startup I was employed at, and it worked great.

Yea no runtime classpath scanning is a requirement for me, we do compile time eclipselink weaving etc which makes startups way faster

Re: The Modern Java Platform – 2021 Edition

#103

Post by reactor »

mberning wrote: post #7

My biggest gripe with java is developer productivity. It has gotten better but is still far behind interpreted languages like Python and Ruby. Class hot loading and things like that have made it better, but if you change a method signature or interface you have to stop your process, recompile, redeploy, and restart. For big codebases it’s brutal compared to the aforementioned languages and their attendant frameworks.

May be you should try Quarkus, its hot reloading is slick. Even with a large code base, I could just do change->save->refresh cycle (about a second).

Re: The Modern Java Platform – 2021 Edition

#104

Post by orthoxerox »

jacques_chester wrote: post #22

I liked this article, but it felt to be as much about Scala and Kotlin as about Java. A more accurate title would've been "The Modern JVM Platform". I recently began doing a side project and, for the first time in a while, picked Java over Kotlin. I mostly did so because most books on deep details of the JVM are mostly books about the deep details of Java. Plus: Java is moving along at a fair clip these days. Records…

> Project Loom and Project Valhalla are coming over the horizon

A: They say it's coming over the horizon. What's the horizon, B?

B: That's the imaginary line where the land and the sky meet that you cannot reach however fast you go.

Re: The Modern Java Platform – 2021 Edition

#105

Post by orthoxerox »

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?

Job listings in the searches I am subscribed to are almost universally Spring and Spring Boot.

Re: The Modern Java Platform – 2021 Edition

#106

Post by soco »

eecc wrote: post #89
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.

That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by your…

Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.

Re: The Modern Java Platform – 2021 Edition

#107

Post by elric »

matsemann wrote: post #70

Pair programming with colleagues I often get frustrated by them wasting time doing things a hard way. Like using print statements instead of the debugger, or setting a breakpoint but then have to skip it twenty times to get to the correct case (instead of a conditional bp), or restarting the whole server instead of hot reloading the changed class in a second. So I think many don't know how smooth java can be if used…

Conditional break points are definitely a great secret weapon. But don't underestimate the value of the humble print statement. It's convenient and can often lead to surprising insights "hmm, why is this getting printed so damned much?" in a way that is sometimes more accessible than a debugger.

Re: The Modern Java Platform – 2021 Edition

#108

Post by koala7 »

TeaVMFan wrote: post #18

The one thing missing is the innovation happening on the Java front end. Frameworks like TeaVM ( https://blogs.oracle.com/javamagazine/java-in-the-browser-wi... ) let you extend your Java app all the way to the browser.

You might be interested in https://vaadin.com/.

Re: The Modern Java Platform – 2021 Edition

#109

Post by algo_trader »

misja111 wrote: post #83
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've been through the whole evolution from Spring with XML configuration to the current 'convention over configuration' approach of Spring Boot. I actually liked the idea behind the XML configuration when I first got to know Spring in 2007. With this you could decouple the composition of your application from the actual code. You could deliver a jar and the user could decide with his own XML which parts to use and wh…

Errr, so today would you for Spring or Spring Boot ?

For a large ebay-sort-of backend with lots of REST apis to both front end and back end itegrations?

Re: The Modern Java Platform – 2021 Edition

#110

Post by TheGuyWhoCodes »

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 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.
Post reply on HN