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

71–80 of 259 posts

Re: The Modern Java Platform – 2021 Edition

#71

Post by elygre »

hans0l074 wrote: post #66

When I use developer tooling in other platforms I’m usually disappointed. I shouldn’t need some special native library installed on my system so I can install a dependency. It shouldn’t take me hours to get my local developer toolchain set up. I found this comment odd - it does take some time to get a modern Java dev env up and running from scratch. For e.g. you have to at least download/install gradle or maven after…

The Gradle wrapper is how you let gradle download itself upon first execution. It stays in your git-repo, and then you don’t need to install gradle yourself.

https://docs.gradle.org/current/userguide/gradle_wrapper.htm...

Re: The Modern Java Platform – 2021 Edition

#72

Post by cromwellian »

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.

From that article "and produces smaller JavaScript that performs better in the browser".

Not according to my benchmarks. That may be true if you use the GWT Widget library, but if you code 'to the metal' using Elemental, GWT produced substantially smaller code than TeaVM when I benchmarked it a few years ago with the Bench2D (Box2D) benchmark. Maybe it got better since then, but I doubt it given the progress GWT's successor made. Using J2CL (the successor to GWT), the following Java class

public class Main { public static void main(String argv[]) { window.alert("Hello World"); } }

would actually compile down to just (JS)

window.alert("Hello World")

TeaVM doesn't support code splitting that Both GWT and Closure Compiler support, or cross-module code motion.

https://github.com/konsoletyper/teavm/issues/333

Re: The Modern Java Platform – 2021 Edition

#73

Post by avodonosov »

beachy wrote: post #65
avodonosov wrote: post #44

Earlier quoted context omitted.

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…

Was "boolshit" a typo or is it a magnificent new pejorative?

Typo :)

Re: The Modern Java Platform – 2021 Edition

#74

Post by oblio »

strictfp wrote: post #58
sz4kerto wrote: post #54

Earlier quoted context omitted.

There's a very good reason why Spring is used so widely. Complex enterprise apps are often complex because the use case and the environment is complex. E.g.: - integration testing and unit testing is required - transparently pluggable backends for message queues so that locally you can use SQLite as your pub/sub storage but in production it's Google P/S - standardized health check endpoints for all your apps ... The…

Enterprise apps are complex because they don't focus on solving the business problem, they focus on the tools and frameworks. Spring is not the cure, it's the disease.

Enterprise apps are super complex, frequently a lot more complex than startup apps.

Someone basically comes with 1 thick tome worth of business knowledge plus 1 thick tome worth of legal restrictions and you're supposed to codify all of that, to the letter, in software. Some of the business logic can make you cry.

Software dev: "But that's not clean/elegant".

Business owner: "Reality doesn't care about elegant/clean, it cares that we build stuff our customers want and that won't get us sued, so we have to implement it to the T".

Re: The Modern Java Platform – 2021 Edition

#75

Post by oblio »

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.

Why does Go need explicit pointers?

Re: The Modern Java Platform – 2021 Edition

#76

Post by lmm »

_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…

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 from the classes containing business logic that accesses those long-lived service objects, is a great thing for testability and maintainability.

Autowiring mechanisms where you have some kind of global bag of (pseudo-singleton) services by type, and wire service dependencies implicitly by type rather than explicitly, are a legitimate tradeoff that's appropriate for some cases.

Don't conflate Spring with Spring Boot. One is a framework that offers some legitimate value even if it makes some questionable tradeoffs; the other is a fractal of bad design.

Re: The Modern Java Platform – 2021 Edition

#79

Post by kaba0 »

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

What is more impressive is the graaljs implementation, that when warmed up, has comparable performance to god damn v8. All that with a complete polyglot runtime, so you can call python code from js and vice versa and the best part: it will inline and JIT compile over language boundaries. Also, truffleruby (graalvm’s ruby implementation) is/was two times faster than regular ruby - that’s how much engineering went into the JVM.

And of course well-performing (but worse than JIT) AOT compilation is also a possibility with it, though I feel it is not needed as often as people think.

Re: The Modern Java Platform – 2021 Edition

#80

Post by hans0l074 »

elygre wrote: post #71
hans0l074 wrote: post #66

When I use developer tooling in other platforms I’m usually disappointed. I shouldn’t need some special native library installed on my system so I can install a dependency. It shouldn’t take me hours to get my local developer toolchain set up. I found this comment odd - it does take some time to get a modern Java dev env up and running from scratch. For e.g. you have to at least download/install gradle or maven after…

The Gradle wrapper is how you let gradle download itself upon first execution. It stays in your git-repo, and then you don’t need to install gradle yourself. https://docs.gradle.org/current/userguide/gradle_wrapper.htm...

But surely if you are starting off you need to install/initialize the wrapper itself, no? From your link,

Generating the Wrapper files requires an installed version of the Gradle runtime on your machine as described in Installation. Thankfully, generating the initial Wrapper files is a one-time process.

Post reply on HN