It definitely sounds like Louis is "my kind of guy". I love people who put in the effort to work against the system that wants us to throw away everything. I guess I've just become somewhat disillusioned as I feel like they make it increasingly difficult an (almost) nobody is doing anything about it. I really love the "right to repair" concept, it should be in our constitution!
If you can find an identical chip from stuff you already have, and have access to the hot air station, I agree that there's no reason not to do it. I was thinking of going through all the hoops of actually acquiring an identical chip that works and isn't a Chinese imitation. In addition I would be slightly worried of minuscule "tin bridges" that could lead to short circuits that could kill your motherboard. I mean, when you heat up the stick, I would guess that the solder of the neighboring chips would also liquefy, and that it would be very easy to make a short somewhere that isn't easily detectable. Without a tester, you'd have to use your motherboard as the "tester", which could become much more expensive. But, if you're willing to risk this and the time and effort required, go for it

I'll be rooting for you!
It feels great when you're able to fix something to give it new life. Not every operation ends up with that though

I replaced all the caps of the type that typically breaks on the HDMI board of my previous Onkyo, and it was some bitchy soldering on some of those caps, and it turned out not to do squat. My current Onkyo developed the same symptoms a couple of years later, and this model was covered by a "recall" for this problem so I sent it in. After communicating with the repair shop, it turned out that all they did to repair it was to reheat the "CPU chip" on the board. Onkyo had been forced to switch to lead-free solder (as everybody else), and they hadn't properly adjusted the solder temperature on the factory, so the bindings were weak and tended to fail after a while. Since the problem was "periodic" at first, and got gradually worse, my mind was kind of "locked in" on the caps. I didn't even consider it being a bad solder, but at the same time, fixing my "old" one was completely out of my reach as there's no way to do that without a hot air station.
If one chip was without contact with the heatsink, it would be a reasonable guess that it's the one who has died. I would still worry about potentially damaging the motherboard.
As SubJunk says, the GUI is probably the last thing you want to start with. It's a bitch to work with for several reasons, like the fact that the GUI framework itself is full of bugs and that Oracle abandoned all development on it years ago. The documentation also generally sucks, so for complicated stuff I usually have to study the code of the framework to figure out how to handle things. On top of that, the classes handling it in UMS is mostly a complete chaos.
Eclipse has tons and tons of extensions, and I know there used to be a graphical editor for this. I don't know if it's still available, because some projects become abandoned, typically the interest falls when the framework itself is abandoned, but it might still be there. It isn't that simple though. I've tried graphical GUI editors before, and they generally generate code very different from that a human would write. They generally can't "parse" human written code, only code they have themselves generated, so I'm pretty sure it would be impossible to "import" any of the existing GUI code into such an editor. If you wanted to make something completely from scratch, it might be viable, although the quality of the code generated often isn't very good.
To complicate things further, Java has no GUI support itself. It relies on toolkits/frameworks that handle GUI, and there are several to choose from, none of which is a good choice IMO.
First there was AWT. This was, as far as I understand, the "original" GUI framework for Java. It used the native GUI components in the OS'es, but since Java is cross-platform and the code should be generally reusable on all platforms, they simply skipped everything that wasn't available across all major OS'es. This is very little it turns out, making AWT more or less useless. The majority of the things you want to be able to do, simply aren't available.
Since that turned out to be a fiasco, they invented Swing. Instead of using the native GUI components, Swing does almost everything in Java. Swing has something called "Look and Feel" classes that tries to make the GUI mimic the native look of different systems. It's not identical though, but somewhat similar. This means that you can for example use the macOS LaF on Windows, if you so wish - and end up with a GUI looking like it belonged on a mac. This approach is slower, isn't properly "native", still doesn't support everything the native components do, and suffers from a number of inconsistencies and issues. UMS uses Swing. Swing could have been "half-decent" in my view, had Oracle not abandoned it years ago. But they did.
Both AWT and Swing was created and maintained by Sun/Oracle. When they abandoned Swing, they decided to abandon everything that resembled native "look", and created JavaFX. This toolkit doesn't even try to look like native GUI components, but has several "themes" that is completely unrelated to the OS it is being run on. As a "patch", they have made JavaFX stylable using CSS, so it is theoretically possible to customize components to look somewhat like the native components, and early on there were some attempts. From what I've seen these have since been abandoned. Oracle seems to have decided that desktop applications isn't really something they care about at all, and has also stopped JavaFX development after Java 8. The only good thing is that instead of letting it die a miserable death, they open-sourced it and has "given" it to the community to maintain and develop. So, there is still hope that JavaFX will have a future, although it's somewhat uncertain.
In addition to the Sun/Oracle frameworks, there is something called SWT, maintained by the Eclipse Foundation. This is obviously what Eclipse uses. SWT is in many ways superior, because it truly use the native GUI components for all (supported) OS'es, but it has one huge drawback. SWT code is NOT cross-platform, so you end up having to create all your GUI components one time for all environments you want to support. I did look into it once, but it seemed awfully complicated to get to play ball without causing a massive maintenance toll and extra work.
So, there you have it. Everything GUI is problematic in one way or another in Java, and it's all about figuring out what you think is the lesser evil. Not to mention that "switching" framework means rewriting all GUI code, making it very impractical to put it mildly. So, the conclusion is: Stay away from UMS GUI until you have some experience and is ready for some real frustration.