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

331–340 of 424 posts

Re: Java 27

#331

Post by troupo »

za3faran wrote: post #306
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…

> 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 relies on properties and provides no facilities for them. Hence the builder pattern instead of object initializers.

In C# object initializers synergize with properties: https://learn.microsoft.com/en-us/dotnet/csharp/programming-...

> The approach they took does not need any extra syntax.

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

Re: Java 27

#332

Post by 946789987649 »

za3faran wrote: post #227
946789987649 wrote: post #178

Earlier quoted context omitted.

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.

Right, but doesn't take away from the fact that Java maintains backwards compatibility and so all these legacy decisions will generally forever exist.

Re: Java 27

#333

Post by pjmlp »

rohan_ wrote: post #172
pron wrote: post #94

Earlier quoted context omitted.

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…

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

If they want to target Android customers, most likely they have to anyway.

Re: Java 27

#334

Post by pjmlp »

adzm wrote: post #286
nitwit005 wrote: post #267

Earlier quoted context omitted.

Until quite recently, the reasonably feature complete open source libraries available for things like DICOM or HL7 were old C/C++ libraries, Java, and C#. That often created a choice between Java and C#. People not doing Windows based development tend not to be interested in C#.

Cross platform C# is certainly getting huge in healthcare and medtech recently though.

Is it? My experience from 2014 - 2018, was that C# was only used in the lifesciences software for Windows, and as wrappers around device drivers mostly written in COM.

Everything that was done on the backend side was done in Java, although there were some exceptions for .NET deployments.

So we ended up with mixed skills teams where depending on the ticket, you would be coding Java or C#.

Re: Java 27

#335

Post by samus »

unscaled wrote: post #254
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.

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…

> 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 (within the same edition) or Go (within the same major version) break less than that.

Java also breaks very few things. Breaking binary compatibility is a no-go since it's a core promise of the platform. The only thing in the surface language that has ever been changed is the meaning of the underscore as an identifier, as well as the behavior of == in upcoming Project Valhalla.

> As far as runtime compatibility goes, Rust and Go apps ship with the runtime.

Java applications can also be shipped together with the runtime.

> Productivity is something that is dead if you are AI-heavy.

Nevertheless, making constructs available to express intent more clearly should also help LLMs to not go off the rails.

Re: Java 27

#336

Post by samus »

unscaled wrote: post #258
munksbeer wrote: post #211

Earlier quoted context omitted.

We have a java monorepo of relatively large size and sophistication, driving our entire fintech, and I haven't seen a NPE for years. Use NullAway and it basically makes the problem go away. Our application won't build if it detects a potential NPE.

Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin. I get it why this seems like a less drastic change, but this saddens me. Kotlin solves more issues with the type system (smart casts, reified types, immutability by default), without sacrificing readability. Un…

> Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin.

You deserve the strawman award of the year.

NullAway and JSpecify encourage making as many types non-nullable as possible, thus they can actually also advice about removing redundant null checks. Nullable types become the painful exception that visibly spreads through the codebase, which discourages writing code that relies on null.

Optional doesn't enter the picture at all. NullAway kills their usecase within ones own code. They are anyway only recommend as return types to force others to check for an emoty case, but I think Optional will become fully optional when the Java platform gets nullable types on its own.

Google Error Prone is a code linting tool that's very useful in its own right, and NullAway is just another plugin.

Re: Java 27

#337

Post by znpy »

okokwhatever wrote: post #209

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

Java is open source and you can get jvm and jdk from other vendors (eg: Red Hat).

You can essentially live all your java life without ever interacting with Oracle.

Re: Java 27

#338

Post by samus »

mahboi wrote: post #235
xdavidliu wrote: post #149

Earlier quoted context omitted.

surely 'throw a npe' means something very similar to something that Go does

It's a panic in Go, not an exception. In practice that's usually a whole process crash. You can catch panics and kinda use them like exceptions, but it's not conventional.

So the whole webserver dies instead of just a worker thread unwinding its stack?

Re: Java 27

#339

Post by liampulles »

za3faran wrote: post #305
liampulles wrote: post #283

Earlier quoted context omitted.

I have a strong belief (mostly borne out by my years as Java dev) that the larger the possibility space of a language (and its ecosystem) the more room there is for inappropriate use and unclear code. Add time and an assortment of rolling devs of mixed ability level, and crap mounts faster then a "simpler" language. Let me be clear: Do I think it is possible to write good, clear, performant code in Java? Of course -…

Golang tried to be simple, but reality hit and they started adding features (generics, and now generics on method, iterators, fixed loop variable scoping). Yet when you program in it, you can feel so much resistance because it took a naive approach to simplicity.

I agree with you, generics reduced the simplicity. Still, better than many alternatives.

Re: Java 27

#340

Post by samus »

unscaled wrote: post #260
za3faran wrote: post #224

Earlier quoted context omitted.

Golang doesn't have solutions like these: * https://jspecify.dev/docs/user-guide/ * https://openjdk.org/jeps/8303099

Sure it does: https://github.com/uber-go/nilaway Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic. I'm not comparing this to "null-restricted types", since that's a draft JEP that hasn't made it even into a preview feature. Go also had multiple proposals for explicit nilability in types, and while they probably have less prospect of ever seeing the light of…

That one works pretty much the same way as NullAway, which is kinda unsurprising because of the name and because of who made it.
Post reply on HN