Live data from Hacker News

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

github.com

381–390 of 557 posts

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

#381

The biggest thing Java is missing is full hot swap. Its been implemented via the dcevm but, inexplicably, has been ignored by both sun and oracle. This one, existing technology would make Java DX on par with the dynamic languages

Enhanced hot swap using GraalVM has mostly caught up with capabilities https://www.graalvm.org/22.1/reference-manual/java-on-truffl...

I’ve tried that and it didn’t work reliably for me. The jet brains runtime release works but it’s a bear to figure out which download to use.

Regardless, it’s ridiculous that at this point Java doesn’t have full hotswap. All the hooks are there (as is apparent from the error messages when a hotswap fails) and the dcevm is being maintained by jetbrains employees. It needs an internal champion at oracle/sun.

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

#382

Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…

Java has reached the status of Cobol - it is immortal because it is everywhere and has been around a long time. Because of that, there are a lot of Java devs. Our team works in Go, and so we get a few Java devs in once in a while as new positions open up. The biggest change for them is to get out of archonaut mode and stop overdesigning everything. After going through a 3-6 month cleanse, it's fun to see them complai…

We use Elixir at work, but a lot of us either did a Java bootcamp, or came over from Java jobs, and in some places the codebase reflects that.

I love your use of the word “cleanse”.

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

#383

Earlier quoted context omitted.

>if I need to do low latency If the JVM is considered low latency I shudder to think what is high latency.

Java is heavily used in high-frequency trading. I believe it's the most popular language after C++.

So is python. Doesn't mean you use it for your latency critical software.

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

#384

Earlier quoted context omitted.

He still acts as the lead architect on C#, in addition to working as the core developer on TypeScript.

Nope, Mads Torgersen is lead architect on c# nowadays, Anders is 100% on Typescript's typechecker.

Sounds like someone's Wikipedia page needs to be updated then

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

#385
post #185

Earlier quoted context omitted.

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

If you do that in C, your program may run “just fine” on the surface forever, yet it can silently corrupt all of its data. Java can catch NPEs and handle them appropriately (e.g. a web server might just answer server error 500, but it will continue to run with well-defined semantics). I don’t think the two is comparable. Even Rust will go off the happy path with a single use of unsafe, and there is no sailing back fr…

I guess you've never hit a JVM bug, then? They happen.

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

#386

Earlier quoted context omitted.

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.

Dereferencing null is undefined behaviour in C. Probably it could be handled with platform-specific code, but handling it correctly not the easiest thing to do. Other than dereferencing null, there're so many ways to accidentally blow up C code and something like reading uninitialised memory is truly undefined behaviour which can't be worked around. Java does not have undefined behaviour at all. Dereferencing null wo…

In theory, yes, but when you run low on memory (heap, PermGen space, whatever), you can run into unusual situations. You may have a bunch of threads spinning with exceptions, continually retrying, making no progress. You'll have no choice but to kill -9 your process and restart.

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

#387

Earlier quoted context omitted.

This has not been my experience at all. The JVM is not corrupted by a NPE or out of bounds access unless you are using native code. For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep goi…

> This has not been my experience at all. This has been my experience with software written in Java by developers who think it was not their experience. > In a Java Swing app we built for a similar use case ...oh no. I actually tend to associate Swing UI with weird, undefined behaviors, and whenever I'd look under the hood, it would nearly _always_ be due to them trying to swallow runtime exceptions. Pure hubris, as…

There is some wisdom to what you say. I've experienced some Java apps that basically enter an exception/logging loop, quickly filling the system with gigs of logs full of 100 line stack traces. Eventually someone is alerted and has to clear the logs and kill -9 the app.

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

#388

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…

> My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Might want to give some evidence of this. Also, C# has no plans of green threads. It went the async/await way which is a pain.

That may not be true according to David Fowler: https://twitter.com/davidfowl/status/1532880744732758018?s=2...

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

#389
post #275

Earlier quoted context omitted.

First class functions are as modern as the Iphone 5.

Pedantically, I want to point out that first class functions predate the original iPhone by a large margin ...

I meant lambda’s introduction’s date in Java.

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

#390
post #106

The JVM is pretty great. I could certainly nitpick things, but it's pretty great. Java is pretty decent. However, I would say that Java lost a lot of time and even now there are some decently rough edges. Java didn't evolve as a language for a while and that left the door open to other languages and other non-JVM ecosystems a lot. As the article notes, Java 8 was a breath of fresh air, but it was minimal in some ways…

C# interfaces with methods, properties, and events is just so nice from a readability standpoint.

I know we like to pretend that Java now has first-class functions since Java 8, but without easier to use functional signatures they're just too much of a chore. Who the heck wants to write a new interface in a separate file to do this.

I'm grateful for the JVM and think it's probably better than the CLR for targeting a high level language (as evidenced by the continued existence of Scala, Kotlin, and Groovy). But Java, even post-Loom and post-Valhalla, will never be the promised land for quick-to-read-and-grok code.

Post reply on HN