Primitives vs. Real-world objects
Throughout both the .NET and Java frameworks, there are beautiful object which represents real world things like languages (java.util.Locale or System.Globalization.CultureInfo), files (java.io.File and System.IO.FileInfo), dates (java.util.DateSystem.DateTime), et cetera.
However, nobody tends to use them, especially not in enterprise software. It’s a bit more difficult to store a Locale in the database than a string. In some cases, you will have to do some processing to do so, but I think this processing is worth it, because the classes are much clearer and less error-prone than primitives. If you use a primitive to represents a real-world thing, you always have to determine how to store it in the primitive. If you work in a team, every person working on this code has to know, honor, and remember this format.
For instance, if an integer represents a date, everybody who uses the code will have to agree on the specific way the integer represents a date. It could be the number of seconds since 1970, or it could be the number of days since 1980. Basically it could be anything, and the only guard you have against someone storing anything in the integer is a manual agreement.
Addititonally, the classes give you functionality that the primitives do not offer. Like determining the display name of a language, or checking whether a file already exists.