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

Java 27

mail.openjdk.org

Post reply on HN
Print view View original

351–360 of 424 posts

Re: Java 27

#351

Post by Capricorn2481 »

misiek08 wrote: post #150
pron wrote: post #101

Earlier quoted context omitted.

They lack in performance, stability (compatibility), observability (telemetry), productivity, or some combination thereof. They are chosen, of course (especially C#; Go and Rust are far behind), but not as much as Java.

Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying. As to Rust - we all, hopefully, agree that it’s great language, but not for some startup making websites or Mongo based, boring backends. It’s great for the stable, system level products.

> Saying that Go lacks in those is just showing how people are making software those days. It’s just terrifying

I'm not following. Saying Go lacks in X shows how poor other software is? Can you connect the dots?

Re: Java 27

#352

Post by samus »

pjmlp wrote: post #325
samus wrote: post #311

Earlier quoted context omitted.

For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.

Up to a point. Embedded systems versions tend to have their own ways, which is why despite everything Android using Dex isn't a first in the Java ecosystem.

IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.

Re: Java 27

#353

Post by Capricorn2481 »

wk_end wrote: post #228
pron wrote: post #156

Earlier quoted context omitted.

It's disclosed right there in my profile (I don't see your professional affiliation disclosed in your comment; or your profile, for that matter). Of course, I, like other runtime and compiler people, joined the Java team because we wanted to work on the most advanced compiler and runtime tech. I perfectly understand people who want to work on smaller, newer, potentially insurgent products, but I took the chance to wo…

GP's snark is unwarranted, but it's probably good practice to disclose your professional affiliation explicitly in comments related to it, even if you have already disclosed it in your profile. I was reading your comments on Java, nodding my head, upvoting, without checking your profile and realizing that you're a member of the Java team. Knowing that doesn't mean I now suddenly disagree with you or anything. But whi…

> I'd like to turn up my internal sense of skepticism when dealing with someone, effectively, selling something their salary depends on

This is really, really silly. Java is many times beyond the position where its developers need to desperately convince people to use it. This is a person who has unique technical expertise in the area whose credentials are smack dab on their profile, not hidden from you. Their closeness to the domain at hand should make you less skeptical of what they are saying.

Re: Java 27

#354

Post by pjmlp »

samus wrote: post #352
pjmlp wrote: post #325

Earlier quoted context omitted.

Up to a point. Embedded systems versions tend to have their own ways, which is why despite everything Android using Dex isn't a first in the Java ecosystem.

IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.

Lots of "improvements" on Dalvik over J2ME was Google's marketing to sidestep Sun, speaking as ex-Nokia, coupled with the experience of Java on Symbian devices and Sony Ericson.

All these years afterwards it quite clear that there is just similar fragmentation, and implementation differences between all OEMs selling every kind of devices, and as you say the format doesn't really provide that much benefits.

What ART has going for it, are all the improvements they started on Android 7 and later, by having a mix of handwritten interpreter in Assembly, JIT compiler with cache, AOT compilation with the device on idle, and sharing of PGO metadata via the PlayStore across devices.

Ironically Windows Phone did it first, with MDIL on Windows Phone 8 followed by .NET Native on Windows Phone 10, using compilation via the Windows Store, but Microsoft fumbled the delivery.

Re: Java 27

#355

Post by zozbot234 »

pron wrote: post #255
p2detar wrote: post #232

Earlier quoted context omitted.

I use Java every day but just to point out that your info about Go‘s GC seems out of date. They switched to Green Tea in 1.25 (I think?) - new GC that even has AVX-512 optimizations. Not sure what you mean by basic about the compiler but it‘s very fast and supports a large set of platforms. That‘s not basic to me. We are using JDK25 and are considering rewriting parts of our product to Go because of lower memory pres…

> I use Java every day but just to point out that your info about Go‘s GC seems out of date. I'm well aware that Go's GC has improved, but the moving algorithm was designed not just to be fast for a GC, but to be faster than no GC. So Go's new GC is good - for a mark and sweep collector. But it can't compete with a moving collector (the only thing that can is arenas, which are user-friendly only in Zig). > We are usi…

CPU utilization is a red herring. Unless you're doing heavy number crunching (which these days heavily favors GPUs) the practical bottleneck on CPU utilization for large general purpose programs (especially when spanning multiple cores) is memory bandwidth. And moving GC is terrible for memory bandwidth compared to both Go-style concurrent GC (which doesn't have to do bulk moves) and manual memory management.

Re: Java 27

#356

Post by p2detar »

the-smug-one wrote: post #257
p2detar wrote: post #232

Earlier quoted context omitted.

I use Java every day but just to point out that your info about Go‘s GC seems out of date. They switched to Green Tea in 1.25 (I think?) - new GC that even has AVX-512 optimizations. Not sure what you mean by basic about the compiler but it‘s very fast and supports a large set of platforms. That‘s not basic to me. We are using JDK25 and are considering rewriting parts of our product to Go because of lower memory pres…

Go's compiler is fast because it doesn't do as many advanced (read: computationally expensive) optimizations as other compilers do. No clue about Green Tea and how awesome it is :-). Lower memory pressure is certainly a difficult thing to beat Go at, Java (OpenJDK) is probably never gonna get there. You get a lot of other stuff, like better peak performance, instead. Btw, have you tried Leyden/AOT for better startup…

> Btw, have you tried Leyden/AOT for better startup times? Curious about your experiences with that.

Nope, not yet. It's a good question given that up to now we used to deliver our product only on-premises and Windows Server-only, but this year we are now finally going with the Cloud, which means Docker containers and Linux.

If I remember correctly Leyden required some sort of warm-up and training data collection before being able to effectively execute AOT, right? I need to freshen up my info on that.

I did try GraalVM-compiled Java executables a couple of years ago and they were not bad, but the binaries were quite big (not a showstopper though) and the class-loading issues were kind of a PITA.

Re: Java 27

#357

Post by Good4boothee »

okokwhatever wrote: post #209

Love Java vs Hate Oracle... My life is a shit show

I mean, thanks to crazy data center over-investment there is real chance that Oracle will need to sell some of their assets. Somehow I can't imagine many potential buyers that would be a good custodian of Java.

Re: Java 27

#358

Post by Good4boothee »

Not a fan of JEP-531, looks the repeat of Optional. Are we really so afraid of extending syntax that we are going to add a class instead of field modifier?

    private static final Logger log = Logger.getLogger(Whatever.class);
This was already verbose enough that Lombok has @Log4j for it, adding `lazy` keyword in front of `final` won't make it any worse.

Re: Java 27

#359

Post by gf000 »

unscaled wrote: post #307
t0mas88 wrote: post #26

Earlier quoted context omitted.

When building boring web applications with a sizeable team that need to run for a long time. Hiring developers is easy since there are many, there is nearly no magic and the language is quite strict and type safe so it works well with a large team. And that "team" nowadays may also consist of many AI agents. In my experience Claude Code for example works very well with a typed, slightly boring language with lots of f…

> Hiring developers is easy > And that "team" nowadays may also consist of many AI agents. And that's the part where the hireability arguments collapse. Sure Claude Code works pretty well with Java. It also works well with Typescript, Python, Go and Rust. It would use types on all of these languages, and run a type checker or LSP on the dynamic ones. And while Java is statically typed, Rust has a stricter type system…

> data races

Which are completely safe in Java

> Forgetting to release a resource

I know what you mean and it's definitely a tongue in cheek reply but it's almost like that's what the GC is made for :D bit less sarcastically java has Cleaners, and try-with-resources are a poor man's RAII

Re: Java 27

#360

Post by troupo »

samus wrote: post #330
troupo wrote: post #271

Earlier quoted context omitted.

Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java. That's why you get `new List { };` Because it could be `new ComplexObject { }`. Same for `new`. Some come from type inference which Java also has. That's why you can have `List foo = new List ();` and `var foo = new List ();` It's not really "7 ways to assign a new empty List ". It's "7 ways to create an object",…

> Some of those ways come from just plain object initialisers. Which are amazing and sorely needed in Java. They really aren't, and they are IMHO an antipattern since they break encapsulation. One might argue that encapsulation doesn't matter with mere data classes, but Java will cater to that use case by introducing withers.

> They really aren't, and they are IMHO an antipattern since they break encapsulation.

They don't. Java had to come up with the extremely verbose builder pattern for the exact same thing. And withers are basically the same tedious manual builder pattern, just with a different name.

For withers C# just has the with keyword: https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

Post reply on HN