Hacker News Reader

Comment by zimpenfish | Hacker News Reader

Java still seems to be the main sticking point - Bedrock (C++) seems to have much higher performance these days.

(Although, intriguingly, Apple Silicon runs Minecraft under Rosetta 2 much more efficiently than the i9 I was using a month ago - no fan noise, no burnt legs, lasts hours on battery, stable 60fps - despite using higher settings and without quitting everything else first. Roll on an Apple Silicon JVM.)

View on HN

A rewrite with performance as the primary motivation is likely to be faster in general, but yes: avoiding garbage collection pauses is a substantial advantage for a video game.

Howdy, I’m the Group engineering manager for Java at Microsoft (yep we now do Java!). Our group is working on minecraft’s perf (starting with server) so expect a steady rate of improvement over the 2021

That's good to know, as server performance has been miserable since 1.13.

Also good to hear that Java edition won't be slowly faded out :)

This is actually really exciting to know :)

The Java client is still in development?

Yes, Java is still important. The vast majority of user-generated content on servers is pretty much Java only. I also believe Java is still the authoritative version of the game (i.e. things come to Java first, before eventually coming out to Bedrock) - the lead game designer for Minecraft is a Java dev.

I just really miss code connection in the Java version. It was the only way I found to teach programming for my kids, but they loath the C# version

*C++

That's really good news. Thanks for still supporting the moddable java edition!

To be clear to everyone. Not commenting or promising on the future product direction of the Java server or Java edition (my group doesn't own the product or product direction in any way shape or form). There's just some stuff we can look at now to improve the status quo since a bunch of my team are also fans of the game :-)

Is there any chance of an official modding API to either Java or Bedrock? I know this is not the place to make such promises or announcements, but I’d be remiss not to ask.

IIRC there is one for the bedrock edition.

There is not. There is a scripting API that is very limited.

Wow thats great! could you also recode tnt physics similar to how they were in version 1.7.10 so that tnt cannons can work again?

is there a way to get you up with Information or a talk about issues within the java server?

yes you can add me on discord Lugburz#5061

lack of value types is also a sticking point, which the early code worked around but evolved to do less and less so. imagine arrays of references to 3d vectors each of which is an object on the heap, instead of inline, etc

Value types are coming soon: https://openjdk.java.net/jeps/390 Probably supported as of Java 17

I've been hearing about value types in Java Coming Soon(tm) for like what, 5 years now? I'll believe it when I finally see it.

It took C++ 10 years to get concepts and modules into the standard, and experience shows 5 more until all bugs are sorted out.

Probably 10 more for static reflection, executors and networking.

Good engineering takes time.

Sure, but then stop advertising the damn thing. That's what I'm reacting to, the advertising. I'm fine with it taking as long as it needs to take. But I've been hearing about it for so long that all excitement for it is completely gone. When it actually drops, it will be met with the word "finally" instead of "awesome".

The JEP 390 that I linked should make you update your beliefs. Contrary to years ago, the value type implementation has matured so much that in a few months every Java program will have to be forward compatible with value types (otherwise they'll get warnings) We are long past the state of just talking about it, now it's being quickly incrementally added

This fight is already lost. It's already in "finally"-state. This is forward-looking feedback.

Even in C++ you have to take care with allocation patterns and what data structures to use.

If more care was taken in such areas it would also perform somehow better.

Hopefully when Java joins the world of languages with automatic memory management with support for value types, these kind of issues start being only a matter of careless programming.

Java 16 will bring the experimental API for native memory by the way.

It’s surprising GC isn’t mentioned once. That was always the thing to fight for decent UX in modded minecraft. Leaky mods could lead to (what this article refers to as) lag spikes as long as 40 seconds when the GC triggered (once a minute with tuned GC settings).

Because most likely it was more an issue of who wrote them than the quality of the GC.

The presence of a GC is an enabler for bad coding. If the code wasn’t running in a VM then you couldn’t play a mod with a memory leak that bad. It would just crash, as it should.

Memory corruption exploitation in C is a proof that no, it doesn't crash, only if you get lucky.

Allocating memory when there is no available addresses does not reliably result in a seg fault in C?

Not at, depends on the OS. It should return NULL, but not necessarly depending on the OS.

For example in Linux it will always return a pointer to memory that is yet to be allocated, it is when you touch the memory for the first time that Linux via the MMU trap, then goes around and actually makes the memory segment available, by then it is too late if the system is running low on memory.

https://man7.org/linux/man-pages/man3/malloc.3.html

That is why there is such a thing as OOM daemon on Linux.

Secondly, memory leaks like those caused by double free lead to the corruption of the memory allocator, thus whatever happens depends pretty much on the implementation being used.

Reply on news.ycombinator.com