This is about "ahead of time" compilation, otherwise known as "compilation", which third-party tools [stackoverflow.com] have done forever. Linking to C in Java is its own world, and I don't know how practical C++ is.
The stack overflow you link to has nothing to do with AOT. They all use a standard JVM and JARs, just all packaged into a single exe file. Its still JIT for the ones that include the JRE bits, the others just download and install a JRE for you. Using C and C++ code from Java is non-trivial but easy enough.
It's dead easy to bridge between C++ and C# at runtime using Managed C++ (or whatever they call it these days). The C# marshaller, the built-in way to get C objects from C# code, is slow painful garbage that no one should use, but it's easy to do the conversion in C++ and either object conversion or using objects directly is very fast that way.
Its just as easy in Java, except better hidden, cause you're not supposed to do it, in order to keep the 'cross platform' nature of Java at its core. Microsoft wants you to bind your C# apps to the Windows platform so they encourage the use of P/Invoke to work around unimplemented features of the framework. Its handy, but goes against one of the core tenets of Java.
You can compile C# to a proper EXE or DLLs easily enough and it will happily load C/C++ DLLs. The reverse is a bitch though - I've heard it's possible (the .NET runtime is also just DLLs), but I never got it to work properly.
Technically, what you compile C# (and all .NET) to isn't actually executable either. Its byte code as well, that can be easily and quickly turned into cached binaries that are essentially AOT compiled ... but thats stored in a different director on the machine and isn't the exe you run, mono will do actual full AOT with the right options, but by default doesn't either. Full AOT takes away several features of the .NET framework, just like it would with the JRE. They'd be implemented in an entirely different way. .NET dlls are just OLE components at their hearts, you've probably heard of OLE as one of the other names it goes by: DDE, OLE2, ActiveX, COM, DCOM. These are ALL THE SAME THING in different revisions, with more features in the later ones. .NET being the latest. Loading and running .NET assemblies is only slightly more difficult than loading an ActiveX in C or C++. Its non-trivial, and you won't find a ton of examples, but its not black magic. Its no more difficult than getting an XPCOM or Corba object to load, and Mozilla can even do that properly so lets not act like its rocket science.
You can (awkwardly) run C code from Java, including loading DLLs, but I've never heard it's possible to do the reverse. What can C code do with a JAR?
You would embed the JVM in your application or a plugin for your application and execute the JAR from there, the same way you do with .NET runtime objects. Not really rocket science here either, though again it is non-trivial.
Its the same as loading pretty much any interpreted language from C or C++, just different libraries and function calls. You do realize that the 'java' command is a C application that loads a bunch of Java libraries and execute JAR files right?
Linking all three would be a bragworthy project, but I think Java is just missing the key concept here.
Its been done: https://www.ikvm.net/
Run .NET code in java, run Java code in .net. Its big, its bulky, it works pretty well, but I don't recommend doing it for weekend fun.