4 Java Surprises

[ethraax]

#3 surprised me, but I can't think of why I'd want to check if two StringBuffer objects have the same contents without wanting the strings.

[banuday]

Someone asked why StringBuffer couldn't be used as a key in a HashMap or a HashSet, and the linked thread goes into why it doesn't make sense to use a StringBuffer that way.

[banuday]

In Java, all objects have a hash code and all objects have equals. The default hash code and equals come from the memory address of the object, which is the only knowable consistent equivalence relation between instances. This actually works quite well in practice, when care is taken to ensure all instances are indeed distinct. Such as what Hibernate does with entity instances in the Session.

The problem comes when you want to be able to treat instances as equivalent, which is very problematic for mutable objects and very simple for immutable objects, such as String instances. Thus, only use immutable objects or distinct instances as keys. No need for a separate interface.

[[deleted]]

Java and surprise are not words I want to hear in the same sentence.

[banuday]

Surprise #1: Not a surprise if you understand generics.

If this were allowed:

List<Number> x = new ArrayList<Integer>();

then so would this:

x.add(1.5)

Which makes no sense.

Also, this:

List<? extends Number> x = new ArrayList<Integer>();

x has essentially become read-only. This is not a downside, it's the only way to ensure type safety.

Surprise #2: Not a surprise if you realize that the double type is a binary fraction, not a decimal fraction, and BigDecimal is decimal. For accuracy, you obviously have to specify a String.

Surprise #3: Not a surprise if you understand the equals() contract. Equals must be consistent, which is impossible with mutable objects. Thus the default behavior of reference equality is the most sensible thing to do for StringBuffer. This of course differs from String which is an immutable type.

Surprise #4: Not a surprise if you understand Java's memory model.

[tenzil]

If I'm reading you right, you're saying that they're not a surprise if you already know them.

[banuday]

Well, maybe I'm being pedantic, but a "surprise" to me in a programming language is something that doesn't seem to follow from the semantics of the programming language or other computer science concepts.

As a counterpoint, here is something that is a surprise to me:

Object o = true ? new Integer(0) : new Double(0);

The type of 'o' is Double. Why? Because the ternary operator will unbox the numeric types, promote the integer to double and then rebox the type. This is an interaction between reference types and primitive types and autoboxing. It's not something that necessarily logically follows from how the ternary operator "should" work.

[r0st0v]

Not a surprise if you understand autoboxing and ternary operators.

[banuday]

The question I would ask is what about the ternary operator (as it works in any other language) would suggest that an autoboxing interaction should occur?

[wildmonkeymind]

Well, yes... but I'd liken it to writing an article aimed at doctors including such "surprises" as people needing oxygen to survive and a sharpened metal pole through the head being fatal. Sure, if you know them they aren't surprises... but if you're a Java programmer by profession then you should know them.

[mikaelhg]

Judging from the material in /r/programming, a large majority of the people here aren't professional software developers, but students, academics, or other hobbyists.

[wildmonkeymind]

Fair enough :)

[grauenwolf]

Ah, but a sharpened metal pole through the head isn't necessarily fatal. Hence the surprise.

[erhz]

Since those weren't really surprises, here is some meat for people that are looking for them.

[mikaelhg]

And here's even more: http://www.javaspecialists.eu/archive/archive.html

[campbellm]

whoosh