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

221–230 of 424 posts

Re: Java 27

#221

Post by za3faran »

troupo wrote: post #162
theandrewbailey wrote: post #16

Earlier quoted context omitted.

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.

> Java has a faster release schedule to get features out sooner While still being behind on most features?

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.

Re: Java 27

#222

Post by saghm »

ndriscoll wrote: post #202
saghm wrote: post #187

Earlier quoted context omitted.

I don't disagree, but that sounds more like a response to the person asking "what's the argument for picking Java?" than one to the someone who finds "Have you tried not returning null or constructing incomplete objects?" and "Why don't you have any coding standards?" to be poor takes.

If someone's asking "why Java" or is saying nulls make it a hard no, then you'd assume that they have a choice in the first place, which generally means they also have some ability to set coding standards at the same time that they're choosing a language. Scala technically allows you to use nulls or throw exceptions pretty much wherever (necessary for Java compatibility), but it's not an issue because people simply d…

> If someone's asking "why Java" or is saying nulls make it a hard no, then you'd assume that they have a choice in the first place, which generally means they also have some ability to set coding standards at the same time that they're choosing a language.

I don't understand that logic. I sometimes ask people to explain why they think a certain policy should be implemented by the government after they state their support for it, but I don't have the ability to set government policy. I have trouble imagining you genuinely assume that any time someone asks you why something should be the way you say that you think they have the ability to change it if you convince them.

Re: Java 27

#223

Post by kilink »

theandrewbailey wrote: post #72
BoppreH wrote: post #44

Earlier quoted context omitted.

> there is nearly no magic I agree with the rest, but there's definitely a lot of magic in Java. This is from both what features the languages makes available (many) and how the community uses them (often). I've had so many hard-to-debug issues in Java over the years due to reflection, annotations, and bytecode manipulation shenanigans. And another positive point for Java: checked exceptions. It's verbose, but knowin…

> but knowing exactly in which ways a function can fail is extremely helpful for building robust applications I've worked on Java apps that have failed in mysterious ways that no exception could explain. Meanwhile, the overhead of having to call out certain exceptions but not others in language syntax is a bit excessive. For example, decoding a byte array (or URL encoded form field) into a UTF-8 string means handling…

That's less of a thing nowadays if you use the newer APIs that accept Charset instances instead of the charset name as a String.

Re: Java 27

#224

Post by za3faran »

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!

Golang doesn't have solutions like these:

* https://jspecify.dev/docs/user-guide/

* https://openjdk.org/jeps/8303099

Re: Java 27

#225

Post by wk_end »

doublepg23 wrote: post #220
chasd00 wrote: post #189

Earlier quoted context omitted.

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.

in my healthcare experience (claims processing, medtech) Java existed for sure but it was always as a "legacy" system they were moving away from.

What were they moving towards?

Re: Java 27

#226

Post by za3faran »

dorkypunk wrote: post #20
Horffupolde wrote: post #15

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

When you are already familiar with it or work in a Java shop, there are better options if you are starting from scratch, but if you already have 50 guys that know Java it's a pretty big ask for all of them to switch.

What better options are there if starting from scratch? The only thing IMO that comes somewhat close is C# for general backend systems.

Re: Java 27

#227

Post by za3faran »

946789987649 wrote: post #178
mikert89 wrote: post #147

Earlier quoted context omitted.

I think Java took all the best features of kotlin

but still has all the historic bad decisions of itself

Many of those are getting addressed. Value types are in the works, generics specialization for primitives, and even type classes.

Re: Java 27

#228

Post by wk_end »

pron wrote: post #156
Mawr wrote: post #154

Earlier quoted context omitted.

Yeah I mean he literally works on Java at Oracle, so may just be a little biased. Doesn't bother to disclose it of course, because what, you don't check everyone's profile in every discussion to make sure they're not biased? What, you don't just know who every user on this site works for? You dummy you :)

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 while in an ideal world it doesn't matter who's saying something when evaluating it, there's some human factors at play - I'd like to turn up my internal sense of skepticism when dealing with someone, effectively, selling something their salary depends on; even if you're being entirely earnest, it's ultimately a sales pitch, and I feel bamboozled for not recognizing it - that'd make me appreciate transparency.

(FWIW, even though I prefer being coy about my place-of-work, I have no professional relation to this conversation. I've never used Java in my 9-5 and I haven't even really used it in earnest since, like, version 5 back in high school. I think it's always been underrated by the hacker crowd, though!)

Re: Java 27

#229

Post by doublepg23 »

wk_end wrote: post #225
doublepg23 wrote: post #220

Earlier quoted context omitted.

in my healthcare experience (claims processing, medtech) Java existed for sure but it was always as a "legacy" system they were moving away from.

What were they moving towards?

claims processing - TypeScript, lots of ETL tools with Go.

medtech - .NET and TypeScript.

Re: Java 27

#230

Post by stickfigure »

Horffupolde wrote: post #15

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

Often? It's a relatively modern language with enough functional programming features to keep mid-high blub programmers happy. Yeah there's cruft; all mature languages have cruft.

Kotlin is the obvious replacement, but the tooling isn't as good and the community isn't as large. Java keeps getting better, and in ways that diverge from Kotlin - eg, virtual threads vs async/await/coloring. From the perspective of language design, I prefer Kotlin. But I keep picking Java anyway, and I don't see that changing soon.

Go is openly hostile to functional programming. Dynamic languages aren't even in the running. Rust is too low-level for line-of-business software. C# is too Microsoft. The remaining alternatives are too obscure.

Post reply on HN