Wednesday 14 December 2005 @ 8:03 pm
Java is fun, Java is nice but most of all Java can be damn complex! This is something that hit me when visiting several sessions during the JavaPolis. A creepy feeling got hold of me when watching some ego’s fighting over the question “what is the best framework to use!”. People started talking about Spring, Seam, Rife and every framework you can think off. Offcourse frameworks are invented for some reason, but why is the Java community not able to settle and choose 1 standard framework?
Creativity is something that must be encouraged and nurtured but sometimes it is nice to share the same idea and head towards one direction.
One question stays on my mind:
Are we as Java developers taking pride of our own invented complexity?
— By Marco Pas PermaLink
December 15th, 2005 at 1:11 am
Let’s have a look at Ruby/Rails at the moment everything is so simple as long as we play with Rails rules.
There will come the time when some people are not happy with Rails, and want to invent their own Ruby based framework.
Convention won’t stay long because everyone has different tastes.
I don’t like the fact that Ruby/Rails don’t do i18n properly.
I hate Rails scaffolding, I hate Rails deployment mechanism.
Should I come up with my own thing?
December 15th, 2005 at 6:09 pm
I can’t, for the love of god, think of one moderately successful programming language
that has settled for just “one standard framework”. Please tell me what that might be!?
December 15th, 2005 at 6:11 pm
Well, actually one of the major themes for the coming new versions of Java, (Java EE 5 and Java SE 6), one of the major themes, and one of this year’s buzzwords, is Ease-of-Development (ofcourse, conveniently abbreviated to EoD).
The promise is that a lot of things are going to be simpler in the future, especially EJBs. Instead of writing an EJB class that extends EJBObject and has to implement a number of “magic methods” such as ejbCreate(), ejbRemove() etc., plus writing a bunch of interfaces and an XML deployment descriptor, you simply write a POJO with annotations.
When you’re visiting an event like JavaPolis you see that there’s so much going on in the Java community - JSF, framework X, framework Y, Java Persistence API, EJB 3.0, Java EE 5, Java SE 6, etc. - you might get the feeling of being overwhelmed by all those new things happening. It’s just so big that it’s impossible to try and understand it all at once.
The fact that we see so many frameworks is a proof of the fact that there’s a lot of innovation going on in Java. The good side of this is that there’s a lot of choice, the hard thing is: how to choose…
December 15th, 2005 at 9:49 pm
Toni, does visual basic rings a bell
January 2nd, 2006 at 3:43 pm
Java is complex. A few statistics may back this claim:
1. In his annual IT Impact forecast, Wim Groenendaal showed that development productivity increased from 8 hours/function point in 1970 (using Cobol for monolithic applications) to 2 hours/function point in 1990 (using 4GL for client/server apps). However, productivity decreased to 12 hours/function point in 2005 (using Java for web-based distributed applications, using a wider range of application architectures).
2. Les Hatton gathered data about the maintenance effort for both conventional and object oriented applications (comparing C and C++). His results indicated that on average it takes twice as much effort to fix object oriented bugs. Although this result is not specific for Java, there is no evidence that Java does much better.
Some plea in defense of Java that the function points of 1990 can not be compared with those of 2005. The reason behind this is that Java applications support a number of non-functional features, like security, scalability and so on. However, wasn’t this exactly the reason that application servers were introduced? To get a whealth of non-functional goodies for “free”?
There are other indicators of the complexity of Java: patterns UML, and frameworks. Patterns are introduced to formalize best practices, and to help developers to do things right. Obviously there is a need for patterns, that was not present in classic approaches and conventional programming paradigms. This need comes from the inherent complexity of OO programming in general and Java in particular.
Whereas a class may be an elegant container of related but limited functionality, an application contains often a large set of classes that are related in intricate ways. This complexity can only be understood in terms of graphical modelling techniques such as UML. UML and OO are thightly bound to each other: it is not possible to model software in other paradigms in UML, neither is it possible to design large OO systems without UML.
Frameworks help to hide or abstract away from low level details and complexity. They may help in increasing productivity, but there is no evidence that such a claim is true. I think that many frameworks replace low-level complexity by high-level complexity. How much do you gain if you replace 15 pages of Java code by 5 pages of Java and 8 pages of XML configuration?
So, Java is quantifiable complex, and this complexity lead to the introduction of methods, tools, techniques and concepts that were not necessary in the classical approach. But what caused this complexity? In my opinion (but it is opinion only) there are several factor that contributed:
1. Java has been a technology in search of an application for a long time. First it was aimed at embedded systems, then came TV set-top boxes, followed by dynamic websites and applets. Still later it was portable desk top applications, web based enterprise applications and recently focus shifts back to the desktop. This lack of focus has left its marks both in the language and in the huge amount of APIs.
2. Java is huge. The language itself may be small enough, but there are far too many APIs, some (most?) of them hastily and poorly designed, some of them conflicting and others buggy. But even if it was well-designed, consistent and of high quality, its sheer size is still baffling. Nobody can grasp them all, specialization is required. And some of this specialized knowledge is subsequently transformed into patterns or used in the design of ever more powerful frameworks.
3. Java changes too fast. The exteremely high pace of language and API development not only leads to APIs of poor quality, but makes it impossible for the humble developer to follow it all and keep up to date. This in turn leads to a huge lack of knowledge and poor software development practices.
4. Java inherits the inherent complexity of object orientation. But I’ve said enough about that.
Am I proud of this complexity? A strange question. Quite some time ago, I stated that managing complexity is the essence of computing science. Perhaps the most important technique to manage complexity is avoiding unnecessary complexity. And I strongly believe that much of the complexity of java is not necessary. No, you can neer be proud of this monster. But at the same time, this complexity has a strong appeal to developers. It is a great feeling to be able to master the difficulties and create a system that actually works. Look ma, no hands! We are all proud of such achievements. The ability to successfully build Java applications separates the men from the boys, and provides intellectual gratification. And not only that, Java programmers make more money than the poor kids that have not yet reached our superior level. (This is of course not true in LogicaCMG, but that is an entirely different thread).
I assume that Marco Pas referred to this personal and intellectual gratification when he wrote “Java is fun. Java is nice.” From a technical point of view, Java is not fun, and it is certainly not nice. In his IT Impact 2005, Wim Groenendaal quotes a statement of the Butler group: “[Java is] indecipherable and totally unfriendly”. The real chalenge is not to write working systems in an unfriendly language, but to create tools and methods to use that unfriendly language in a friendly way. Frameworks may or may not be the way to go. But if we succeed in taming this dragon, then we can really be proud!