Summary
In a recent blog post, Weiqi Gao suggests that Java frameworks will continue to proliferate, and that keeping up with new frameworks and framework features will become an increasingly tougher job for developers, offsetting some of the productivity gains frameworks promise.
Advertisement
In response to a recent discussion on developers' use of Java frameworks, Weiqi Gao suggests in his blog entry, Software Development: The Abstraction Dilemma, that enterprise Java frameworks will continue to proliferate:
What do you think the framework builders do day in and day out? Right, they build frameworks. Thus the proliferation of frameworks... And that creates pressure for the framework users to ever switching to the newer and better frameworks.
While Jakov Fain's initial post in this debate, A new breed: Framework Java Coder?, spoke mainly of developers who are adept at using a framework, but know very little of the underlying mechanisms of Java, Weiqi Gao's blog post questions the true productivity gains provided by frameworks:
... In the name of productivity, we have just created a situation where the framework users (that's the majority of us developers) have to waste our time to learn the new things that they [the framework builders] keep on churning out that ... they'll call garbage two years from now. And productivity suffers, because the things that are going to simplify our lives are making it more complicated.
He suggests that when appropriate, developers should use standard features offered in Java, instead of using a framework to accomplish the equivalent task:
Learn what's essential: Being able to use the String class from your language to achieve your string manipulation goals is essential. Making your application dependent on Apache Strings package (and seventeen of its dependencies) just to use a couple of their convenience methods is not essential.
Gao also suggests that much hype is created in the technical press about frameworks, since many in the technical press either have their own agenda or, more likely, because publishing about a framework always seems a safe bet.
Do you agree with Gao's conclusion that framework proliferation can offset the potential productivity gains a framework is supposed to provide? And, if so, do you see a back-to-the-basics sort of movement taking shape in the enterprise developer community?
It's good to avoid dependencies, using Java's standard libraries. But it's better to avoid duplicate code. The question is refactoring common code into an ad hoc library, versus adding a dependency on some existing library or framework.
I see unnecessary dependencies on old frameworks and libraries, for example, 3rd party libraries for regex, logging, and pooling. Applications on 1.3 needed these, but an application started on 1.4 could use the standard Java libraries instead.
It's essential to know that JDK 1.5 added String.contains(), so Apache's StringUtils.contains() shouldn't be used on 1.5. But it was better to use that Apache method (or some other library) than to use someString.indexOf(searchString) == -1.
[quote]Learn what's essential: Being able to use the String class from your language to achieve your string manipulation goals is essential. Making your application dependent on Apache Strings package (and seventeen of its dependencies) just to use a couple of their convenience methods is not essential.[/quote]
This seems to be a fundamentally different question about dependencies. There is something to be said here as the proliferation of "dependent on half of Jakarta" is becoming something that annoys me, but this is more about "API" rather than "Framework". I mean, you can use (insert framework here) and they don't care if you use java.lang.String inside your code or not. The problem you run into with this, however, is more about dependency convergence between, oh, Hibernate, Xfire and (insert web framework of choice here).
The question of frameworks, however, is about the constantly moving target of "recommended" programming models and the proliferation of "Me too" frameworks that are basically "Just like X but with Y" vs "Just like X but with Z".
The prime example of this, and one I am actually fond of is Stripes. It is basically Struts with Annotations. Now, I find the glacial pace of the Struts team to move to annotations and other language feature updates frustrating, but it begs the question whether we needed Stripes or just a few more committers on the Struts team.
The other "framework" issue is the issue of programming models. With RIFE, Struts, Stripes, Shale/JSF, Grails -- whatever -- you end up with entirely different ideas on what the programming model for a web app should be. Now toss in Struts-HTML, JSTL, Velocity, GWT and a couple other templating/view layer systems and the basic requirements for what you have too know to be a Java Webbish kind of developer becomes very very high. It isn't that these don't have their own advantages and disadvantages, but the lack of a "this is the way we do this" rule makes it seemingly much more "difficult" to work on the Java space than, say, .NET.
The framework race is a pointless rush to a deadend finish line. A lot of companies are currently making big efforts to ditch custom frameworks for something like Spring. Somehow "rapid development" turns into a 7-8 month project. God help them when something else comes out.
Frameworks initially served a purpose of bringing the day to day Java coder out of low-level thinking towards modern web development, but currently it's completely a hinderance. One horrible side effect is it causes a lot of defensive thinking in tech management. They're generally scared to touch anything without miles of tech marketing and evangelism.
> The prime example of this, and one I am actually fond of > is Stripes. It is basically Struts with Annotations. Now, > I find the glacial pace of the Struts team to move to > annotations and other language feature updates > frustrating, but it begs the question whether we needed > Stripes or just a few more committers on the Struts team.
More committers doesn't help - I'm sure struts has more than Stripes. The problem is bureaucracy (damn, that is such a hard word to spell!). Apache and Jakarta and their projects have gotten so big and so careful about their releases and codebases that progress has slowed down considerably. Some would argue it's a good thing, but it's only a good thing if you've already Gotten It Right.
I find it funny that so many project leads and committers worry so much about maintaining backwards compatibility that many users actually find it easier to change their dependency base wholesale than to work around the inadequacies of older projects fixated on their legacy issues.
Previous Topic
