[bunderbunder]

Keep in mind that Java came out about 5 years before a certain similar language that has reference types. The designers of that language made some decisions based on trying to learn from things that didn't work out so well in Java.

To some extent both languages were trying to deal with C++'s having three different kinds of types: Atomics, objects and structs. If I had to tell a made-up story, I'd guess that Java's designers looked at that and decided structs were in many ways just a more limited version of classes with some confusing semantic quirks, and therefore decided to nix them. That left atomics and objects, and the rest is history.

C#'s folks then reconsidered it and realized that, from a high level perspective, atomics are really just a special case of structs. (Side note: still telling that made-up story.) So they kept structs, unified them with atomics in the language,* and let the compiler deal with the rest. It works well and seems like an obviously better way to do it, but I'm not sure that insight would have been so obvious in the moment.

* Edit: Oh, and made structs a subtype of System.Object. Unlike Java, .NET's more-or-less fully object-oriented.

[Sharlin]

C++ doesn't really make a difference between builtin and user-defined data types. They all have value semantics, and a lot of effort has been spent to make user-defined types able to mimic builtin types as closely as possible. Classes and structs have no semantic differences besides default visibility of member names. For reference semantics, you use explicit references.

Java wanted to enforce reference semantics (and heap storage) for classes, but still wanted to retain value semantics (and stack storage) with fundamental types for performance reasons. The result is the mess we have now.

[pjmlp]

Many languages older than Java do the said conversion between value and reference types.

They just wanted to simplify the compiler.