Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 26 is here

hanno.codes

Post reply on HN
Print view View original

341–350 of 352 posts

Re: Java 26 is here

#341

Post by deepsun »

gf000 wrote: post #331
deepsun wrote: post #310

Earlier quoted context omitted.

I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).

It's just that Maven doesn't have a good core abstraction and it is not a reliable build system. Like even with base plugins, let alone with additional ones you can't be sure that a build actually picked up every change, you often have to do a double take and do a clean install instead to get some stale files cleared. This should never happen in a build tool and every other feature is secondary to this error. That's…

But it's IDE who picks up every change, not Maven. God forbid you run 'mvn install' for all modules on every line change while developing, that's IDEs job. Maven config just tells IDE locations and dependencies.

For release build you do want to clean up the space in CI/CD anyway.

Not sure what you mean by "doesn't have a good core abstraction". For example, Linux famously doesn't have a good core abstraction (aka "monolithic kernel").

Re: Java 26 is here

#342

Post by gf000 »

deepsun wrote: post #341
gf000 wrote: post #331

Earlier quoted context omitted.

It's just that Maven doesn't have a good core abstraction and it is not a reliable build system. Like even with base plugins, let alone with additional ones you can't be sure that a build actually picked up every change, you often have to do a double take and do a clean install instead to get some stale files cleared. This should never happen in a build tool and every other feature is secondary to this error. That's…

But it's IDE who picks up every change, not Maven. God forbid you run 'mvn install' for all modules on every line change while developing, that's IDEs job. Maven config just tells IDE locations and dependencies. For release build you do want to clean up the space in CI/CD anyway. Not sure what you mean by "doesn't have a good core abstraction". For example, Linux famously doesn't have a good core abstraction (aka "mo…

It's not a good core abstraction for a build tool to not be able to do proper iterative builds. And thus it's not a good model for IDEs neither, while with Gradle it never gets out of sync, with Maven it can easily happen that some edits don't "show up" in behavior.

Re: Java 26 is here

#343

Post by gf000 »

troad wrote: post #340
gf000 wrote: post #330

Earlier quoted context omitted.

Unless you are using a strictly FP language, you are always basically using objects. And all the stuff like factories and everything exist in FP as well, it's pretty short sighted to say otherwise. These are patterns that may or may not be useful in a given case. Sometimes a language feature can replace them (e.g. pattern matching ~ visitor pattern, but not even this is a full match see closed vs open hierarchy), but…

I do mostly use a strictly FP language, but it's trivial to use Java (C#, etc) as FP languages too. Just use classes as stateless function namespaces. FP Java is best Java. > And all the stuff like factories and everything exist in FP as well, it's pretty short sighted to say otherwise. These are patterns that may or may not be useful in a given case. Sometimes a language feature can replace them (e.g. pattern matchi…

I am fairly familiar with FP concepts, though lack experience with large FP-only code bases, so I don't think the OOP-blinder things apply to me.

Visitor pattern is meant to address the other half of the expression problem - you have n types of data all with m behaviors. OOP makes it easy to add a new row (new class) while FP makes it easy to add a new column (new function). But both are asymmetrical, traits a la rust are probably the closest to solving it properly. So no, it is incorrect assumption on your part to hand wave it away, this is not solved (especially not in "FP java", which otherwise I also like and use).

Re: Java 26 is here

#344

Post by gf000 »

Mawr wrote: post #333
pron wrote: post #134

Earlier quoted context omitted.

And Java has some advantages that are hard to beat. It performs better than Go and builds just as fast (at least when not using some popular build tools) while offering unmatched deep, low-overhead observability. People might think they may enjoy another language more, but the portion of people who eventually come to regret choosing Java is probably lower than that of any other language.

> It performs better than Go > and its optimising compiler and GCs blow Go out of the water without breaking a sweat. Well, dandy! Since the performance gap is that big, it should be trivial to get hard data backing that up. Mind linking some representative benchmarks? Dang, I just can't wait, same resource usage for Go and Java (RAM in particular, if you would), and Java performance that "blows Go out of the water".…

> all optimizations

You might want to take a look at what actually happens here. The only reason Go can compile this fast is that it does barely any optimizations. And yeah, javac also does a literal transfomation to Java byte code, no difference here with Go. One will just get a second chance of actually getting optimized via a JIT compiler.

And Java AOT is not doing the same as Go, so again, apples to oranges. It does a complete closed universe build of the program, which requires knowing what classes are ever reachable, and then running their initializers at build time, so they can be burnt into a binary in an initialized state.

There used to be a GNU java compiler doing pretty much what Go did, it's not hard to build, it just wouldn't be compatible with "normal Java", so the use cases would be limited.

Re: Java 26 is here

#345

Post by pregnenolone »

spopejoy wrote: post #274
pregnenolone wrote: post #246

If we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue. The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpac…

TIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ... But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the communi…

> Anyway, is mill worth switching away from Gradle?

Hard to say because I don't know how someone without Scala experience would fare with Mill. Then again, I think anything is better than Gradle. Really, anything. I even think I would do everything by hand rather than using Gradle. Also the creator of Mill is a great guy. Rest assured, if something's confusing or not working he's gonna help you out or fix it if necessary.

Re: Java 26 is here

#346

Post by Tostino »

nameconflicts wrote: post #141

I think Java became popular because of Sun. My experience with Java-based apps is bad. Laggy, resource-heavy, IDE bound, and it causes premature hardware performance degradation.

Heh, you have no idea how many websites you interact with daily are powered by Java backends in that case.

Re: Java 26 is here

#347

Post by fzeindl »

Tostino wrote: post #263
fzeindl wrote: post #245

Earlier quoted context omitted.

That and also the JVM is a marvel of engineering with millions of hours that were poured in by smart people over the last 30 years. It can be as fast a C, supports a multitude of languages, introspection, surveillance etc.

JFR is one of my favorite things about the JVM. Such good tooling to figure out whatever it is you are having problems with in production. I've also used Eclipse MAT to find tricky dangling references to objects that caused memory leaks. Definitely not as polished, but extremely useful.

I agree JFR is amazing.

Also that you can start it on a running JVM and it that is has minimal ~1% performance overhead.

Re: Java 26 is here

#348

Post by lucyjojo »

owlstuffing wrote: post #336
gf000 wrote: post #326

Earlier quoted context omitted.

And a fat runtime with a garbage collector. Like people can write all sorts of programs with a GC, that was never the issue. But then just stay truthful, otherwise C# is also a system PL.

"Fat" runtime? Go? Nah. Go's runtime is thin: goroutines, a GC specialized for concurrency, networking, and little else. Java, by contrast, assumes a JVM plus massive stdlibs to handle everything from enterprise apps to big-data, making its platform genuinely "fat" and layered. Other Java-tier languages, C# included, follow the same model.

java has had profiles for an eternity and multiple jvm implementation. it can get really really thin.

also has modules now.

Re: Java 26 is here

#349

Post by dinkumthinkum »

munksbeer wrote: post #335
dinkumthinkum wrote: post #190

Earlier quoted context omitted.

> This makes no sense to me. If AI possesses intelligence then it should have no problem learning how to use a new language. If it doesn't possess intelligence, we shouldn't be outsourcing all of our programming to it. Perfection. You have made such an excellent. However, I don't want to detract from that but it's like, in reality, this is a completely obvious point but because of this AI/LLM brain-rot that has taken…

> this is a completely obvious point but because of this AI/LLM brain-rot that has taken over the software programmer community This is really insulting. I think you're wrong, AI agent programming is very good now, and you will have to admit it at some point.

Insulting to whom? Are you anthropomorphizing LLMs. Also, you think it is insulting it is a bad idea to complete outsource software development to it. If that’s the case then being insulting sounds like a good thing.

Re: Java 26 is here

#350

Post by munksbeer »

dinkumthinkum wrote: post #349
munksbeer wrote: post #335

Earlier quoted context omitted.

> this is a completely obvious point but because of this AI/LLM brain-rot that has taken over the software programmer community This is really insulting. I think you're wrong, AI agent programming is very good now, and you will have to admit it at some point.

Insulting to whom? Are you anthropomorphizing LLMs. Also, you think it is insulting it is a bad idea to complete outsource software development to it. If that’s the case then being insulting sounds like a good thing.

>Insulting to whom? Are you anthropomorphizing LLMs.

Obviously not. Insulting to programmers who use them, hence I object to the term "brain-rot". Clearly the insinuation is we're just suffering from brain rot.

Post reply on HN