rand(3) isn't really the OS's concern, it's part of POSIX and the C standard which don't indeed, but could. Java specifies exactly how java.util.Random should be implemented (LCG from TAOCP with a 48 bit seed), which on the one hand means its well-understood and stable across machines, and on the other hand means it's kinda crap and can't ever be upgraded.
Yep and with the new SplittableRandom they seem to have opted for a more subjective definition with a guaranteed minimum cycle length and passing marks on Diehard. Seems like a happy middle ground.