dis·am·big·u·ous·i·ty

Paul Browne has written a follow-up to his article about how Java is “dead as we know it”: Java and those pesky Google APIs. Apparently the feedback was pretty negative to his first article. However, the guy has the right idea.

Its really not as drastic as some people want to make it sound (probably most of them are worried about their own job). I think relating this story to how things get done today might help get the idea across.

Today with many projects, there is an architect or a small group of people who are charged with creating and maintaining the API and/or frameworks for the application. In these types of projects, there is typically a much larger group using those APIs and frameworks to actually implement functionality for the client. For the sake of argument, let’s say the proportion is 20% API developers and 80% functionality developers.

Throughout the 90s, the most robust standard that would allow you to actually take advantage of this set-up was Java. Furthermore, all the tools and collaboration made it work great. However, everything basically had to be Java (for example, passing Objects along in your Request to the JSP).

Now there is a new standard that accomplishes all of those same goals, and it is web services. The platform of web services is a standard that can accomplish these goals but is much less restrictive (everything does not have to live in the JVM).

As a result, while the 80-20 dichotomy will probably be mostly unchanged in proportion and concept, it will be greatly impacted in implementation. Much of that 80% will not need the heavy solutions that we have created in the past.

However, that 20% will probably continue to look to Java to implement the robust applications that we need. Furthermore, making java open source will put it in a position to keep pace with the offerings of these newer technologies while leveraging the huge embedded base of developers that already know the platform.