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

361–370 of 424 posts

Re: Java 27

#361

Post by troupo »

samus wrote: post #320
troupo wrote: post #268

Earlier quoted context omitted.

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

> Probably not a good idea since they break encapsulation by exposing internals of the class.

And thousands of manual get/set functions don't?

Thousands of lines of builders don't?

Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

> for the simple reason that there is no simpler syntax than plain old synchronous code.

But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and...

Java always opts out for "let the developer handle all the complexity all the time even for the simplest most used parts of the code".

Re: Java 27

#362

Post by [deleted] »

chasd00 wrote: post #189
rohan_ wrote: post #172

Earlier quoted context omitted.

This is quite the take - i doubt most startups building in these spaces are using Java.

i can't speak to the others but banking and healthcare is virtually all java top to bottom. The big healthcare EMR/EHR systems are Java and every bank i've ever worked with (i use to do a lot of integrations with the big banks) was all Java. I have friends in those areas and whenever they start up a new project it's still always Java since that's where their skills are and what's on the "approved tech." list.

[deleted]

Re: Java 27

#363

Post by someone_19 »

gf000 wrote: post #317
someone_19 wrote: post #272

Earlier quoted context omitted.

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

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

Yes, it just adding or subtraction int to stack pointer register. I’m not certain, but the only thing that might be faster is accessing data at a fixed address - that is, global variables.

Re: Java 27

#364

Post by gf000 »

troupo wrote: post #361
samus wrote: post #320

Earlier quoted context omitted.

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

> Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of lines of builders don't? Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > for the simple reason that there i…

> And thousands of manual get/set functions don't?

By definition, they don't.

They are verbose and hard to maintain, but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you.

> But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and...

No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds

Re: Java 27

#365

Post by liampulles »

tpoacher wrote: post #341
liampulles wrote: post #285

Earlier quoted context omitted.

Also - and this is very subjective - I find developers who have similarly low view of software development and high view of simple languages, to be very good team mates. We can laugh at the realities and move on pragmatically.

I see. I tend to agree in principle. I felt this with julia for example and it put me off a bit even though I was very keen on it at first In the specific case of java however I don't think this applies much; the vast majority of improvements are aimed at under the hood optimisations rather than syntax. And I feel that any changes in syntax have been quite incremental, intuitive, and reasonable. AND they stay around…

Fair.

Re: Java 27

#366

Post by robertlagrant »

PaulHoule wrote: post #201
hirvi74 wrote: post #79

Earlier quoted context omitted.

> Python and especially JS ecosystems it's so much better. That's a pretty low bar to beat.

10 years ago I was working at a place that was building Python systems that had dependency graphs too complicated for pip to handle. I was able to solve the problem for my system with a "wheelhouse" system that could compute a list of wheels that could be installed to build it but the confidence of my team in Python had flagged. I had a sheaf of notes about the problem and figured out the math to build a proper depen…

Before uv came along, pipenv, Poetry, and (much older) Conda all were trying to solve this problem. It's a huge problem for Python that not all languages experience, because Python packages can contain all sorts. At one point if you wanted to install Scipy you had to drag in (and compile, if I remember correctly!) Fortran, of all things[0].

[0] https://stackoverflow.com/a/14822245/61938

Re: Java 27

#367

Post by wolvesechoes »

pron wrote: post #94
Horffupolde wrote: post #15

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

These days, Java is mostly used in greenfield software that has to be very reliable, very performant, and last for many years. So it's often the first choice for banking, telecom, finance, government, defence, manufacturing control, logistics and shipping, media streaming, retail, hospitality, healthcare etc.. It's usually not a first pick for more exciting software, such as Python type checkers, JS bundlers, or TUI…

First, I like reading your comments, as they are pretty illuminating, also in the way they expose how superstitious programmers can be.

Second, I wonder where, roughly, would you put a transition from small programs where low-level langs are fine, to programs large enough to heavily benefit from JVM tradeoffs? And how this transition is affected by a stuff like Graal Native?

Re: Java 27

#368

Post by dimaaan »

za3faran wrote: post #303
dimaaan wrote: post #217

Earlier quoted context omitted.

Null pointer dereference problem. Solved for greenfield C# projects and Kotlin

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

It says: "Status - Draft"

Re: Java 27

#369

Post by troupo »

gf000 wrote: post #364
troupo wrote: post #361

Earlier quoted context omitted.

> Probably not a good idea since they break encapsulation by exposing internals of the class. And thousands of manual get/set functions don't? Thousands of lines of builders don't? Object initializers are that plus much better handling of fields/properties that doesn't require hundreds of lines of tedious manual code: https://learn.microsoft.com/en-us/dotnet/csharp/programming-... > for the simple reason that there i…

> And thousands of manual get/set functions don't? By definition, they don't. They are verbose and hard to maintain, but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you. > But it's not synchronous code, is it? It's easily dozens of lines wrangling Futures, and Thread initialisers, and Executors, and... No, it's done under the hood by the JV…

> but if ever in the future you would want to keep the same API surface but change the internal implementation detail, they let you.

So do properties in C# which object initialization relies on. With significantly less manual code, or the need for tedious builder chains and withers.

`{ prop = x }` is no more encapsulation breaking than ` .setProp(x) `, but actually makes developer experience better.

> No, it's done under the hood by the JVM. You only ever see a blocking call on a new "thread", via debugger via everything. Best of both worlds

What's Java's equivalent of

   x = await someFunction()
   await waitForSomeOtherFunction()

Re: Java 27

#370

Post by someone_19 »

pron wrote: post #289
someone_19 wrote: post #272

Earlier quoted context omitted.

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…

> However, such optimization is theoretically possible. The stack is definitely faster than anything else. What you're describing isn't a stack, but an automatic arena, and this optimisation is easier to do in Java. It's easier to do in Java because it requires setting a "current arena" or inlining, both of which Java can do more easily, and then either the arena will be heap allocated (which will be slower in Rust)…

> Assembly (which is faster than anything in the same sense: for any program in any language, there exists and Assembly program that's at least as fast)

At least you aren't claiming that the JVM is ~1.5 faster than perfectly written assembly :)

I disagree with a lot of what you’re writing. However, we’ve reached the point where we need to run benchmarks and analyze the generated code (this is easy to do for compiled languages using https://godbolt.org/, but for the JVM, it can be a bit more complex, given the warm-up factor).

So, there is one fundamental point I started with:

> JIT is effective for languages where the source code lacks sufficient information (dynamic typing, where anything can be null)

And your answer is:

> A JIT can make such languages decently fast, but that's not how it's used in Java. In Java it is used for speculative optimisation, which allows far more aggressive optimisation than an AOT compiler can do.

Essentially, you are saying that the compiler can apply aggressive optimizations when it knows what is happening in the code.

But I say that JIT is needed so the compiler can figure out what is happening in the code and perform aggressive optimizations.

There are many things that can be inferred from the code without needing to execute it. The question is how difficult it is to make such an inference: in one scenario, the compiler might attempt to track whether specific data changes-and, if it can prove this, mark the data as immutable and apply certain optimizations-whereas in another, it might already possess the information that the data is immutable.

Moreover, information about immutability is useful not only to the compiler but also to the programmer. Just like information about types: it benefits both the compiler and the programmer. Imagine a fan of JS or Python joining our conversation and claiming that both Java and Rust are low-level languages because you have to specify types - something they view as complex and a hindrance to development speed.

The same applies to the GC: the compiler can perform more optimizations when it knows when memory needs to be cleared (move it to stack or even place the data on registers). The JVM attempts to do this (via escape analysis), but there are limitations; consequently, data ends up on the heap, and GC operations come at a cost (due to data movement).

Rust simply makes it easy to obtain far more information, enabling aggressive optimizations that are both immediate and guaranteed.

There remain a small number of cases, such as `switch` statements - where one branch executes 99% of the time, while the other 99 branches execute only 1% of the time. In such instances, the JIT could indeed perform further optimizations; however, I am not even sure if the overhead of monitoring wouldn't outweigh the benefits. And the question is when and how to perform PGO, or whether to perform it at all.

Post reply on HN