Refactoring the server to Java

[Protonull]

There was a relatively brief conversation about this in the Discord about this and there would be some benefits to it:

• Java is a strictly typed, cross-platform language: prospective contributors are likely to know it given that Minecraft and its mods are written in it.

• It means we can share/reuse classes between the client and server, particularly the packets themselves.

• Easier access to multi-threading, potentially reducing or even eliminating blocking-related delays. Currently, the entire server is locked up but a particular sequence of the sync negotiation since the query takes a while to complete and the server cannot handle anything else until the query resolves.

• Can turn this into repo into a root-level Gradle project. Not strictly necessary but a nice benefit.

• Let's the server use ViaVersion's API for multi-version support (Multiversion support #145) (relevant from ViaVersion Discord)

• The application Gradle plugin lets us produce a distribution zip that we can upload to each release and it'll just work out of the box.

• Java provides a greater means to configure the runtime, such as RAM usage and which GC to use, which could potentially lower RAM usage below the current ~100MB during single-person dimension sync for about a 3x3 region area. More significant testing may be required, but projects such as Reposilite, which runs on the JVM, can run on as low as 20MB.

[Protonull]

With any refactor comes the question of what's a dealbreaker change. For example, terminal commands can be reimplemented via jline, but should they? (relevant: #147). But what about the database? H2 would likely be a better fit for a Java refactor than SQLite, but they're not compatible: should the Java refactor keep SQLite? Or provide migrations? Etc.

[Huskydog9988]

I'm not sure a java rewrite would offer any substantial benefits. I'm partial to go if we were to do a rewrite as your well probably aware, but I'm not sure the project is in any real need one rn. The server is mostly a solved issue and good enough for deployments of ~30 people last I remember, which is far more than most people will reach.

[Protonull]

In another discussion on Discord, I've agreed that this would need @Gjum 's permission since this is ultimately his project and a Java refactor would be pretty substantial. I do just want to reiterate and stress though that this is NOT about mere language preference: if it were, I'd be recommending zig or dlang instead. No, I'm recommending this as I believe there'd be a genuine benefit

That said, I will admit to a slight snag: I've attempted a Java refactor before as kind of MapSync version of this, and I always stumble at packet reuse, specifically the chunk-tile packet. That packet and its subtypes are deeply entangled with Minecraft types that makes is annoying to detangle without some serious consequential edits to catchup and integration code. If this were to go ahead, I'd like some assistance in how to resolve this.