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

21–30 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#21

Post by lmm »

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 that must mean you want a MongoDB connection pool spun up and running).

I swear I'm going to add a bitcoin miner to my libraries and list it in spring.factories so that it autostarts whenever someone starts a Spring Boot application with my library on the classpath. There'll be an undocumented config property to turn it off or make it mine to a different address. That's standard practice with every other library that uses Spring Boot, so it's perfectly ethical, and it's not like anyone using Spring Boot would notice that their application was wasting a bunch of resources.

Maybe someone else did this already. That would explain a lot actually.

Re: The Modern Java Platform – 2021 Edition

#22

Post by jacques_chester »

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 just landed in 16, Project Loom and Project Valhalla are coming over the horizon, plus lots of other niceties that've showed up lately.

Re: The Modern Java Platform – 2021 Edition

#23

Post by codr7 »

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

Re: The Modern Java Platform – 2021 Edition

#24

Post by kaliszad »

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.

You could use Clojure of course and drop to Java for the few performance-supercritical functions if needed (most likely not for like 95%+ of codebases). The productivity and performance may be even better than Python or Ruby. Another positive is, quite a bit of the code can be taken 1:1 and used in ClojureScript if you do back-end and front-end at the same time. (Of course you can program in ClojureScript targeting not the browser but Node.JS e.g. using shadow-cljs which makes working with npm easy.) Also, I haven't spent much time on StackOverflow when programming in Clojure/ ClojureScript because the language is very clear and consistent and usually the documentation and maybe one or two examples there is enough. Or I just play with the function in the REPL for a bit, maybe do a quick (time (dotimes [_ 1e3] (some-function-under-bench))) and dirty benchmark for the more involved stuff.

Clojure is a superpower especially for large codebases because you can maintain your state and ship your adjustments from the editor to the REPL in development which is almost instantaneous. This works for production code also, if you need a very, very quick hot-fix or want to look at live data in the live database without copying possibly confidential data around. Of course, you have to be careful. With great power... and all that.

Re: The Modern Java Platform – 2021 Edition

#25

Post by NOGDP »

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.

If your development productivity is entirely reliant on how quickly you can reload your changes, then you're doing something wrong. Though I guess you'd have to write mounds of unit tests and constantly rerun them to prevent common issues that Java's type system solves for free.

Re: The Modern Java Platform – 2021 Edition

#29

Post by NOGDP »

mberning wrote: post #13
hello_moto wrote: post #10

Earlier quoted context omitted.

In big codebases, people don't change Interface (that's a contract btw) that often. They would do the proper "migration" by offering path to the new contract/api. If you have huge codebase in Python or Ruby, you'll rip your hair more often because it's riskier to make changes (dynamic language) according to your use-case :).

Sure, according to some OO professor. In real life these things change all the time. And it’s not just methods and interfaces that force a recompile, those are just examples. As for dynamic language projects, they should include a test suite to mitigate such issues, but often do not.

A big chunk of the issues you're writing that test suite for, and constantly rerunning, are solved, out of the box, by having a decent type system. The type system also gives you superior code completion (with proper IDE support), which already outweighs any potential reload time costs in Java vs Python/Ruby, for me personally.

Re: The Modern Java Platform – 2021 Edition

#30

Post by galaxyLogic »

The_rationalist wrote: post #14
galaxyLogic wrote: post #12

Earlier quoted context omitted.

It is interesting Java was supposed to be write once run anywhere already some 20 years ago.

You do realize the paradigm shift that enable language polyglotism? It is nothing like WORA

I'm not sure I do. Isn't polyglotism about being able to write in different languages, and Java VM making that possible?
Post reply on HN