I can confirm that modding in Java DOES work. You can recompile some of the classes and replace them within the folders. However, some classes will give you a null errors, as if the file wasn't loaded properly (mainly when I recompile UIManager). This could be caused by a number of reasons, and ultimately it would be a lot to have to track down what is causing it.
That said, the methodology I've had the most success with so far is creating an external "ModLoader" class, to which I call the various lifecycle methods (init, update, render, destroy) from the IngameState class. The problem, however, is when you start to add UI elements using the UIManager. Despite having no "Kahlua table" to reference, they still wind up being called upon in the various UI elements, resulting in a bunch of Kahlua errors saying "no table available." This could be fixed by adding conditionals to the Lua files that have the problem, but I feel like that kind of defeats the purpose of modding the game using Java? The engine SHOULDN'T be referencing those UI elements if they don't have a table, but for some reason they still do. Additionally, the UI manager seems like the only way to reasonably add UI elements to the game because of how it threads everything, so not being able to do this is basically the biggest reason why modding in Java seems so hard.
I have yet to test a lot of other functionality like adding items to the game, adding certain events, etc. I can't imagine there will be too much of a problem with all of that, though. I'll post updates if I decide to further pursue modding in Java, maybe I'll even post a framework to allow other creators to more easily do so. Right now I have a few ideas for mods of my own, but they all require me to find a way to get around the UIManager problem. I think I'll re-attempt recompiling it, but this time I'll just add everything to a separate list for rendering that doesn't get provided to the Lua.