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

251–260 of 352 posts

Re: Java 26 is here

#251

Post by ludovicianul »

HendrikHensen wrote: post #207
zadikian wrote: post #92

Earlier quoted context omitted.

Lack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set? Though JS will still have the least boilerplate because of the way it handles types.

I think there is something to say for compiling to native code, having binaries in the ~25 MiB range, being able to run in distroless containers, being able to run a web application with less than 100MiB of memory and startup times measured in milliseconds rather than seconds (sometimes dozens of seconds). Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon sti…

With Quarkus (and other new frameworks) you can have webapps with less than 100MiB. Startup times in a couple of miliseconds. CLI apps, with limited number of third party libraries are under 40-50MiBs.

Re: Java 26 is here

#252

Post by haspok »

owlstuffing wrote: post #151
lucketone wrote: post #65

Earlier quoted context omitted.

> for not embracing religion of OOP and FactoryFactory Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture. FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”. We now know that we prefer composition over inheritance, we have st…

> We now know that we prefer composition over inheritance When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a. But that’s not what composition is really about. The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface. Java provides inheritance and interfaces…

> Java provides inheritance and interfaces, but it doesn’t provide first-class delegation or traits.

I'm not sure I am missing first class delegation much (not a lot of UI projects in Java these days).

But interfaces with default (and static) method implementations are actually quite usable as traits / mixins. Since Java 8 IIRC.

You can also pass around functions / lambdas (coincidentally also since Java 8) to compose functionality together. A bit harder to follow and/or understand, but another perfectly legitimate and very powerful tool nevertheless.

Re: Java 26 is here

#253

Post by hocuspocus »

HendrikHensen wrote: post #219
pron wrote: post #210

Earlier quoted context omitted.

From your description it sounds like you're comparing an old Java program running on an old JDK with a new Go program running on a new Go runtime. These days Java has virtual threads (similar to Go's goroutines) and doesn't need a "reactive stack", and its optimising compiler and GCs blow Go out of the water without breaking a sweat.

I mean, what is old? How far along are frameworks these days, and what are companies using? That team was using Java 17. Java 21 was just released and frameworks had no meaningful support for virtual threads whatsoever. 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). Perhaps you can share some sources which prove that Ja…

> 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.

Re: Java 26 is here

#254

Post by pjc50 »

stanac wrote: post #53
dzonga wrote: post #37

the people that work on Java & the JVM are very smart. it has become a best of breed language - hell its better than Go for industry purposes. the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change. All those people using typescript (could be…

After ~13 years of working with C#, I moved to Kotlin. It's such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin. I want to say culture around Java doesn't have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.

I must say I prefer C# over Java. They're pretty similar in a lot of ways, but LINQ is much nicer to use than the Java streaming equivalents. And there are some odd warts like Java lacking unsigned types.

Re: Java 26 is here

#255

Post by pjc50 »

troad wrote: post #238
deepsun wrote: post #118

Earlier quoted context omitted.

I recently worked on a Go project and my task was to make it more configurable at build time and start time (add plugins / addons, make it possible to reuse from other libraries and tools). Turned I had to create *Factory and *Providers, even though I did not want to. It's easy to avoid "AbstractFactoryProviderBuilder" if everything is hardcoded. Try to make it reusable and extensible, and I bet you write one yoursel…

> 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?

Re: Java 26 is here

#256

Post by Arwill »

zelphirkalt wrote: post #247
Arwill wrote: post #71

Earlier quoted context omitted.

Once i heard a manager explain "we must get rid of anything Oracle, including Java, because of license reasons". I see this attitude everywhere since. JavaScript people are too afraid to use Java, that is why something like TypeScript exists. And for personal projects, C# has become a better and more fun "just works" platform.

I wouldn't count myself as a JavaScript person at all, and usually avoid it where I can, going to some length, to make pages static, if possible. So I am not exactly in the group of people you are attacking. However, I am afraid of the Java coder who is decorated as senior, has sway due to their position, and who will tell me, that something, that is a simple function, shall not be a simple public static "method", bu…

> So I am not exactly in the group of people you are attacking.

I wasnt attacking anyone.

Developers are used to the lack of type-safety in JS, and assume that having to code in a type-safe language is something hard. Ive seen this attitude multiple times, it is a known topic.

The issue you are describing is what the author on top mentioned, the culture. It is not just Java, the "enterprise style" coding has infected other languages too. It is the result of how new developers were educated in a time when for example code performance or code readability were only abstract considerations. I fought that style myself multiple times in the past. But thankfully it is going away now.

We are more or less in "chained function call hell" now.

Re: Java 26 is here

#257

Post by megapoliss »

gf000 wrote: post #199
owlstuffing wrote: post #151

Earlier quoted context omitted.

> We now know that we prefer composition over inheritance When people say "composition over inheritance" in Java discussions, they usually mean the trivial modeling rule: prefer has-a over is-a. But that’s not what composition is really about. The deeper idea is interface composition -- building types by composing multiple behavioral contracts behind a single cohesive surface. Java provides inheritance and interfaces…

Well, what mainstream language has better tools for composition?

kotlin

Re: Java 26 is here

#258

Post by zvqcMMV6Zcr »

> My hope is that the first JEPs out of Project Valhalla will be announced later this year

I have heard about Valhalla at least around release of Java 8. That said that site is a solid description of other current and upcoming JEPs.

Re: Java 26 is here

#259

Post by lenkite »

HendrikHensen wrote: post #207
zadikian wrote: post #92

Earlier quoted context omitted.

Lack of virtual threads was its biggest remaining problem because this made the common ways of doing cooperative multitasking very ugly. Go's big thing was having that from the start. Maybe now that Java has it too, it's set? Though JS will still have the least boilerplate because of the way it handles types.

I think there is something to say for compiling to native code, having binaries in the ~25 MiB range, being able to run in distroless containers, being able to run a web application with less than 100MiB of memory and startup times measured in milliseconds rather than seconds (sometimes dozens of seconds). Don't get me wrong, I like Java and don't very much like the Go language. But Java has a lot to improve upon sti…

You can have a <20MiB Graal-compiled binary for a Java project if you use a lean framework like Micronaut. Memory footprint is 5–40 MB RSS.

Re: Java 26 is here

#260

Post by chii »

gf000 wrote: post #216
rossjudson wrote: post #166

Earlier quoted context omitted.

GWT was a huge success, and eventually became obsolete -- which is not the same as "failing horribly". It took a long time for the web ecosystem to build up the capabilities that removed the need for GWT. For a while, it was quite a good way to build and heavily optimize certain kinds of web client applications.

Yeah, I believe some ex-Googlers even claimed that writing Gmail was simply impossible at that time with ordinary JS, and the abstraction behind GWT was an absolute necessity (though maybe the frontend part was not all that important - closure compiler is still alive though)

On the other hand, gwt did not gain much traction, and the majority of frontend developers disliked it (granted, they do prefer javascript+css rather than coding the frontend via gwt widgets).
Post reply on HN