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

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

github.com

Post reply on HN
Print view View original

391–400 of 557 posts

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

#391

Post by kaba0 »

icedchai wrote: post #385
kaba0 wrote: post #185

Earlier quoted context omitted.

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.

Sure, but only with similar frequencies as an LLVM/compiler frontend bugs. A JVM bug may also be harder to debug, due to all the moving parts, but realistically, it’s always the program’s fault, and those are taken care of.

To directly answer you though, no, I haven’t hit a JVM bug that was apparent (so no segfault or anything like that, except when playing with sun.misc.unsafe).

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

#392

Post by kaba0 »

babypuncher wrote: post #322
kasperni wrote: post #215

Earlier quoted context omitted.

The version number increments by 1 every 6 months. What is so nightmarish about that?

To someone who has not written Java since High School in the '00s, I find the ecosystem a little confusing. My recent experience was this: I have a Windows box in my basement that hosts a Spigot Minecraft server for some friends and their kids. This box also hosts my UniFi controller software. The UniFi controller software requires Java 8, which is what Oracle offers for download on their website. Spigot usually requ…

Well, first of all there is indeed no JRE anymore, one is not supposed to install anything. The java program is supposed to be packaged up with a lean runtime executable that only contains the necessary parts, as this has been the trend for a long time.

But in practice there are indeed a lot of jar files everywhere, that have to be run through a “JRE”. It sounds a lot like a package manager program to be honest (taken care by nix for example). But otherwise, I recommend sdkman to manage multiple java versions.

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

#393

Post by naikrovek »

bhuber wrote: post #251
naikrovek wrote: post #229

Earlier quoted context omitted.

it doesn't matter how much the HotSpot JVM is tailored to OOP code. CPUs and RAM are not tailored to OOP in any way. Procedural code will always be more efficient with CPU and RAM, arrays will always be faster than Lists, being able to control datatype sizing to the byte will always outperform classes, and so on. java is very fast, please do not misunderstand me. java is much better than it used to be, as well. Java…

> it doesn't matter how much the HotSpot JVM is tailored to OOP code This is obviously false. The JVM, or any other compiler for that matter, is what translates the OOP code into CPU instructions. If it does that optimally, it won't matter what design pattern the top-level compiled language used. If it does it poorly, then it will. > CPUs and RAM are not tailored to OOP in any way. This is not entirely true. Intel in…

> If it does that optimally

ah, the "sufficiently smart compiler" argument. There is no such compiler, FYI, and there may not ever be. Not for every situation that developers are creating in Java today.

it's a matter of hitting your CPU cache as often as possible. Neither javac nor the runtime has any freaking clue how to do that, but you, as a developer, do. When you write Java, you can't do a lot to control how that JVM arranges data or how it fetches it from RAM, partially because of OOP, partially because of autoboxing/unboxing, so you wind up missing the cache a lot more unless you create a bunch of primitive types and use those, and that that point, why are you writing Java?

I'm not saying Java is bad. I'm saying that it is not the fastest language you can use. You seem to be arguing that it is, or that it could be. It cannot.

> average performance for a large codebase will be much better than something like C/C++ given the same amount of effort.

absolutely not. Maybe if you're fully skilled in Java and new to C or C++, but if you are equally skilled in both, you would never choose Java for performance alone.

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

#394

Post by cozzyd »

chopin wrote: post #361
kentonv wrote: post #274

Earlier quoted context omitted.

Oh, please. I once worked on a Java-based server at Google that had to answer requests with millisecond latency. In order to achieve this, the server had to block garbage collection most of the time. Periodically, each instance of the server would ask the load balancers to stop sending requests to it, so that it could then safely run the garbage collector, and then ask for traffic to return. We likely would not have…

Afaik, a malloc is not guaranteed to return fast. With those requirements it's hard even in C.

Right but you would typically use a preallocated arena.

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

#395

Post by debug-desperado »

titzer wrote: post #379
hhjinks wrote: post #362

Earlier quoted context omitted.

Can you explain why you think C# does those things better than Java? And what they correspond to in Java?

Sure. Reified generics, along the lines of C#[1], rather than Java, is the only sane design. Erasure of generics works fine in languages that have the "parametricity" property, where you cannot observe any characteristics of a polymorphic value. That doesn't hold as soon as you have casting. Java generics have a couple of unfixable problems. For one, you can have List and List both be passed to a place where Object i…

"Static generic types are lies" yes, and it doesn't matter that much. You got the safety at compile time and if you didn't do an unsafe cast then you preserved it.

The issue with primitive types and boxing is certainly noted. Hopefully Valhalla will address it and more.

The problem with reified generics is that the same variance model must be adopted by all guest languages on the runtime. Hence you basically don't see any guest languages on the CLR, and efforts by languages such as Scala to port to the CLR failed due to problems interoping with C#. I think one of the JVM engineers "pron" has discussed this multiple times.

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

#396

Post by [deleted] »

ralmidani wrote: post #356
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...…

Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem.

[deleted]

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

#397

Post by liketochill »

bjourne wrote: post #245
lliamander wrote: post #133

Earlier quoted context omitted.

Erlang is not as peformant as Java, but there are plenty of reasons to prefer the former to the latter: - a much better concurrency model, that gets you parallelism for free just by adding cores - no global gc pauses, low-latency - fantastic operational tools (trace debugging, remote shell, etc.) - Erlang/OTP gives you great middleware out of the box, including including queues, pub-sub, service monitoring, database,…

Imo Erlang's scalability benefits are oversold. Unless you're a national carrier the performance of Java far outweighs Erlang's scalability. Instead, Erlang's undersold killer feature is its robust support for hot code reloading. It enables almost any part of the system to be upgraded without affecting running processes. Other languages and VMs can't do that because they optimize call frames differently and rely on m…

This type of feature is important in control systems where we can modify the process control without interrupting it at all

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

#398

Post by kaba0 »

tomohawk wrote: post #363
ralmidani wrote: post #260

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…

That’s funny because Go is much less expressive than even Java. If anything, their overdesign seems to come from their juniority and badly ingrained “best-practices”, nothing inherent in the language.

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

#399

Post by rowls66 »

oftenwrong wrote: post #297
topspin wrote: post #62

Earlier quoted context omitted.

> The biggest thing Java is missing is full hot swap The biggest thing missing in Java is an answer for the billion-dollar mistake. Real world Java is plagued by NPEs because a lot of Java is written by low caliber programmers. Java + functional error handling would be a monumental improvement.

Java should adopt something like the Checker Framework Nullness Checker in its first-party tooling. https://github.com/typetools/checker-framework

Agree, love that tool. Unfortunately it does not fully support Java 8, and that seems unlikely to change. I have never used it on a large project, I don’t think that compile times are good.

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

#400

Post by kaba0 »

titzer wrote: post #379
hhjinks wrote: post #362

Earlier quoted context omitted.

Can you explain why you think C# does those things better than Java? And what they correspond to in Java?

Sure. Reified generics, along the lines of C#[1], rather than Java, is the only sane design. Erasure of generics works fine in languages that have the "parametricity" property, where you cannot observe any characteristics of a polymorphic value. That doesn't hold as soon as you have casting. Java generics have a couple of unfixable problems. For one, you can have List and List both be passed to a place where Object i…

Your first point is kind of making a big deal out of something that isn’t that big of a deal. The trivial solution is to just.. use the language’s static typing and don’t pass typed objects as Object. With a generic function nigh everything can be done type-safely (remember, if you don’t use class casts, your generic code will be completely type safe). Sure, there are some edge cases, but they are so edge-cases of an edge case that I really don’t think it is a great differentiator between the two platforms.

Your second point is true though, and the fix is something that requires at least 6 PhD’s combined, but they are working on it.

Post reply on HN