Erasure/Reification and Forward compatibility...

Recently, while I was trying to build a core mocking API based on reflection with JDK 5.0 (what one would do during his spare time...), the amazing subject of (type) Erasure with Generics appeared to me...

1. (For those already knowing everything about erasure, roll a 20 and go to number 2) Thanks to JDK 5.0 Generics, most people think that Collections can now be brilliantly assigned specific types of objects, removing the clutter of casting-all-around. Don't be afraid, but Generics in JDK 5.0 are not really the Generics you think they are! For reasons detailed below, Generics where sacrificed at the altar of Erasure! So let's be more specific. When you declare... say... a Map<String,BigInteger> myBigIntegerMap and a Map<String,Float>, the compiler will replace them with a Map and a Map! The compiler keeps all the code in a common class and adds some type conversions and type checks along with bridge methods for the specific types you declared, but it completely erases your beautiful type arguments from the runtime code. This is (insert dramatic drum roll here) type ERASURE (insert crash of cymbals here)!
2. The positive effect is that it ensures backward/forward compatibility by (almost) not modifying existing collections and avoiding the mess that can be found in recent version of #ed languages and described in David dossot's blog entry. The negative one is that you will never be able to discover these types by reflection, because nothing differs myBigIntegerMap.getClass() from myFloatMap.getClass()... and you'll have the surprise to see that (myBigIntegerMap instanceof Map) is a true statement! I can't wait to see the java puzzlers derived from these Generics...
3. The opposite system of Erasure is Reification. In this system, information is kept at runtime as first-class entities and can therefore be accessible for the true happiness of ORM tools developpers and such... Tough talks went on long before the release of Generics with JDK 5.0 about whether backward/forward compatibility could be attained with reification. It appears that such a goal could be attained, but is not even planned (as I know of) for JDK 6.0...
   

So knowing that two questions pop out of my humble mind:

• Does a software of any kind always has to ensure backward and forward compatibility, even when slowing down innovations?
• Do JDK 5.0 code really has to run with older JRE's?

If you answered yes to any of these questions, then ask yourself : should these requirements be mainstream, or handled by adapters?

JDK should at least handle backward compatibility and moreover migration compatibility. Meaning that interoperability should be a real asset! This doesn't mean that Generics should be reduced to Erasure for the sake of it!
This just means that :

• adapted Serializers could be coded in order to ensure compatibility with existing older codebase used through RPC calls
• adapters could be coded for older codebase used in the same VM.

So what do we do now?
I for myself saved my day by just asking myself the right question : what is the most elegant way of getting to my goal as I can not wait for JDK 8.0 ? ;).

My own solution was an annotation added to the Collection attribute I wanted to attain by reflection. Annotations can be attained at runtime by reflection, and are checked by the compiler. This adds a little bit of clutter and doubles the declaration of my type argument(s) but it does the job!
So I now have to declare :
@CollectionRuntimeInfo{type=Integer.class}
private List<Integer> myIntegerList;
@CollectionRuntimeInfo{type={String.class,Integer.class}}
private Map <String,Integer> myIntegerMap;

So I was just wondering that if instead of replacing Erasure with Reification, the compiler could automatically add an annotation to the Generics with the type arguments, we would save the day without affecting the forward/backward compatibility paradigm!

But I'm not (and will surely never be) part of the JCP, and am probably occulting a lot of potential issues... but it's still worth looking ;)

From software to detergentware...

Web 2.0, Ajax, SOA 2.0 and 3.0; those are magic words to the ears of the Gartner-worshipers all over the the world. Adding buzz-words to buzz-words seems to be the latest trend in technological cocktails.
In fact, more than mere words, it is interesting to see how software retailers and software makers are now kept away from these buzz words.

Do you remember the beginning of the web Era? How many managers or marketing people have mispronounced or misunderstood the technical web jargon? But this was a jolly foolish time when marketing of software was technologically-driven!
Third millennium has dawned the era of real marketing in software!

Computing has never been about technologies by themselves... in fact it is more about who's going to use these technologies. And this is of course the job of marketing to link companies to their customers. Customers looking for incredible things like QoS, TCO and RoI...
But until last year or so, the frontier between technical concepts and marketing concepts was a one-way ride...

So where do Web 2.0 and SOA 2.0 come from? Are these merely technical concepts?

To me they are blankets pulled over the software market in order to convey a clear message :
"Web or SOA are dangerous investments for your company? Forget about this, Web 2.0 and SOA 2.0 are there! And believe me or not, they are simpler to use and provide a better result!"
So even if this sounds like the "even whiter than white" you could hear in any detergent commercial, this has two opposite side effects:
on one hand it brings a new interest from cautious companies to the products, but on the other hand it conveys the ambiguous message that older or not labelled Web or SOA implementations are hell on earth.

And this is where things are slowly shifting. The same way economy influences politics, economy and market clearly influences technology...
You'll say to me that this is not new, but it is quite disturbing to realize that in order to talk about the technologies you implement and/or originate, you have to adapt yourself to these marketing concepts...

In fact this shift is quite important and is quite representative of what's at stake in the coming years.
Open source project without a clear marketing plan are more and more out of the game, but more than that, they have to adapt to the advices of marketing/management gurus like Gartner. First SOA has been sold like a complete replacement of the frightening EAI acronym. Then SOA has turned from an abstract concept like OOP or AOP to a complete marketing concept shadowing the beauty of the described technology. And the whole World Wide Web (and all the underlying concepts) is now versionned by absolutely arbitrary and meaningless numbers.

But don't be mistaken, branding is quite important! Yet as long as a brand is applied to a product. But let's imagine that from now detergents enter in the era of "detergent 2.0"... and that each and every detergent company who wants to be taken seriously has to print a beautiful "detergent 2.0" logo on the product. You'll soon see all the products branded with this logo... and the concept being completely blown away.

There's hopefully still some room for products branded with reason and offering a good balance between technological efficiency and QoS/TCO/RoI.

But it is now a full-time job to invent detergent names for software and to understand what's white and what's whiter...