RSS Feed

The Joel on Software Discussion Group (CLOSED)

I'm currently in the planning stages of building a hosted Java web application (yes, it has to be Java, for a variety of reasons that I don't feel like going into right now). In the process, I'm evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks.

And after spending dozens of hours reading through feature lists and documentation, I'm ready to gouge out my eyes.

Let's pretend I've decided to build a spice rack.

I've done small woodworking projects before, and I think I have a pretty good idea of what I need: some wood and a few basic tools: a tape measure, a saw, a level, and a hammer.

If I were going to build a whole house, rather than just a spice rack, I'd still need a tape measure, a saw, a level, and a hammer (among other things).

So I go to the hardware store to buy the tools, and I ask the sales clerk where I can find a hammer.

"A hammer?" he asks. "Nobody really buys hammers anymore. They're kind of old fashioned."

Surprised at this development, I ask him why.

"Well, the problem with hammers is that there are so many different kinds. Sledge hammers, claw hammers, ball-peen hammers. What if you bought one kind of hammer and then realized that you needed a different kind of hammer later? You'd have to buy a separate hammer for your next task. As it turns out, most people really want a single hammer that can handle all of the different kinds of hammering tasks you might encounter in your life."

"Hmmmmmm. Well, I suppose that sounds all right. Can you show me where to find a Universal Hammer."

"No, we don't sell those anymore. They're pretty obsolete."

"Really? I thought you just said that the Universal Hammer was the wave of the future."

"As it turns out, if you make only one kind of hammer, capable of performing all the same tasks as all those different kinds of hammers, then it isn't very good at any of them. Driving a nail with a sledgehammer isn't very effective. And, if you want to kill your ex-girlfriend, there's really no substitute for a ball-peen hammer."

"That's true. So, if nobody buys Universal Hammers anymore, and if you're no longer selling all those old-fashioned kinds of hammers, what kinds of hammers do you sell?"

"Actually, we don't sell hammers at all."

"So..."

"According to our research, what people really needed wasn't a Universal Hammer after all. It's always better to have the right kind of hammer for the job. So, we started selling hammer factories, capable of producing whatever kind of hammers you might be interested in using. All you need to do is staff the hammer factory with workers, activate the machinery, buy the raw materials, pay the utility bills, and PRESTO...you'll have *exactly* the kind of hammer you need in no time flat."

"But I don't really want to buy a hammer factory..."

"That's good. Because we don't sell them anymore."

"But I thought you just said..."

"We discovered that most people don't actually need an entire hammer factory. Some people, for example, will never need a ball-peen hammer. (Maybe they've never had ex-girlfriends. Or maybe they killed them with icepicks instead.) So there's no point in someone buying a hammer factory that can produce every kind of hammer under the sun."

"Yeah, that makes a lot of sense."

"So, instead, we started selling schematic diagrams for hammer factories, enabling our clients to build their own hammer factories, custom engineered to manufacture only the kinds of hammers that they would actually need."

"Let me guess. You don't sell those anymore."

"Nope. Sure don't. As it turns out, people don't want to build an entire factory just to manufacture a couple of hammers. Leave the factory-building up to the factory-building experts, that's what I always say!!"

"And I would agree with you there."

"Yup. So we stopped selling those schematics and started selling hammer-factory-building factories. Each hammer factory factory is built for you by the top experts in the hammer factory factory business, so you don't need to worry about all the details that go into building a factory. Yet you still get all the benefits of having your own customized hammer factory, churning out your own customized hammers, according to your own specific hammer designs."

"Well, that doesn't really..."

"I know what you're going to say!! ...and we don't sell those anymore either. For some reason, not many people were buying the hammer factory factories, so we came up with a new solution to address the problem."

"Uh huh."

"When we stepped back and looked at the global tool infrastructure, we determined that people were frustrated with having to manage and operate a hammer factory factory, as well as the hammer factory that it produced. That kind of overhead can get pretty cumbersome when you deal with the likely scenario of also operating a tape measure factory factory, a saw factory factory, and a level factory factory, not to mention a lumber manufacturing conglomerate holding company. When we really looked at the situation, we determined that that's just too complex for someone who really just wants to build a spice rack."

"Yeah, no kidding."

"So this week, we're introducing a general-purpose tool-building factory factory factory, so that all of your different tool factory factories can be produced by a single, unified factory. The factory factory factory will produce only the tool factory factories that you actually need, and each of those factory factories will produce a single factory based on your custom tool specifications. The final set of tools that emerge from this process will be the ideal tools for your particular project. You'll have *exactly* the hammer you need, and exactly the right tape measure for your task, all at the press of a button (though you may also have to deploy a few *configuration files* to make it all work according to your expectations)."

"So you don't have any hammers? None at all?"

"No. If you really want a high-quality, industrially engineered spice rack, you desperately need something more advanced than a simple hammer from a rinky-dink hardware store."

"And this is the way everyone is doing it now? Everyone is using a general-purpose tool-building factory factory factory now, whenever they need a hammer?"

"Yes."

"Well…All right. I guess that's what I'll have to do. If this is the way things are done now, I guess I'd better learn how to do it."

"Good for you!!"

"This thing comes with documentation, right?"

Now that I'm the proud owner of my own general-purpose tool-building factory factory factory, I'm satisfied to know that it complies with the GPTBFFF 0.97 RC2 draft specification for tool-building factory factory factories.

Luckily, 70% of the workers in the Tool-Oriented Metafactory Union are certified against this version of the spec.

On the horizon is a competing standard, though: a very compelling metafactory technolgy called the UXCTBFFF (Universal Trans-Continental Tool Building FFF), which promises to unify the factory factory factory industry to comply with guidelines of countries that use both metric and standard tools.

My understanding is that there will be a service pack to my GPTBFFF 0.97 RC2 to bring it into nearly 95% compliance with the UXCTBFFF standard, just by creating an abstraction layer through its user interface.

Sweet!!

Surely this new development will improve the quality of my spicerack (which I'll get around to building one of these days, as soon as I've got my factory factory factory all up and running, my labor force trained, my raw materials imported from Cambodia, etc).

Excellent, I thought I was reading Robert Sheckley for a little while.

He he, I actually found that quite amusing :-)

And seriously, as soon as you stop keeping things simple, you've messed up. Always use the simplest possible solution that (barely) gets the job done. Always.

I just got this bookmarked.

The funny thing is, my partmer and I were just discussing making a hammer. Do you think anyone would still be interested in something like that?

Why do I need a space shuttle if all I want is to cross the street? :-)

Congrats for the nice piece.

Now excuse me. I need to go to the moon and then mars before I can cross the street.

This would be much funnier if it wasn't true *tears hair out*

Kudos!

Fell off my chair! good stuff :)

Benji that's a nifty article. Why don't you spiff it up a bit, stick it on your website, and submit it for Joel's 2005 best-of book.

This is really fabulous. Very well written!!

Easy target, cheap shot.
Just take your favorite plattform and build all the stuff yourself. See you in 10 years again.

The STL is a framework and very productiv, the JAVA-RT is a framework and very productiv, the .net runtime too.
So just name the name the hammer within JAVA, C++, or dot.net wich is not sold anymore!

But anyway, very well written :)
I like meta factories

"All tools are Wal-Bell"

- Brought to you by the all-encompassing oligarchy that remains in the wake of that zero sum game known as unregulated global free market capitalism.

Nicely written.

I don't want to start yet another religious war, but for a nice respite from the complexities of J2EE frameworks, check out Ruby on Rails. I'm playing with it now and it is a pleasure to work with.

Some links to check out on Rails vs. J2EE:

Architecture:
http://www-128.ibm.com/developerworks/linux/library/wa-rubyonrails/?ca=dgr-lnxw01RubyAndJ2EE

Performance:
http://www.relevancellc.com/blogs/?p=31

I agree with "Game Programmer" and Martin.  It is EASY to over engineer a framework.  It is also easy to just flip the "not done here" bit and try doing it all yourself.

Both are stupid mistakes.

A good framework is nothing more than your toolbox filled with a good selection of tools.  Some tools are very general purpose (standard claw hammer) while others are very specialized (roofing hammer).  Having them all available and knowing when to use them is half the battle.

Stupidity is the idea that someone can make the one tool that does it all.  But as Martin points out, stupidity is also making all your own tools from scratch when existing tools work just fine. 

I don't want the uber-3000 software development tool that plugs into my head and spits out software.  Give me STL, ATL, WTL, MFC, CodeJock, .Net, Expat, CRTL, etc....  Let me be the craftsman who uses these tools to build the software I need.

Heh. Just notice the "What is with all the RoR spamming on this forum?" topic just below this one. Sorry, folks. But it is a nice framework.

Aargh. This is so true in Javaland. Everybody wants to build frameworks. End-to-end applications are so pedestrian. Also, we are waay to elite to be bothered with writing documentation, our idea is so sublime that it explains itself.

Benji:

Great post! In fact, I submitted it to Joel's Best of collection.

"But as Martin points out, stupidity is also making all your own tools from scratch when existing tools work just fine."

Yes it is stupid to build a tool from scratch when you have a working one. But sometimes you can find that a specialized tool can be better at something than the standard one. I can think of some cases when you just need to start from scratch and Do-It-Yourself.

If you have the time, it's always better to roll your own. If you don't have enough time, you'll have to make do with crummy stuff from other developers.

Any computing problem can be solved by adding another level of abstraction—except the problem of having too many layers of abstraction.

Larry Wall (I think?)

Great post!  Although you *could* go to Walmart and buy a cheap spice rack that is missing a couple of features...

Benji has a cute little story but if it's supposed to support some kind of argument against using frameworks then I'm not buying.

"I'm evaluating a bunch of J2EE portlet-enabled JSR-compliant MVC role-based CMS web service application container frameworks."

Your essay could have stopped here and we'd have understood your problem completely. 

Do people that come up with the descriptions of frameworks use a framework to help create the description? If so, what is it called, and how would it be described if it were marketed as a service?

The problem is not frameworks per se, it's these middleware "platforms" (like J2EE) that are created with complexity as a goal.

In general the business model behind "enterprise frameworks" is to add mind-boggling, eye-gouging complexity so that the middleware vendors can sell consulting and training/certification.  The easiest way to add such complexity is to build turkeys with ten layers of abstraction; developers, with their "Lord of the Flies" mentality, are all too happy to indulge in such excess.

Compare the frameworks of the past, such as the Win32 API (and the ill-begotten MFC, for that matter).  The basic idea there was always to create an actual platform for expediting development; the ends of which were more operating system sales.

The unfortunate fact of "enterprise" (web, even) development is that there isn't a consumer base to use the platform directly; therefore, the development tools suffer as a result.

Benji,

That has to be one of the *funniest* articles that I've read for awhile!  (Did you write it yourself, or did you get it from somewhere?  If you wrote it yourself, I seriously hope you're considering a second career writing comedy!)  Whatever the case, it's funny AND it makes sense too... 

Overengineering, just say no!

(Or perhaps it might make more sense to say "overengineering the overengineering that someone else has overengineered, just say no!") ;-)

But anyway, thanks again for some good laughs!

One of the interesting ideas coming out of the Ruby world is that "frameworks are extracted."

The idea being that if you build the framework first, you end up with an overengineered, hard to use mess.

However (the theory goes), if you build the application with the Don't Repeat Yourself principle in mind, you'll end up with some generally useful pieces that you can extract from the application.

Sorry to litter yet another thread with Rails posts. ;)

Well, good morning everyone. I wrote that little one-act play last night out of a frustrated need for catharsis (and in the midst of a bout of insomnia), and it definitely provided me with some catharsis.

But now that I'm a little more awake, I'd like to address the notion of using a framework vs. rolling your own framework.

I think it's a false dichotomy; I don't want to use any framework at all.

I know what several of you are thinking. I'd be out of my mind not to use some sort of framework. Am I honestly thinking of writing every single line of code that I'll need all on my own?

No, of course not.

What I'd really like to find are some appropriate *libraries* that I can use to provide several kinds of functionality for my project. Here's what I need:

* A library to use as a templating system for the presentation tier of my application. This API should be dirt simple.

* A library to use as a content repository (articles, essays, etc).

* A library providing a user-management API, for creating, editing, and deleting users, and assigning them different privileges.

* A library providing a threaded discussion forum API. This code should have *no* front-end gui. It should just provide an API of forum-related services that I'll need in building my webapp. I'll build my own JSP GUI on top of it.

* A library providing multi-user blogging capabilities.

Why is it so difficult to find simple libraries that provide these kinds of services?

The distinction between a library and a framework is subtle, but I think critical. A library is a collection of code that I don't have to write myself. It provides me with a set of objects and methods that I can use to build me application. If the library doesn't do quite what I want, I can make some small modifications or throw it away and use a different library.

A framework, on the other hand, always attempts to redefine the entire applilcation architecture. And, if the framework ends up not meeting my needs, I need to throw away my entire application, because everything I've written is defined in terms of the framework's methodology.

A library is something *contained* within my code.

A framework is a *container* for my application.

So, now that the working hours are in effect again, I'd like to actually *solve* my problem, rather than just complain about it. So I'm asking the JOS community whether they know of any *libraries* for building web applications. Libraries for forums, blogs, content management, user management.

No frameworks please.

totally agree about libraries vs frameworks... a key distinction and I think it's something most people would agree is a real issue...

Benji,

Sorry to have to do this, but have you tried Rails?

Sure, Rails describes itself as a framework, it is true, but...

Well, have you tried it?

Benji,

Simply hillarious! Thanks for the laughs :)

Ruby is not an option, or else I would look at Rails (becuase hey, I've already looked at several dozen other frameworks, so why not look at one more).

But really, it absolutely has to be Java.

If you have enough libraries that work together nicely you get a framework.

If you don't don't like stuff in the framework; rip it out.

Deleting lines of code is a lot more satisfying than writing them (at times!).

Try Perl, Template::Toolkit and CPAN.

Try PHP, smarty, PEAR.

I'm currently moving from the perl/php guy to learn some of what my cohorts have been doing with Java while I handled legacy stuff.

I'm an OO fan so there's a lot I like about Java but my gosh ... there's an awful lot of mess to go through to do simple things in the frameworks they are using. It's enough to drive one back to soc perl/php.

I installed the spring framework on my server at home. Ant built everything right out of the box. I uploaded the result war examples and everything worked fine. I love that. I've tried other Java frameworks and they don't build. I don't figure out why they don't build, I immediately rm -rf. It's like other apps ... they can at least verify if I have all I need before I start or ... get what I need, like using CPAN to install perl modules or something like apt-get instead of RPM.

Take a look at http://www.springframework.org/

I've got minimal experience with Java frameworks but spring looked reasonable and like I said, it built.

Well done, Joel! We don't agree on everything, but I'm right with you on the framework thing! And it's a great read as well!

Mostly Harmless,

Yeah, actually, I'm strongly considering taking some existing framework and ripping it to pieces, keeping only the bits that I actually need.

But it can be very difficult to determine whether a given framework actually has any of the services that I want. Most of these frameworks advertise their underlying technology rather than their capabilities when they talk about their feature set. So, for example, it's very common to see something like this:

"Built to conform with the new JSR-170 standard for extensible content repositories, this framework harnesses the power of Axis SOAP and the Apache Lenya XSLT transformation engine to provide a rich and robust application core. The underlying permission system employs SSO/LDAP solutions with custom authentication via JAAS login modules. In addition, the CMS backbone implements a full WebDAV stack, via seamless integration with Jakarta Slide."

And it's very rare to see something like this:

"The content repository handles centrally developed content as well as user-contributed content. Administrators can stage their own content, approve the content written by internal authors, and quarantine content written by user contributors. The content system can organize articles into a nested hierarchy of categories, or by the creation date of each piece of content. Articles and essays can be assigned into multiple categories. The forum module supports threaded or unthreaded discussions and can be integrated with the CMS system to support user-authored comments on individual articles. A private messaging system is available for users with the appropriate privileges, and certain users can also be granted permission to create their own blog entries. The user-management system has stubs so that application authors can create permissions to support their own application development."

I would *love* to see a paragraph like that in the feature list of one of these frameworks. But usually the feature lists don't tell me much.

It's like a chef telling me what kind of oven he used to cook my meal, rather than telling me what the food tastes like.

Very nice Benji, you made my day.

I have one question though: can you imagine how much money the factory-factory-factory / ex-factory-factory / ex-factory / ex-universal-hammer / ex-hammer makers are making on the hammer-buying people? Isn't this a brilliant marketing scheme?

If there is a problem with J2EE is that the people writing specs have agendas loaded with 99% corporate marketing and only 1% tech needs.

Licensing and consulting revenue at all J2EE vendors is up. Think about that before you decide to implement your small web site with anything more than servlets and JSPs.

I'm subscribed to the Apache announce mailing list and I've noticed that I often get announcements for their various Java frameworks and there is often no description of what the framework actually does.

Benji-

I'm using Tapestry (http://jakarta.apache.org/tapestry/) right now and it does a great job of separating the presentation layer from the rest of your code. It's certainly a framework, though, not a library.

javaOnTheRun,

I've actually worked with the Spring Framework a little bit in the past, and I don't like it. In fact, I think it's one of the key offenders in the Framework-As-Hidden-Complexity problem.

Actually, I haven't used much from Spring, so I can't comment on it universally, but I have a little bit of experience with its dependency injection features, and I think they're the worst kind of awful.

For example, in my original source code, I had a declaration like this:

class MyServiceClass {
  private IShoppingCart myCart = new WizzyShoppingCart();
  // Other stuff goes here.
}

In this code, IShoppingCart is an interface and WizzyShoppingCart is (obviously) the implementation class. According to the Spring methodology, it's bad practice to tie my interfaces directly with a particular implementation (what if I want to swap out my implementation later?), so the authors of the Spring framework recommend this:

class MyServiceClass {
  private IShoppingCart myCart;
  // Other stuff goes here.
}

The object is never instantiated. Later in my code, I might call methods on this object, even though I never explicitly called the constructor. Meanwhile, somewhere else, far far away in a configuration file somewhere, is the following snippet of XML:

<beans>
  <bean id="ShopCart" class="net.benjismith.impl.WizzyShoppingCart"/>
  <bean id="MyServiceClass" class="net.benjismith.MyServiceClass">
    <property name="myCart">
      <ref local="ShopCart"/>
    </property>
  </bean>
</beans>

...or something like that. I think I got the syntax wrong, but you get the idea.

The Spring documentation claims that "Your application code should *not* depend on Spring APIs." ( http://www.springframework.org/about ) Given the example above, their claim is clearly ridiculous. Without the object instantiation defined in the bean configuration file and performed by Spring under the covers, the object myCart will never be instantiated. So that's a clear *dependency* on the Spring framework. What make it even worse is that it's an invisible dependency. Just by looking at my application code, you can't tell that there's a dependency in place. There's no mention anywhere of the Spring APIs. I don't even need to "import org.spring.* or whatever. Yet if you get rid of Spring, my application will suddenly and cataclysmically break because the dependencies are no longer being injected, and my object never gets instantiated.

It makes me cringe.

And yet, for some reason, everyone I talk to just RAAAAVES about Spring. I don't get it.

Benji,
I hear you on Spring.  I hate to admit it, but I kinda bought into the hype and got all excited about it, until I started digging around in there.  Slowly but surely it dawned on me: there's no such thing as eliminating dependency, but boy you can sure obfuscate it.

Very nice story! So we should not use frameworks to generate what we need (especially not in a canonical or recursive manner). Instead use libraries?

Libraries consists of individual tools. When we diversify these tools, we will get a large set of similar, but slightly different tools. So it will be a problem to find just the right tool. Like "the right" information on the Internet, you do not know if it is there, and if it is then you need special tools to find it. Those search tools are meta-tools too. And if they don't find it, you still don't know if this is because it is not out there, or the meta-tool is not perfect.

So we don't use meta-tools to make our perfect tools, and we don't use meta-tools to find our perfect tools in the libraries. So the next step is to make our own tools.

But as a tool users I am not skilled in tool making. If I can effectively use every option of a compiler, I will not be able to build my own compiler yet!

So no factories, no libraries, no meta-tools and no making yourself. Now what? Evolution stops and we are still throwing speers and stones.

Aren't we glad we don't have to build our own cars? Aren't we glad we don't have to evaluate all cars? Aren't we glad we can use search engines to find reviews of cars? Aren't we glad we do not have to improve our cars? Aren't we glad we can use roads we never had to ask for? Aren't we glad there are maps? And route planners to create maps? And databases that feed route planners that create maps? And translators that convert satelite images into data to ...?

The story sounds absurd, but would we be happy if we did not have frameworks?

Pretty funny stuff.

This reminds me of a Components versus Frameworks discussion I had some years ago.  Summary: Components Good.  Frameworks BAAAAAD.

The idea is that something that just does a small thing well (like a standard hammer) is more useful and less prone to obsolescence that something that tries to form the basis of all existence (the general tool factory-cubed).

So for a Java webapp, why not use a set of simple components like JSP+JSTL, a DB layer (Hibernate, IBatis, etc.), and maybe a very simple Web framework (or write your own if you must).

I'll definitely be using servlets for my business logic and JSP (potentially Tapestry?) for my view tier. I *might* use Hibernate for DAO, but I'm very very skeptical of it as well. (I don't like to think of a database as a place to store my objects. A database is where I keep my *data*, though I may want to contruct various object types based on that set of data from time to time.)

But does anyone know of any user management or content management libraries? I'd prefer something with no front-end. Just a set of classes, if at all possible.

So true about frameworks vs libraries. I often start using a  framework because I want to use some cool class it contains, and soon find myself implementing IThreadableInstanceManifold in order to print "Hello World".

You lost me at "hello"

K9, you forgot your IThreadableInstanceManifoldFactory, not to mention a ThreadableInstanceManifoldFactoryImplementation and ThreadableInstanceManifoldFactoryImplementationStub for testing purposes.

How could you possibly have a simpler, more elegant, implementation of "Hello World" than that? I can't see how anyone can fail to see that!

Arethuza, please tell me you made those class names up.

BenjiSmith, that was an awesome post. Someone even thought you were Joel himself (judging from a few posts up...)

Benji

This is a classic. I hope it it is included in the next release of Joel's book. Thank you for a great read.

If the framework does not fit your domain you will end up fighting the framework.

Did you not analyse your domain properly ?

*Sigh*.

Benji's posts are indeed amusing and well written, but then it's easy for a good writer to make fun of almost anything in caricature.

The primary difference between a class library and a framework is that a class library provides a collection of loosely related abstractions, which its users compose as they see fit to solve a broad set of loosely specified or unspecified problems, while a framework provides a specific composition of abstractions designed to solve a specific class of problems.

The framework makes more assumptions about the problem domain, and consequently captures more knowledge about solving problems in that domain than a class library.

It sounds like a large part of the passion behind the thread has come from people naively choosing to use frameworks to solve problems they were not intended to solve.

Finding that the frameworks could not be easily adapted to solve these problems, the would be users of the frameworks appear to have concluded that any attempt to provide a tool with a better fit to purpose than a class library is dangerous and evil.

And yet we marvel at the Salem witch trials.

Presumably relational database engines are also dangerous and evil because they do not allow the developer to design his or her own data storage formats and access strategies?

While relational database management systems can indeed be frustrating at times, and while there are indeed some situations that call for writing custom data access methods, of which I have written my fair share, computing in the enterprise would be set back by at least a decade if we were to capriciously eschew all use of relational database management technology and embrace a philosophy that calls for developing a custom data access method on every project.

If the challenges you face are such that you can solve them quickly by writing everything from scratch, then please do so without blaming tools developed by others for specific purposes.

Like the doctor to whom the patient complains that it hurts when he does this or that, we reply, "Then don't do that".

On the other hand, if after careful examination of the problem at hand, and of the available tools, you find a tool that claims to meet your need, then by all means try it.

Of course, I'm not defending all frameworks. Many are poorly documented and poorly supported. We have long way to go as an industry in learning how to become suppliers of tools that other people find useful.

No doubt, some frameworks are also poorly designed, and cannot be saved by any amount of documentation or support.

But please, if the tool you choose fails to fulfill its promises, don't make sweeping statements about the dangers of attempting to create or use tools more complex than a class library, especially in public.

Similar statements were made about early machines, which were also deeply misunderstood by poorly educated crowds, often to the detriment of their inventors.

Sadly, there are always too few champions of reason to save unfortunate victims of circumstance from the popular uprisings of the simple minded and the uninformed.

Besides, as far as I know, no one has advocated taking general purpose programming languages off the market in favor of software factories.

Jack, I completely disagree with your characterization of the difference between libraries and frameworks.

You said:
> The primary difference between a class library
> and a framework is that a class library provides
> a collection of loosely related abstractions, which
> its users compose as they see fit to solve a broad
> set of loosely specified or unspecified problems,
> while a framework provides a specific composition
> of abstractions designed to solve a specific class
> of problems.

You've got it bass-ackwards.

I'm looking for a few particular kinds of libraries:

* User Management

* Content Management

* Forums

* Blogs

Those are *specific* needs. That's not a loose jumble of loosely-related abstractions.

To contrast, take a look at the list of features from Spring, everyone's favorite "leading full-stack Java/J2EE application framework":

http://www.springframework.org/about

* The most complete lightweight container, providing centralized, automated configuration and wiring of your application objects.

* A common abstraction layer for transaction management, allowing for pluggable transaction managers, and making it easy to demarcate transactions without dealing with low-level issues.

* A JDBC abstraction layer that offers a meaningful exception hierarchy (no more pulling vendor codes out of SQLException), simplifies error handling, and greatly reduces the amount of code you'll need to write.

* AOP functionality, fully integrated into Spring configuration management. You can AOP-enable any object managed by Spring, adding aspects such as declarative transaction management.

* A flexible MVC web application framework, built on core Spring functionality.

That doesn't sound to me like a "specific composition of abstractions designed to solve a specific class of problems." It sounds more like a boil-the-ocean re-engineering of every aspect of enterprise development. (And yet somehow, without providing *specific* functionality for common things like user managment.)

The biggest problem with these frameworks is that they intend to be everything to everyone, a completely generic solution-for-everything. But when someone creates a completely generic, highly configurable solution, they have to outfit that solution with a zillion knobs for configuring all of its parameters. And in order to become a consumer of that framework, an application author has to spend a considerable amount of time learning how to use it to solve their particular problem.

And I content that, in many cases (especially for any of us who aren't fortune 500 companies), the amount of time spent learning how to customize the architecture of the framework to my particular circumstance is greater than the amount of time it would have taken to just roll the goddamn thing myself.

Not that I want to roll it myself.

If there were some *libraries* that didn't try to boil the ocean and redefine the way people develop applications, then it wouldn't be so needlessly complex, and I could use it in my application.

But the focus isn't on libraries anymore. It's on frameworks.

And, of course, I don't mind the fact that frameworks exist. For certain large applications, I'm sure the framworks solve some of their problems (distributing an application across a whole farm of servers), but for the majority of projects, the problems that we really need to solve are the kinds of problems that would be better handled by libraries of reusable code.

By the way, Jack, can't you state your point without being so condescending?

I don't appreciate being characterized as naive, simple-minded, or uninformed. And the only salem witch trial that seems to be going on is the one you're creating.

Just put down your pitchfork and your flaming torch and have a reasonable conversaion. Maybe try some humor. People seem to enjoy it.

"And yet we marvel at the Salem witch trials."

Mere child's play. Let's compare Benji to the Nazis instead.

Benji eats Salad Cream!

I really enjoyed this article.  I think in some ways it relates to what I call "scaling down".  Make something complicated, and certain people will simply not be up to using it.  Make something simple, and even if they're not great programmers, and produce code that might not be very elegant, at least they're able to get what they need done.  I wrote a little bit about it here:

http://www.dedasys.com/articles/scalable_systems.html

Interesting to note that .Net is not immune from "frameworks", there is a port of Spring at:

http://www.springframework.net/

However, elements of this framework (Inversion of Control) are apparently already supported in .Net:

http://weblogs.asp.net/cazzu/archive/2004/05/10/129140.aspx

Given the choice, I'd rather use the latter approach (which is closer to the "libary" model) than the apparently all encompassing framework approach.

Time will tell!

Great article!

Well... but "generality", "reusability", "extensibility", etc. are typically seen as Good Qualities(tm). I think these things are semi-good, as long as they don't intrude too much into the progress of solving the original problem... but some people -- lots of people -- seem to have it backwards. *sigh*

Benji, I think the only thing you're going to find that meets your needs are "quasi-extensible stand-alone applications". That's a long and made-up phrase, so I'll elaborate.

For example, you want to be able to include blogs and CMS services in your product. Well, it's easy to find complete open-source packages that do each of these functions, and even do them in a way that they can be controlled externally. But, this is not the core purpose of these projects. Extending them to meet your needs means hacking them horribly. This is really your only option.

To hijack your lovely analogy, it's sounds like you're opening up a speciality garage which you want to include, among other things, the highest quality tools available. But at the store, they don't sell individual tools. Tools only come in bulky packaging with a dozen other irrelevant features. You might be able to strip out the parts you don't need, but there is a good chance you'll destroy them in the process.

Instead, what the store really wants to sell you are tool foundries. These make it possible for you to produce your own custom tools at home, albeit with a lot of effort.

Sorry about that.

The best Java Forum package I had seen (excelent API, ability to plug in own User authentication, etc.): http://jivesoftware.com/products/forums/
So easy to use, it was a pleasure!

Really wish there was a blogging package that good.  I have thought that Jive API could be adapted to do a Blog-style site.  Each Blog would be a Forum.  Blog posts would be a thread, and comments would be messages in that thread.

Yep, Robby, that's exactly what I've started doing. I've started the process of ripping the API out of JForum ( http://jforum.net ) and the blogging API out of Roller ( http://rollerweblogger.org ).  The user management API that I end up with will be an amalgamation of the user management in both JForum and Roller.

Once I've got functional APIs for forums and blogs, I'll find an appropriate CMS package and do the same thing.

This whole thread is about the issue of "simple" vs. "complex".
The problem being that although people have some idea about one thing being "simple" and another "complex" when pinned right down, they really have trouble describing the difference.
In the world of data mining ocam's razor is used.
They take it to mean that the solution with less symbols is the simpler solution.
Of course, that doesn't work.
One word (symbol) to represent a difficult idea does not make the difficult idea simple.
Rather simplicity has to do with "degrees of freedom".
The problem is "degrees of freedom" is only well defined in certain disciplines.
Clearly though, frameworks typically increase the number of decisions that a developer needs to consider.
A good framework; then, decreases or at least makes obvious the decision paths.

Benji,

If you are successful in finding, or creating, your libraries I hope that you collect them somewhere for the rest of us. This community process of needs and solutions should be able to combat the various and sundry frameworks available.

We should become the change we want to see.

Wouldn't it be nice to see a site a couple of months from now that lists libraries and the no-nonsense "here's what it does" descriptions that we're all asking for?

Thanks for the humor the conversation.