Comments on: Usability and Java 1.5 generics vs. Autocasting

By: spullara

spullara — Fri, 13 Mar 2009 07:09:35 +0000

You are totally missing the point on the example. There is no opportunity for doing what you suggest with JNDI because the common 'interface' is Object and actually may not have any commonality at all.

By: Chris

Chris — Fri, 13 Mar 2009 03:28:44 +0000

I think the point you are missing is that what you call a "mixed map" can often be folded into a generic through the use of an interface; wrap the elements of your map in an interface that abstracts the functionality that binds them together into a single map in the first place. Then you declare the generic map using the interface as the element type.

This has the side effect that you must make explicit in the API the design decisions behind why the elements are in the same map, thus self-documenting the features of the underlying connectivity between the pieces. This was part of the goal with generics. An object-oriented purist would say that anytime you are forced to cast you are missing an opportunity for polymorphism. Unfortunately the Java 1.4 Collections API forced you to cast just to use the most basic features.

In Java 1.5 we are closer to the ideal, which is that you should see every cast as an opportunity to add polymorphism.

By: spullara

spullara — Fri, 13 Mar 2009 00:09:35 +0000

By: Chris

Chris — Thu, 12 Mar 2009 20:28:44 +0000

By: spullara

spullara — Thu, 08 Jan 2009 21:59:41 +0000

Amusingly, generics in Java don't prevent you from using the wrong key type, here is some legal code that fails at runtime:

Map map = new HashMap();
map.put("test", "test");
StringBuilder sb = new StringBuilder("test");
String a = map.get(sb); // works fine, returns null, no error at compile time.

So even they do not prevent some kinds of errors that could be statically prevented. IntelliJ will warn you about that one though.

By: Krish

Krish — Thu, 08 Jan 2009 19:35:44 +0000

Hmmm... That putting the type checking responsibility on the developer. That's taking the main power of java (static type checking) out of the equation. In the EJB case, it's fine, because it will immediately be caught when we start testing the app.

But in a generic Map, in big apps, if we don't rely on the compiler to do the type checking if can become a big issue in a production environment. Having said that, java till 1.4 had that hole and that's what generics avoids by strictly typing collections.

Still there can still be uses for a mixed type maps. In those cases, your solution can reduce some clutter in the code.

By: spullara

spullara — Wed, 07 Jan 2009 18:51:56 +0000

The simple case where you have:

String value = map.get(key)

I'm not looking at what was inserted into the map, merely assuming that you know what you put in the map and automatically adding a cast under the covers so the bytecode actually looks like:

String value = (String) map.get(key)

Similarly in the case of doing a JNDI lookup, the developer has already declared the type that is coming out of the JNDI context on the left-hand side of the assignment and the cast is just repeating yourself.

By: Krish

Krish — Wed, 07 Jan 2009 18:49:47 +0000

Hmmm… If I follow your logic correctly, in the simple case, you know the type of the values by inspecting what is being inserted into the map. In a local map this is pretty simple to do… But what if it is a static map and values are getting inserted (retrieved) into (from) this map from all over the application code. How would you know what type you are supposed to autocast to at compile time. Generics elegantly solves that problem by letting us define the type of the collection.

Also, in the J2EE case, how do you know the type of the EJB to autocast it to? All you have is the jndi name.