C basically has no standard library. It's no surprise to anyone who has ever used it more than in passing that you depend on the chosen build system to replace that. Building portable C libraries is very different because of this from any other commonly used programming language - even C++.
It's ironic to me to say that C has no standard library while at the same time libc is one of the most important libraries that most programs on an installed system can't go without.
So it has one, but it's small. It has a few useful functions, for example system(const char*) which was used by the exploit.
Actually the interaction with libc is not like what you expect from a standard library in other languages. Even apart from being very small, it's not really a single library - you have glibc, musl lib c, the BSDs each have their own libc, Mac OS has its own, Windows has its own. And if you want a very portable C program, you can't assume your program will run with the libc on your system, you need to take into account differences between these. Also, writing C programs that don't use the standard library at all is not unheard of - even apart from C in-kernel or on bare metal. For example, on Windows, libc is just a wrapper over win32, and you can just use that directly and gain much more functionality if you are not going to be portable anyway.
Additionally, libc is typically more of a system component than a part of your program. You can't choose to distribute a libc you prefer with your program and use that, you have to link to the system libc on many OSs. Even on Linux where it's not strictly required, if you use a different libc than the distribution provided one, you can end up in all sorts of problems when you interact with other programs.
AzulJDK and Android JDK would be better examples, as Oracle JDK is just an Oracle-blessed build of OpenJDK.
The difference from libc though is that there is no problem in distributing a program with your preferred JDK, and multiple Java programs can live on the same system while each using its own JDK and even communicate risk free with each other.
Also, different JDKs are significantly more similar in the API they offer to Java programs than different libc are - at least for a common core of functionality.