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

311–320 of 424 posts

Re: Java 27

#311

Post by samus »

vlovich123 wrote: post #56
cogman10 wrote: post #43

Earlier quoted context omitted.

There's not really a second C# runtime. Java has several, some based on the Openjdk, but a few that are completely new like OpenJ9 and Graal. The closest C# has is mono. This sort of thing is bound to happen with that situation. Heck, it happens with C++ whenever a new C++ version comes out. Some C++11 features took years to make their way into all the compilers.

Graal is based on OpenJDK. OpenJ9 while using a separate JVM and JIT leverage the openjdk class path as well as the build environment and various other things. I don’t think there’s a single alternate implementation that doesn’t leverage a good chunk of openjdk somehow

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

Re: Java 27

#312

Post by gf000 »

AgentME wrote: post #276
za3faran wrote: post #208

Earlier quoted context omitted.

This should address your example https://openjdk.org/jeps/218

That's about letting you do Expression , not about removing type erasure or otherwise allowing overloads based on type parameters.

It's one end of the same problem.

int is not an Object, so just erasing is no longer a valid approach, you need to specialize the class/method itself to use int-specific byte code.

Re: Java 27

#313

Post by nixon_why69 »

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…

A couple data points, I like Java but I've seen metrics of container fleets at multiple companies that were memory constrained with low CPU usage sitting around underutilized. The reason in both cases was a bunch of memory-heavy yet CPU-efficient Java processes.

Re: Java 27

#314

Post by gf000 »

theandrewbailey wrote: post #16
moomin wrote: post #5

C# dev here: it’s amazing how different this is from a Microsoft release. First off, Oracle are doing versions at approximately twice the cadence. But also, and I’m guessing this is a function of the much larger Java audience: things rarely get two preview versions in a proper release. Updates in beta versions, yes, all the time. It also feels like Microsoft are bundling a lot more into the platform and leaving less…

I never thought of Java being the 'move fast ~and break things~' alternative over .NET, but Java has a faster release schedule to get features out sooner.

It's pretty much the opposite.

A fixed release schedule makes development more relaxed so it can be properly done, no need to rush for some release date.

If it's not yet ready, there is 6 more months to get it merged.

Re: Java 27

#315

Post by gf000 »

troupo wrote: post #268
za3faran wrote: post #221

Earlier quoted context omitted.

Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.

Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn…

At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features.

That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do.

(And then there is also Go that falls off the other edge of the cliff with useless if err checks spamming the code making actually functioning error handling hard)

Re: Java 27

#316

Post by gf000 »

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…

Actually, javac itself is plenty fast, pretty similar to Go's (it also barely does any optimization)

It's usually the build systems that add quite some overhead.

Re: Java 27

#317

Post by gf000 »

someone_19 wrote: post #272
pron wrote: post #251

Earlier quoted context omitted.

> Which specific optimizations are you referring to? A JIT with speculative optimisation and a moving GC. There are two constraints in low-level languages that trump any of their performance goals, one technical and one a matter of preference. The technical limitation is that they must use stable pointers (because they need to be low-level and so having an FFI layer that separates "hardware pointers" from "language p…

Thank you for the reply. Do you mind a reasoned discussion? > A JIT with speculative optimisation and a moving GC. Idiomatic Rust, through its concepts of ownership and borrowing, encourages a pattern where you receive data as an argument or create it directly, perform operations on it, and then discard it via RAII. This bears some resemblance to functional programming. This approach does not apply to buffers of unkn…

> The stack is definitely faster than anything else

I have seen it mentioned everywhere, but is this actually true?

I mean, of course it is faster than random cold memory, but is it actually faster than a hot, in-cache part of the heap? It is not special in any other way, AFAIK.

And for what it's worth, what pron mentioned, Java uses a pretty similar structure for initial allocation, a thread local buffer where you just pointer bump. Another thread can then in the background copy still alive objects from this "arena" and then reset the whole thing.

Re: Java 27

#318

Post by gf000 »

unscaled wrote: post #310
pron wrote: post #293

Earlier quoted context omitted.

> Rust is just as ergonomic as any other popular language today if you're using an agent Have you worked on large (>500KLOC) codebases with an agent? Not only do you have to be an expert at the language, but even if you're lucky and everything is fine, Java code is likely to be particularly fast by comparison, because the agents aren't very good at manual optimisation, especially as the code grows (they're even worse…

Have you worked on large (>500KLOC) codebases with an agent? Yes. But keep in mind KLOCs are not easily comparable across languages. Java is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust. If your argument is that large codebases makes life harder for agents, you should go with a less verbose language. I'm not sure what "manual optimization" means (isn't it a bit of an oxymoro…

> is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust

Lol, no way. Especially that rust is pretty verbose all things together (which makes sense, given it's a low level language - ergo you have to literally express more things about the code)

Re: Java 27

#319

Post by gf000 »

what_hn wrote: post #111
winrid wrote: post #95

Earlier quoted context omitted.

I have a couple 50k+ loc java projects written entirely by LLMs at this point that have never thrown an NPE.

Same here with go, then Again go doesn't throw!

It just swallows errors, so you don't even know about it!

Re: Java 27

#320

Post by samus »

troupo wrote: post #268
za3faran wrote: post #221

Earlier quoted context omitted.

Which features exactly? Java got exhaustive pattern matching before C# (through sealed interfaces), it has switch expressions, multi-line strings, green threads and structured concurrency, is getting value types, and even type classes in the work.

Granted, I havent' used either for a couple of years, so my knowledge is a little rusty. Yes, some of them are "just syntax sugar", but man oh man does it make C# such a pleasant language to work with. Used to work at a company which had services both in Java and C#, so some of Java's decisions or indecisions felt like pain points when switching between the two: - Proper IEnumerable with proper iterators that in turn…

> - object initialisers

Probably not a good idea since they break encapsulation by exposing internals of the class. There is work on withers, which should make defining builders far simpler.

> - extension methods.

They make code harder to understand. If they ever come they would have to be declared at the top of each source file.

> - null coalescing operator

Maybe we'll get it, maybe not, but they want to first introduce proper nullable types, lest there is a risk of painting themselves into a corner.

> - async/await

There is a fork in the road, and Java has gone into the direction that leads to virtual threads and Structured Concurrency, for the simple reason that there is no simpler syntax than plain old synchronous code.

> - ... generics metadata in runtime

There are plans to add a kind of reified generics, so maybe we'll get it.

Post reply on HN