Don’t call it a comeback: Java is still champ • Hacker News Board

Re: Don’t call it a comeback: Java is still champ

#461

Post by bluefirebrand » Wed, Aug 10, 2022, 5:10 AM UTC

cutler wrote: post #416

nick__m wrote: post #341

Earlier quoted context omitted.

Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...…

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Doing validation in the method body scales terribly, is hard to maintain, isn't very testable, etc.

However, defining the validation schema in the parameter list is ugly too. Define it elsewhere and have it run through a validation middleware.

Re: Don’t call it a comeback: Java is still champ

#462

Post by cozzyd » Wed, Aug 10, 2022, 5:13 AM UTC

chii wrote: post #441

cozzyd wrote: post #394

Earlier quoted context omitted.

Right but you would typically use a preallocated arena.

but if you're going to do that, the same could be done with java, with less pain for the remaining parts of the application that does not require such methods of memory allocation.

My Java is rusty, does Java provide things like placement new that make using arenas ergonomic?

Re: Don’t call it a comeback: Java is still champ

#463

Post by amanaplanacanal » Wed, Aug 10, 2022, 5:22 AM UTC

pron wrote: post #64

jeroenhd wrote: post #29

Earlier quoted context omitted.

My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…

> but I think it'll slowly move the way of COBOL and FORTRAN That could be true of any language that's achieved great popularity, but in 2022 Java is the language that dominates server-side development (by plurality, not majority), it is a technological leader in areas of compilation, garbage collection, and low-overhead in-production profiling, no other single language looks posed to seriously challenges Java's domi…

Aren't most of those benefits from the JVM rather than Java itself?

Re: Don’t call it a comeback: Java is still champ

#464

Post by kaba0 » Wed, Aug 10, 2022, 5:26 AM UTC

debug-desperado wrote: post #428

kaba0 wrote: post #417

Earlier quoted context omitted.

You have Function , Supplier , and many other predefined functional interface in the standard library.

That's my point, we don't have much more than that. Even a 2-arg function is missing. You can supplement with something like Vavr or just write your own, but even then it's not pleasant to read "Function3 ". Typescript, Kotlin, and Scala all do this way better. Here's an example from Kotlin (it's an extension function, but focus on the combiner lambda): fun Collection .fold( initial: R, combine: (acc: R, nextElement:…

Just nitpicking, but there is a BiFunction generic class in Java, but I understand your point. Yeah, some syntactic sugar could come in handy, though I don’t think that it would be a real productivity boost, more just an annoyance.

Re: Don’t call it a comeback: Java is still champ

#465

Post by hackerlight » Wed, Aug 10, 2022, 5:34 AM UTC

bitcharmer wrote: post #184

dboreham wrote: post #124

Earlier quoted context omitted.

The JVM GC is fundamentally the same as 10 years ago.

Saying this just shows you don't know much about modern JVM.

Do you use a proprietary JVM at your place?

Re: Don’t call it a comeback: Java is still champ

#466

Post by mesarvagya » Wed, Aug 10, 2022, 5:35 AM UTC

al_mandi wrote: post #452

cutler wrote: post #416

Earlier quoted context omitted.

Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?

Why write many lines of validation when one line can suffice? @Entity class User { @NotBlank String username; } // Use site public User addUser(@Valid User user) { ... } as opposed to class User { String username; public void validate() throws ValidationException { if (username.isBlank()) throw new ValidationException("username is empty"); } } // Use site public User addUser(User user) { user.validate(); // ... }

Code like this is expected in Spring https://hastebin.com/jevibugiqu.less . Literally all the classes I see are filled with annotations. Can we even write code in pure java without a single annotation ? Theres a lot of magic going on with annotation. It works great while it is running. God forbid there is some issue and we have to figure it out where all the magic is happening.

Re: Don’t call it a comeback: Java is still champ

#467

Post by skybrian » Wed, Aug 10, 2022, 5:42 AM UTC

SureshG wrote: post #333

skybrian wrote: post #163

Earlier quoted context omitted.

I wouldn’t use Java again because I am done dealing with the brokenness of Maven and Gradle. They are the opposite of “little fuss and muss.” The Go build tools fit your analogy better.

> The Go build tools fit your analogy better. Go uses two build tools for any non-trivial projects. One write in go.mod and another in Make :D (see this - https://github.com/kubernetes/kubernetes/tree/master/build/r... )

I think Hugo might be a better example, as a medium-sized non-trivial project:

https://github.com/gohugoio/hugo

There is a Docker file and some shell scripts, but you build the executable using "go install".

Re: Don’t call it a comeback: Java is still champ

#468

Post by chii » Wed, Aug 10, 2022, 5:46 AM UTC

cozzyd wrote: post #462

chii wrote: post #441

Earlier quoted context omitted.

but if you're going to do that, the same could be done with java, with less pain for the remaining parts of the application that does not require such methods of memory allocation.

My Java is rusty, does Java provide things like placement new that make using arenas ergonomic?

no, you cannot control allocation via regular means. What i meant is that you make pooling in java, and that effectively makes it work like an arena allocator (in that you end up setting a bit/boolean flag to allocate/deallocate an object).

But the pooling can be constrained to just one portion of your app - the hot loop or the bit that needs the low latency. The remaining code - loading resources at startup for example - can just be regular old java that's easy to write.

Re: Don’t call it a comeback: Java is still champ

#469

Post by skybrian » Wed, Aug 10, 2022, 5:47 AM UTC

chii wrote: post #439

skybrian wrote: post #163

Earlier quoted context omitted.

I wouldn’t use Java again because I am done dealing with the brokenness of Maven and Gradle. They are the opposite of “little fuss and muss.” The Go build tools fit your analogy better.

> dealing with the brokenness of Maven people shit on maven, but i say it's much better than many other built tooling - npm, make, or custom scripts. The only thing need getting used to is that you cannot and should not stray from the maven model - fit your project's built into the maven model, rather than try to twist maven to do your bidding.

Maybe I haven't built anything large enough to feel the pain, but I find npm acceptable. Go's module system seems more secure, but I had little fuss using npm to build a simple web app.

Re: Don’t call it a comeback: Java is still champ

#470

Post by pkolaczk » Wed, Aug 10, 2022, 5:51 AM UTC

kaba0 wrote: post #409

pkolaczk wrote: post #318

Earlier quoted context omitted.

I haven't said that the JVM would be corrupt by NPE. But C program state would also not be, and you could do the same handling as in Java. But if your code invoked an NPE or bounds check, then it means either the algorithm is incorrect or the data it processes are already corrupt by incorrect processing earlier. Continuing in such situation increases the risk, because you don't have any guarantees which parts of the…

Well, then consider deterministic failing a plus, as your C program may just continue along silently, with corrupted application state, and you might never learn of the problem (you are not likely to meet truly nullptr null pointers, they are just likely uninitialized, where all bets are off whether they are valid addresses) Being able to handle it correctly is just an additional benefit.

Ok, but now you're speaking about a different thing - memory safety. And that is an obvious advantage of Java over C. But C is a very low bar to compare to. There are dozens of other languages which are memory safe and some of them offer stronger guarantees than Java.

Your Java program may continue along silently, with corrupted application state, because it invoked a race condition, and you might never learn of the problem.