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

121–130 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#121

Post by wiradikusuma »

TheGuyWhoCodes wrote: post #110
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.

I almost fall into the same trap. Lucky the documentation for reactive approach is very lacking, and I'm lazy, so I stick with traditional approach.

Re: The Modern Java Platform – 2021 Edition

#122

Post by lenkite »

TheGuyWhoCodes wrote: post #110
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.

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

Re: The Modern Java Platform – 2021 Edition

#123

Post by vips7L »

oblio wrote: post #98
The_rationalist wrote: post #4

GraalVM truly has the potential to become the universal, interoperable VM. It would be rational for e.g Julia folks to migrate to the graalVM ecosystem and cotntribute to it instead of living on their small code island. They would get an un inimaginable amount of benefits in the process.

I've never seen or heard anyone major use GraalVM in production. I only hear Oracle and a small bunch of other folks hyping it. Tech also lives on hype and a long time until a tech reaches a critical mass is generally a band indicator (i.e. if something doesn't reach the mainstream in less than N years, it never will). There are some exceptions (Ruby took off after Rails was launched, Python was adopted by Linux dist…

Twitter runs graal in production.

Re: The Modern Java Platform – 2021 Edition

#124

Post by kaba0 »

erikds wrote: post #111
sandGorgon wrote: post #61

Really the future of the Modern Java Platform is Graal - https://www.graalvm.org/reference-manual/embed-languages/ Java is not Spring Boot. For example, this is Python 3.8 compliant runtime on top of Graal - https://www.graalvm.org/reference-manual/python/ You can also compile your application into a native image (like Go?) - https://www.graalvm.org/reference-manual/native-image/ you can try it in the next 5 mins 1.…

Never heard about Graal before. When reading the description it reminds me of WebAssembly. Can anyone compare how they compare?

WebAssembly is lower level with raw memory management, meant primary for running low-level languages in the browser.

Graal instead is a bit more complex to describe, since it incorporates many things. Perhaps the most important part of it is an abstract syntax tree-based interpreter, which can be used to implement a dynamic language with ease, and Graal can basically convert such an interpreter to a language runtime that uses the many many advancements behind the JVM like advanced JIT, GCs and the like. Such an implementation for small languages can easily surpass the “host” runtime in performance, for example R, Ruby.

What makes graal even more interesting is that this intermediate AST is language agnostic, it basically maps the guest language to JVM built-ins — this allows completely polyglot code bases (with JIT compilation between boundaries) and even has an llvm ir-based interpreter because dynamic languages often have C-based standard libs (and since it can inline between deps now, it may be faster than native FFI). But the whitepaper titled One VM to rule them all could give a much better overview than I could.

Since it is primarily a JIT compiler, it can be used as AOT as well.

(Also, there is graal wasm I believe as well)

Re: The Modern Java Platform – 2021 Edition

#125

Post by jlward4th »

kylecazar wrote: post #3

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

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.

Re: The Modern Java Platform – 2021 Edition

#126

Post by blacktriangle »

elric wrote: post #107
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.

This right here, print statement debugging gets far more of a bad name than it deserves. If that's a developers only tool then sure that's a problem, but no need to hate on a very simple and effective technique just because it's often the only one people know when they are starting out.

Re: The Modern Java Platform – 2021 Edition

#127

Post by lmilcin »

I find reactive stuff the best improvement in my productivity since Spring.

I use both RxJava and Reactor, and I sometimes have a one page function that could have been an entire application in the past.

My manager once asked me if we can have a complex endpoint to page data from multiple collections on multiple MongoDB clusters (paging is for backwards compatibility with some clients) and do it efficiently. This requires sorting query results on each of the clusters, then merging the streams of data into a sorted stream and then do that paging manually on the resulting stream. You also need to deal with various error handling and retry requirements.

He asked this 20 minutes before our 1:1 and I had working endpoint before we started it.

Does it have steep learning curve? Sure. But it is totally worth it.

Re: The Modern Java Platform – 2021 Edition

#128

Post by lmm »

hderms wrote: post #112
lmm wrote: post #76

Earlier quoted context omitted.

I disagree with that blog post. It may be technically possible to hijack the classloader mechanism to make instantiating classes do dependency injection, but it's not easy or idiomatic, and it's not good for maintainability either; a reader can't tell the difference between a global service and a value object if both are just "new Foo()". DI, in the sense of separating the instantiation of long-lived service objects…

Which one is the fractal of bad design?

Spring Boot

Re: The Modern Java Platform – 2021 Edition

#129

Post by oblio »

vips7L wrote: post #123
oblio wrote: post #98

Earlier quoted context omitted.

I've never seen or heard anyone major use GraalVM in production. I only hear Oracle and a small bunch of other folks hyping it. Tech also lives on hype and a long time until a tech reaches a critical mass is generally a band indicator (i.e. if something doesn't reach the mainstream in less than N years, it never will). There are some exceptions (Ruby took off after Rails was launched, Python was adopted by Linux dist…

Twitter runs graal in production.

Interesting, their core systems?

Re: The Modern Java Platform – 2021 Edition

#130

Post by throwaway4good »

People are critical of Spring because they have seen it in production and in practical projects. And fall in the naive trap that somehow the tools and the libraries are the reasons why a real-life software project is messy.

However Spring is something that has stood the test of time and is used in thousands of actual projects. And Spring itself emerge out of practical software development with plenty of competing alternatives (Guice, classic J2EE plus many others).

The mentioned alternatives in article: Micronaut and Quarkus are not much beyound the demo state, and frankly based on some questionable ideas: Compile-time dependency injection and idea of "cloud native" - that somehow things run better in the cloud if they are compiled into a binary.

Post reply on HN