One of the new features of Java 8 is the SHA-224 message digest.
What is the use case for having a 224-bit-length hash?
SHA-224, part of FIPS 180 since
SHA-224 was defined by slightly modifying SHA-256 of FIPS 180-2, in two ways:
As a side benefit, SHA-224's output is 28 bytes instead of 32 for SHA-256, which is useful on some occasions, including a huge number of hashes (as rightly pointed in this other answer) or mapping to an Elliptic Curve Group of some particular size. But if that's put to use in any FIPS-endorsed usage, I missed it, and welcome the info.
Update: to clarify why 224 bit is the right size to match the assessed security strength of 3DES: SP 800-131A says " three-key Triple DES is assessed at a security strength of 112 bits ", I think referring to the attack of Stefan Lucks: Attacking Triple Encryption (in proceedings of FSE 1998), or perhaps to the ealier meet-in-the-middle attack of Ralph C. Merkle and Martin E. Hellman: On the Security of Multiple Encryption (1981, Communications of the ACM, Volume 24 Number 7). We need to double that 112 to obtain the required bit width of a hash of equivalent strength, including against very practical attacks, see Paul C. van Oorschot and Michael J. Wiener: Parallel collision search with cryptanalytic applications (1999, Journal of Cryptology 12 (1), 1-28).
It meets the security requirement for 112-bit collision and preimage resistance, while being 32 bits shorter than SHA-256.
This may not seem like a lot, but when you have thousands or even millions of hashes or signatures to worry about in a system, those extra 4 bytes add up.
Think of a webmail service, where a hash of each email is used for deduplication and stored, you need enough collision resistance for the system, but don't want to needlessly waste space if you have billions of emails coming in every day. Those 4 bytes add up to several terabytes per year, per server
Honestly, in practice, there are very few if any reasons to use SHA-224.
As fgrieu notes, SHA-224 is simply SHA-256 with a different IV and with 32 of the output bits thrown away. For most purposes, if you want a hash with more than 128 but less than 256 bits, simply using SHA-256 and truncating the output yourself to the desired bit length is simpler and just as efficient as using SHA-224. As you observe, SHA-256 is also more likely to be available on different platforms than SHA-224, making it the better choice for portability.
Why would you ever want to use SHA-224, then?
The obvious use case is if you need to implement an existing protocol that specifies the use of SHA-224 hashes. While, for the reasons described above, it's not a very common choice, I'm sure such protocols do exist.
Also, a minor advantage of SHA-224 over truncated SHA-256 is that, due to the different IV, knowing the SHA-224 hash of a given message does not reveal anything useful about its SHA-256 hash, or vice versa. This is really more of an "idiot-proofing" feature; since the two hashes have different names, careless users might assume that their outputs have nothing in common, so NIST changed the IV to ensure that this is indeed the case.
However, this isn't really something you should generally rely on. If you really need to compute multiple unrelated hashes of the same input string, what you probably want instead is a keyed PRF like HMAC, which can be instantiated using any common hash function (such as SHA-256).