How feasible would it be to use java bindings to call the world generation code from the original server?

[zleyyij]

While more of a stop gap solution, this would mean you could gradually transition from java to native rust while still having worldgen functional.

[Metaa4245]

is this even feasible? JNI only works with a running process, so you have to run the server to generate worlds anyway

[ReCore-sys]

A crate called rjni does allow you to run individual .class files so if we could extract those from the original server and figure out how exactly to run a function in a way that we can get the binary chunk data from, should be possible.

[zleyyij]

The main benefit would be easier usage of the server, so that more people can use ferrumc before it's fully implemented, hopefully helping with momentum/community

[Sweattypalms]

That's true. Well we'll see with the new rewrite on how it goes with world generation. Although it'd be against the law no? I'd hate to get sued 😂

[Metaa4245]

how would it be against the law though? if you extract the class file from the original server JAR not provided by you i don't think it's illegal, just like PaperMC applying patches to the server JAR

[ReCore-sys]

I am currently messing around with Rust and JVM interop and it does look very possible to do, the hard part would be getting the output of a chunk generation in a way that we can use.

[0xnim]

maybe make worldgen plugin api. then anyone can write whatever. including this

[AnonymousBit0111]

I agree with @0xnim , the main reason we're rewriting in rust in the first place is for performance and reduced memory usage. If we hook into the java implementation then that brings all of the problems with the JVM back. We can write our implementation of world gen in a way that if someone wanted to make a plugin to hook in they can, but it shouldn't be our focus.

[ReCore-sys]

I'm honestly not sure how to do the world gen in a way that allows plugins to influence it, but if we can I might see if we can pull off what @AnonymousBit0111 suggested. The reason I would like to have some kind of vanilla terrain gen is to act as a stand in while we do it natively, since that's going to take a long time to perfect. There may also be users who would rather sacrifice the performance improvements to get vanilla terrain gen anyway.