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

401–410 of 424 posts

Re: Java 27

#401

Post by mrsmrtss »

_the_inflator wrote: post #393
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 worked at a MS "fanboy" company around 2011-2013. Highly competent guys, really Senior Devs, C#, MS SQL, as well as using graph data - with one distinction: it must be MS. Open Source? No way. Git? No, they relied as die hard MS believers on the MS software called Team Foundation or something like that, that was integrated into Visual Studio Pro - sorry, I forgot about it, I considered it kind of bloat and outdated…

JavaScript didn't "win" because it was a good language (it is not), it "won" because it was the only language that ran in the browser.

Re: Java 27

#402

Post by za3faran »

dimaaan wrote: post #368
za3faran wrote: post #303

Earlier quoted context omitted.

Also solved for Java: * https://jspecify.dev/docs/user-guide/ * https://openjdk.org/jeps/8303099

It says: "Status - Draft"

Nullness annotations are already usable. The JEP is for further integration into the type system.

Re: Java 27

#403

Post by za3faran »

jayd16 wrote: post #390
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.

Even in the small list of features in your retort you had to switch to future tense.

Value types are scheduled to be in preview next release (6 months). And C# does not have type classes.

Re: Java 27

#404

Post by za3faran »

troupo wrote: post #331
za3faran wrote: post #306

Earlier quoted context omitted.

> Proper IEnumerable with proper iterators that in turn enables Linq Are you referring to generators? > Properties As far as I'm aware, it is a deliberate choice not to implement them, and I can see their point of view. > object initialisers I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. >…

> Are you referring to generators? Both I guess. Main thing is https://learn.microsoft.com/en-us/dotnet/api/system.collecti... which seems to be everywhere in the language and the library. > I believe the same justification applies here, it's mainly syntactic sugar, and can result in certain undesired behavior by bypassing constructors where validation can happen. This is mostly due language design. Java heavily reli…

> You mean it needs 15 lines whete C# needs one? ;)

Can you elaborate? The async/await approach is much more than 1 line when you need to switch a call between them. Whereas the green thread approach does not need anything.

Re: Java 27

#405

Post by dwaite »

Horffupolde wrote: post #15

Serious question: when should one use Java for greenfield projects in 2026?

Java is still excellent when you need to have software that ships and gets integrated into a customer's environment, or need to support a diverse set of such integrations yourself.

Re: Java 27

#406

Post by za3faran »

dwaite wrote: post #400
za3faran wrote: post #208

Earlier quoted context omitted.

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

That is unfortunately more about adding another edge case for the non-reified Java generics system where it has been forced to partially reify, rather than really addressing the larger complaint.

It should address the most common use case for reification. Type erasure has its advantages which we saw in the JVM ecosystem.

Re: Java 27

#407

Post by dwaite »

pron wrote: post #261
unscaled wrote: post #254

Earlier quoted context omitted.

While Java can outperform Go in some cases, the situation is very much the opposite when it comes to Rust. I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. But we were talking about greenfield projects and newer JDK go EOL much faster. If you want patches, you'll have to run your app to a newer JDK, which may break a couple of things. Rust (withi…

> the situation is very much the opposite when it comes to Rust. It isn't, and the problem isn't Rust specifically, but all low-level languages. They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant. This is for pretty fundamental constraints of low-level language that I mention in another com…

> They can offer very good performance (often better than Java) when small. But as they evolve over time, or are very large to begin with, they become much harder to keep performant.

Generally, efficient memory management is orthogonal to object oriented design. Meaning, as your complexity grows and your business logic changes, it often means the optimal memory management changes because the lifecycle and relationship between objects change.

For a web server for instance, you have both request/response as well as various transactional memory requirements. In Java, the role of the garbage collector is to adapt to whatever the best memory policy is based on runtime behavior, rather than statically defined rules. One could say that the evolutionary and revolutionary changes in garbage collectors as well as the multitude of tuning parameters comes from this being a really hard task.

If you have a services architecture, the runtime advantages of Java go down significantly.

> I wasn't talking about "runtime compatibility" but of overall version compatibility. Java has an unmatched compatibility record.

I would say both matter significantly more again in a monolithic architecture. It matters a lot more when you are trying to deploy your software into a single application server, or trying to avoid version incompatibilities when integrating large amounts of code into a single executable.

> Time and again we see Rust or C++ programs spend 30-50% on memory management.

I've seen plenty of Java applications spend 30 seconds or longer because they had to do a full garbage collection back in the day. I even had one customer who maxed out Java to utilize all the memory in their server and hit a 13 minute production pause due to otherwise unoptimized GC (promoting many temporary transactional objects to the mature generation until it eventually exhausted memory).

The different strategies for memory management (static vs dynamic) ultimately still require recognizing, diagnosing and correcting issues. GC provides unique challenges because the tuning mechanism is decoupled from the actual code. GC challenges can also often go undiagnosed until staging/production workloads hit them, precisely because they are dynamic behaviors.

Re: Java 27

#408

Post by dwaite »

egorfine wrote: post #278
unscaled wrote: post #245

Earlier quoted context omitted.

I'm not sure what enterprise-level collaboration means. In my experience, "enterprise" usually means: "Let's use tools that are 10 years behind, buggier than average, and have lots of half-baked features, none of which we need". I'm not sure what kind of tools you mean, but unless you're looking for something that just works exactly the way EJBs do for some mysterious reasons, I don't see why you can't do most "enter…

> Let's use tools that are 10 years behind Yes and that's exactly what modern tooling is missing. Try to develop for node.js 0.2.12 on today's update of Visual Studio Code. See? No enterprise-level collaboration for ya.

I've found the challenge of running a non-existent version on a tree that was EOL 16 years ago is typically keeping it up with internal security standards, and not one of new collaborative development.

Re: Java 27

#409

Post by the-smug-one »

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

Earlier quoted context omitted.

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

A simplified way (and it is simplified) is that it takes your warmed up ordinary Java JIT JVM and dumps all of the "warmed up" stuff to an archive that's super quick to start. Then you skip a lot of interpretation, etc. You need to run your regular app while recording, in order to get something out of it.

Re: Java 27

#410

Post by pron »

nixon_why69 wrote: post #396
pron wrote: post #374

Earlier quoted context omitted.

When CPU utilisation is low, the heap can be set much smaller. Many don't know that, so in the next year we'll have the VM do it automatically: https://openjdk.org/jeps/8377305 The amount of memory a Java program uses is whatever the setting is, not how much it "needs", because the need depends on the preference of the CPU/RAM tradeoff. But again, not many understand that, so we're making that automatic.

I'm sure both of the cases I'm thinking of could have been tuned better. Just saying that it's a default case that I've seen 2 places land, both of which had a lot of smart engineers following best practices. Maybe its food for thought for you in your position

Yes, this is why we're doing automatic heap sizing :)
Post reply on HN