Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 26 is here

hanno.codes

Post reply on HN
Print view View original

301–310 of 352 posts

Re: Java 26 is here

#301

Post by troad »

pjc50 wrote: post #255
troad wrote: post #238

Earlier quoted context omitted.

> It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yourself. The first domino is opting for OOP. AbstractFactoryProviderBuilders are just the inevitable downstream consequence of that initial choice. No need for factories if you don't traffic in objects in the first place. Objects. Just say no.

Bit of an extreme position, no? Languages without OO tend to end up reinventing it. Like the Linux kernel style of "big C structure with function pointers": that's just a vtable which you have to maintain by hand. Or, god help you, trying to do COM in C. What's a good codebase that is very large but without either OO or pseudo-OO?

I totally agree one ought not use a non-OOP language for OOP. Right tools for the job and all that.

I work on large (but private, so I cannot share, sadly) FP-style codebases. The code style is stateless functions grouped in modules that operate on data-only structs in a factory line manner. Typed boundaries for correctness, short and maintainable functions for clarity. No member functions, so no vtables.

I've never seen such code need or use OOP design patterns. I'm just very gently pushing back against the idea all code devolves into OOP spaghetti in due course. It doesn't! There are better ways. :)

Re: Java 26 is here

#302

Post by hocuspocus »

HendrikHensen wrote: post #281
hocuspocus wrote: post #253

Earlier quoted context omitted.

> Java 21 was just released and frameworks had no meaningful support for virtual threads whatsoever. Spring was ready on day 1, as virtual threads had been an experimental feature since Java 19. Spring Boot added support within a couple months. > In my experience, most companies using Java are chronically multiple versions behind (e.g. some of my friends still in the Java world are on 11). And that's on you.

> And that's on you. Sorry I have to defend my pride here a little bit. When I joined my previous company, the entire company was on Java 8. When I left every app in every team there was up-to-date on the latest LTS release at the time, 17. I assisted many teams in upgrading their Java, Spring, etc, and inspired even more. I would argue that I'm one of the last people who you could blame for most companies being many…

So what's the issue then? You'd be able to bring other teams to current versions of Java and frameworks, which have all been using virtual threads for the past 3 years.

Re: Java 26 is here

#303

Post by gf000 »

Mawr wrote: post #289
gf000 wrote: post #213

Earlier quoted context omitted.

Java's GCs (plural) are hands down better.

Ok, which one do I choose then, with what configuration? How much time do I need to spend on this research? How do I verify that they are actually better ? Is the overall performance of my program better ? Because that's what I care about. I of course do include memory usage in "performance".

Do you need extra-low latency, even at very high percentile and are willing to give away a bit of throughput for it? ZGC

At almost every other case: G1 (the default, just don't add any flags).

Do you want to trade off using less memory at the price of some throughput? Decrease heap size, otherwise don't add anything.

That's it, in most cases just use the default.

Re: Java 26 is here

#304

Post by gf000 »

Mawr wrote: post #286
Tostino wrote: post #265

Earlier quoted context omitted.

(just like modern Java can burn its runtime / GC into the binary)

No, not just like. You're downplaying significant differences between the two that do in fact matter. So much so in fact, that you're just wrong. Stop spreading misinformation.

GraalVM indeed does a lot more than Go, it's a full optimizing compiler while Go does very little optimiations.

But burning a JVM next to a jar file is not hard at all, one could make something like cosmopolitan.

Re: Java 26 is here

#305

Post by gf000 »

wbl wrote: post #292
gf000 wrote: post #208

Earlier quoted context omitted.

> However complex error recovery is an anti pattern for Go. Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes". Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.

Why exactly do you have complex error analysis happening above a component that has the error? That's anti modular.

Because almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error.

E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).

Re: Java 26 is here

#306

Post by gf000 »

owlstuffing wrote: post #300
zadikian wrote: post #298

Earlier quoted context omitted.

Go use cases overlap the most with Java. I think the reputation you mentioned comes from Google using a lot of C++ for high-level things others would likely do in Java, so they see Go as a replacement for C++ in some areas. (assuming you meant C++ not C)

> I think the reputation you mentioned. . . Actually no. Go was designed from the beginning as a systems language as a C replacement.

In what way does that "design" show up in Go, besides marketing?

Re: Java 26 is here

#307

Post by lmm »

rubzah wrote: post #270
lmm wrote: post #145

Earlier quoted context omitted.

Some people did but that's actually worse. Your configuration comes magically out of nowhere and when it breaks you can't fix it.

Nobody ever wanted to wire up RPC endpoints, in the form of Enterprise JavaBeans(tm), using XML files. That is one for the history books of ridiculous technology.

XML files are bad. Invisible magic is worse. The sensible way to wire up a bunch of RPC endpoints is, like the sensible way to do most things, plain old code.

Re: Java 26 is here

#308

Post by cmwelsh »

cess11 wrote: post #67
mands wrote: post #58

Earlier quoted context omitted.

It's getting better, it doesn't all have to be Spring Boot and JBoss. There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI ( https://tamboui.dev/ ) for terminal UIs, and more. Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resourc…

If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with. https://www.wildfly.org/ I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for. As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.

As you’re familiar with the JBoss space, why would someone use an enterprise container over a simple HTTP server (Tomcat, Jetty, etc)?

Currently I’m trying to externalize as much as possible to the service mesh. I want teams to stand up a basic unencrypted HTTP server that accepts the company headers and just works with as minimal of a runtime as possible.

Re: Java 26 is here

#309

Post by owlstuffing »

gf000 wrote: post #306
owlstuffing wrote: post #300

Earlier quoted context omitted.

> I think the reputation you mentioned. . . Actually no. Go was designed from the beginning as a systems language as a C replacement.

In what way does that "design" show up in Go, besides marketing?

It's replete with oddities and limitations that signal "ah, this is because systems language."

Go’s type system, for example, is very much a systems-language artifact. The designers chose structural typing because it was lighter weight, but provided enough type safety to get by. It sucks though for enterprise app development where your team (and your tooling) are desperate for nominal typing clarity and determinism.

Re: Java 26 is here

#310

Post by deepsun »

spopejoy wrote: post #274
pregnenolone wrote: post #246

If we ignore the fact that value types likely won’t ship before we have flying cars, Java has evolved greatly. I really like how they’ve solved concurrency, but I dislike how they’ve handled modules but this a minor issue. The main problem with Java has always been its build tools. They’ve consistently been bad and continue to be. Even today, creating a bundled application with a stripped down JDK with jlink and jpac…

TIL Mill, I've been in build hell trying to package a javafx GUI gradle project that depends on a non-module-ified lib (usb4java, long story, no I can't use anything else). Beryx/badass failed entirely, was able to get something working with Gradle doing jlink and manual CLI jpackage ... But tbh the whole experience makes me distrust the Java ecosystem if you're supporting anything that is slightly out of the communi…

I feel like Gradle is only relevant for Android. All other projects are fine with Maven (and I like a lot that Maven doesn't allow to code in the build config, any complex logic should be extracted to a custom build plugin, using real code. I just have PTSD after some build.gradle monstrosities).
Post reply on HN