Information overload

I read the book ‘Future Shock’ more than 15 years back but didn’t realize
what it was trying to explain. It seems that the term “Information Overload”
was coined in 1970 by Alvin Toffler in this book.

When I started programming using Java it seemed like any other language
but I have learnt to look beyond the language. I use Java to earn a living.
So I am expected to know it very well but the languagealone is not sufficient
in the current scenario. Now I am expected to understand processes like CMM
( I tend to favour agile practices like XP ), design, frameworks,
enterprise integration, ecommerce and so many other things.

One can’t be an expert in everything.

It is impossible to keep up with the rapidly advancing software technology. How can
one read the various blogs, mailing lists, books, technology magazines and also work
and lead a reasonable life ?

That is why I am overwhelmed and cannot understand how people like Doug Lea( I read
his thread book )(http://gee.cs.oswego.edu/dl/html/vita.html) lead a normal life.

So these are the things that I have been trying to learn
There is information overload but time is limited.

Consider this shortened list.
1. BPEL, SOA, ESB etc. and Microsoft’s Web Service offerings.
2. Java 5, C# and all those new features. It will take several months just to
   investigate the generics features in Java and C#.
3. AOP
4. A deluge of frameworks like Spring and hibernate.
5. MDA and DSL.

etc. etc.

So right now my pet project is a UML 2.0 modeling utility that might help me learn
No. 5, 2 and 3 above apart from good OO programming.

Compile-time resolution of Generic methods

The draft Java Language Specification has this to say about Overloading.

8.4.9 Overloading

When a method is invoked, the number of actual arguments (and any
explicit type arguments) and the compile-time types of the arguments are used, at
compile time, to determine the signature of the method that will be invoked.

The difference here is the extra rule within braces.

This is the JLS second edition.

When a method is invoked, the number of actual arguments and the compile-time types of the arguments are used, at compile time, to determine the signature of the method that will be invoked.

Now code written using JDK 5.0 relies on the type arguments to determine the correct method even if we have two methods with the same name and no parameters like the following code.

public class Overloading {

public static <A extends String> A test() {
System.out.println("String");
return null;
}

public static <B extends Integer> B test() {
System.out.println("Number");
return null;
}

public static void main(String[] args) {
Overloading.<Integer>test();
Overloading.<String>test();
}
}

What I cannot do with generics ?

I am still trying to understand the full benefits of generics. I picked up the following that you cannot do with Java generics from the Sun generics forum where sometime back a generics debate was raging.

Use constants.
Cannot perform compile-time recursion.
Cannot do compile-time loop unrolling.
Cannot create full or partial specializations.
Cannot work with primitive types.
Cannot create arrays of generic types.
Cannot check generic casts at compile time.
Cannot do type analysis at compile time.
Cannot do anything with generics that would create multiple instantiations of the generic code.
Though I am not a C++ programmer, I found this article http://www.langer.camelot.de/Articles/Cuj/ExpressionTemplates/ExpressionTemplates.htm that would support many of the above points. It looks like a serious drawback of the Java implementation of generics.

  It would be interesting to check how many of the above are possible using C#.