If your bags of data have internal state, there's something wrong with your bags of data. I assume that the Java guys thought far enough to either exclude padding from comparisons or force padding bytes to be zero.

It should work even for strings: They will surely continue to be heap-allocated, and memcmp-ing pointers (inside the new "structs") is exactly an identity comparison.

▲

layer8 8 hours ago | parent [-]

There’s nothing wrong with having non-normalized representations, that’s why there is equals().

For example, you might have a value class for representing (limited-precision) fractions using two longs internally, for the numerator and denominator. For efficiency trade-off reasons, you don’t want to always shorten the fraction. But now client code can distinguish 2/3 from 4/6 using ==.

Scenarios of that sort are conceivable where this actually leaks sensitive information. In any case, it creates dependencies on implementation details where you don’t want to have them.

When designing a value class, you are now in the dilemma of either always having to normalize the representation, costing performance, or having your class be a funnel for leaking implementation details.

▲

ahartmetz 7 hours ago | parent | next [-]

Well. I'd be upset if custom operator==() for plain-old-data structs was removed from C++, but Java never had it to begin with, so for Java, it just means that you have to fall back to using traditional classes (or compare using something other than ==) if you need such "fancy" features.

▲

inigyou 6 hours ago | parent | prev | next [-]

Java can also distinguish a 2/3 object from a 4/6 object using == when they are not value types. It can even distinguish a 2/3 object from a different 2/3 object.

	▲	scotty79 3 hours ago \| parent [-]
		[dead]

▲

jstimpfle 7 hours ago | parent | prev [-]

> There’s nothing wrong with having non-normalized representations

There is a lot wrong with that: complexity, bloat, and slowness.

> But now client code can distinguish 2/3 from 4/6 using ==

That's a great way to obfuscate code. Not a good idea. The right way to do the comparison is, just make a function called CompareRational().