Thanks. Yeah, this is really my first time posting about the project since it's in a working state, and I wasn't aware of that sub, I mostly perused the source code.

That's always fun. I've considered doing something with LLVM, but I opted instead to make something that's a bit more unique in some of the design choices, prioritizing that over pure performance.

Yep, Java constructors and finalizers have to be treated as normal methods completely separate from C++ constructors and destructors, which is reasonable, anyway, with how Java objects are normally constructed. Trying to merge the Java and C++ constructors would definitely present issues, and destructors would be worse. Virtual inheritance is definitely a pain, requiring a number of workarounds to get everything compiling, plus sketchy behavior like needing a shared pointer to the object that's been partially destructed while calling the finalizer, or calling the finalizer to begin with, since the virtual function table changes during destruction. Everything has been working quite reliably so far, though, not running into any issues with the thousands of generated classes that I've tested.

Yeah, it's primarily the issue of debugging it. I've considered what would be required to implement one here, and it wouldn't be too bad to implement a similar one, but I've just spent so long debugging GC bugs in the C version, I opted for peace of mind and the performance hit, knowing that it may have been a decision I would regret later. It basically resolved all of the memory bugs, though, and the performance is still sufficient for now, so I'm quite happy with it. It's also nice not having to worry accidental collection in native code, though that could be mitigated with convenient C++ features.

Yeah, C++ seemed like an interesting challenge due to the object hierarchy issues, but I think most of the issues have been resolved with just using virtual inheritance. The additional flexibility with C++ makes a lot of the solutions much more elegant, which has been nice to actually work with. Most of the handwritten C++ for intrinsic functions looks quite similar to their Java counterparts, for instance. The whole concept was a bit on the impractical side, since there's no GC, so performance is a bit limited, but it's sufficient for simple games, and completely removes the need for additional countless hours debugging GC bugs.

UWP was more of an afterthought here, since it could be achieved with slight modifications to the C++ codebase while hopefully maintaining identical behavior to the other platforms. The main goal was Xbox support with UWP, since it's for a game framework, but the future of UWP on Xbox seems uncertain, so it was just another feature to throw in for fun. The primary goal of the project was always the Nintendo Switch backend, though there are plenty of other interesting possibilities like wasm.

This is a project created to bring Java codebases to platforms without a JVM using plain C++. It primarily exists to support the LibGDX game framework backend for Xbox and Nintendo Switch, SwitchGDX, though the generated C++ could be used in any environment. It was originally just a modified fork of the Parpar VM to compile with plain C and support further runtime library features like file I/O, but has been completely rewritten as far as the transpiler and native code is concerned to make use of modern C++ features and provide memory safety.