The Toolkit for Online Communities
16688 Community Members, 1 member online, 2007 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : A Technical Paper on Java

Forum OpenACS Q&A: A Technical Paper on Java

Icon of envelope Request notifications

Posted by Ben Adida on
Over the past few months, the OpenACS community has been besieged by questions concerning Java. Having worked with a number of Java-backed systems, I decided to write up a technical argument as to why OpenACS is making limited use of Java. This is a draft, so please, for now, don't redistribute this link, don't post it to any other forums, just comment on it in this bboard. I would love to hear everyone's opinion on this paper. I will be writing more of these (not just about Java), and I encourage all who have experience with specific technologies to do the same.


Posted by Ben Adida on
One quick note: I will turn on general comments on this paper when it
is no longer a draft. For now, don't forward this article, let's keep
the comments within the community, on this bboard.
Posted by Talli Somekh on
Looks great Ben!!! I took a very quick look and I have some suggestions, but I think it's absolutely great.

Thank you very, very much. I really appreciate your work specifically here, and in general.


Posted by Jamie Ross on
Well said Ben, it mirrors my thoughts from my experience with both AOLserver/ACS and Vignette Storyserver.  TCL may not be the absolute best scripting language but combined with the AOLserver API it is a very good combination and I see little to recommend switching to the complexity of a java based solution.  I totally agree that the capability to call java, python etc from tcl/AOLserver is a great asset and the best way to go at the moment

good work!

Posted by carl garland on

Good job Ben a much needed link for future here are my kneejerk thoughts.

I use TCL because AOLserver exists and it is the optimized included language offering the best bang for buck programming wise with AOLserver. Why AOLserver is a different question but if Java or COBOL were the language as tightly integrated I would use them till another language was available that provided superior performance and brought to the table the same features/performance.

I think many people dont understand the underlying TCL integration that exists in our application server (aolserver). If AOLserver didnt exist I would probably use Java because the things I need / want are next best found in that toolset but are better in AOLserver. For me I think its not a question of picking a language but rather picking a tool and then the best language to go with it to get the job done that I am after.

I am just happy that TCL brings some nice things along with it since it is really the only option for my tool of choice.

Best Regards, Carl Garland
Posted by Walter McGinnis on
I echo the "well done Ben".  Thanks for the strong document.

My only comment is I would like to see harder of examples of your evaluation of Java based solutions.  Maybe a companion document that evaluates the ones you are talking about against the sets of criteria you use.  Or just more links to feature lists for various Java products, etc.

Posted by Kevin Scaldeferri on
I'll pose a few naysayer comments and questions, since no one else seems to want to.

This doc seems mostly to be arguing why you are happy with TCL and not inclined to go through the work involved to switch languages.  That's perfectly fine, but the article is posed as an argument about the inherent potential of the two languages.  So, I'd like to see a little more honesty about the real issue under consideration.

In a number of places, there are comparisons made between (Open)ACS and Java.  But, you're comparing apples and oranges.  The fair comparison is AOLServer/TCL vs. Java (& a servlet container) or ACS TCL vs. some Java application development framework.  The fact that the comparison you make isn't a complete slaughter is a tribute to the strength and extensiveness of the standard Java libraries.

I have a number of objections to the section on the conflict between abstraction (by which you seem to mean object-orientation) and RDBMSs.  Certainly the O-R mapping problem is hard, but I think your third paragraph about the number of database interactions and the inherent scalability is based on naive assumptions about how you approach this issue.

Posted by Talli Somekh on
I think that this is a very strong beginning, Ben, but as you said I look at it as a draft so I hope my comments are useful.

I think that as an argument for OpenACS it's excellent. But as Walter pointed out it needs a greater comparison to some of the Java apts out there. In the section entitled "Java and J2EE -- not that revolutionary", the first paragraph is a mention of what Java is and the rest of the section is another argument for OpenACS. I think that's fine to use those arguments, but this section should probably be a more objective analysis of Java.

Kevin Scaldaferri writes: "This doc seems mostly to be arguing why you are happy with TCL and not inclined to go through the work involved to switch languages. That's perfectly fine, but the article is posed as an argument about the inherent potential of the two languages. So, I'd like to see a little more honesty about the real issue under consideration."

Kevin, excuse me if I find it ironic that you are saying this (since I'm considering you a representative of aD, fairly or unfairly) but aD made the very specious claims that Java is 2x as fast as AOLserver (here (http://www.arsdigita.com/asj/building-scalable-ebusiness/) and the resulting post (http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000dpo&topic%5fid=web%2fdb&topic=) without a whole lot of documentation describing the specific test.

Some helpful comments, like how aD solved the O-R problem, would be nice.


Posted by Dan Wickstrom on
"Some helpful comments, like how aD solved the O-R problem, would be nice."

I would also be interested in hearing about this. I've been following the java development, and the proposed persistence solution seems extremely cumbersome compared to just writing sql queries. The goals for persistence seem desirable, but the object-relational mapping doesn't seem to be going well.

Maybe as an outsider, I'm just not appreciating the advantages of the new persistence scheme, but it seems to be unecessarily complex relative to the old aolserver/tcl approach.

Posted by Rafael Calvo on
Ben, Good document. I can not add anything from the technical point of view, but my feelings about your "how to chose guide" (in which I *technically* agree) are different. In my experience the people who *buy* will have exactly the opposed priorities:
  1. The general popularity of the language
  2. The availability of proven, useful packages of functionality
  3. The extensibility of the language platform
  4. The programming language's inherent adequacy to the task at hand
And I believe that the difference is what made aD change their way. In fact I think that it is why Microsoft is putting so much money into marketing C#, because they know that each developer is programming in C# for .NET is potentially one less for the competition.
Millions of dollars and men hours have been invested in Java. How is it that Microsoft suddenly has a "competitive" alternative?
How do you think opening the doors to the idea of OpenACS/C#, becomes part of this power game?
It would be interesting to highlight in your document that students at MIT, UCB, CMU and at least a couple of Univ. in Australia are studiyng Tcl. Maybe some figures from sciptics?
I apologize if you wanted to keep this discussion strictly technical.
Posted by Tom Jackson on

You could start from scratch with AOLserver and be more productive than you could with Java. Just pick up O'Reilly's _Java Servlet Programming_, read a few chapters and you if you didn't already know it, you would find that you have to reinvent the wheel for everything.

Unfortunately, when you compare OpenACS with Java, you need to really compare OpenACS to ACS Java. Give aD some credit. They made using Java relatively easy. Now they provide db connectiviy, nice macros, templating that is simple. And it is still free!

The downside is that it is still Java, and development is still way too anal. There isn't really a nicer way of expressing it.

Another point to be made is that Tcl is more than a language. It is a glue that holds things togeather, which is exactly the problem of the web. Anyone that can program in any 'real' programming language can pick up Tcl quickly. All tcl commands can be be displayed on half a web page. Compare that to Java.

Tcl can be extended easily. I have zero training in C, meaning I have never written a program longer than a few lines. From this point I created a mostly functional ns_ldap module in two weeks of spare time.

Posted by Todd Gillespie on
Fantastic paper, Ben! It concisely enumerates the reasons that I have been struggling to explain to clients and collegues. If there is anything I could contribute, it would be:

Java OO vs RDBMS: I would relate more concrete figures in this section. There is much to be said on how OO can break JOIN semantics, but on a related subject is how the predilection of most app servers to attempt to abstract away the RDBMS makes programmers unaware of RDBMS performance. PhilG related, in one of his recent one-day courses, that an in-memory object can be updated a few hundred million times per second, but a RDBMS can only issue a few hundred COMMITs to disk every second under optimal conditions. The naive Java programmer, using an abstraction best titled 'magical persistence', can see a 6-order of magnitude drop in expected performance. I've stopped counting the number of systems that take this approach.

I have always thought the most attractive technical thing about the ACS is how close it stays to the database (acting very like a responsible DP application). The authoritative location of data is never in dispute, and flow of control is relatively easy to follow (even with nsd filters in the way). IMOH, the ACS avoided lots of sophmoric design mistakes, eg, trying to outsmart the DB, which just turns into a nightmare trying to debug your cache.

None of this is explicitly against Java, except that:

Strong static typing makes SQL a PITA: any ad-hoc SQL querying in Java is burdened under layers of code casting vars to string and constructing strings. There is no concept of string interpolation nor of automatic casting. Fetching results is equally difficult due to its inflexibilty: I just recently dealt with a system wherein the developers assigned any numeric query values to java integers....eventually they wondered why all financial records were rounded to the nearest dollar... The combination of difficulties on both input and output of RDBMSes naturally tends to encourage abstracting away the DB, leading to the evils proclaimed above and in Ben's draft.

Strong static typing is a boon when a module has predefined functionality (no lambda), certain garantees on inputs, and a large amount of complex operations on internal data. The provided invariance enhances stability on such problem domains. But when working with large amounts of foreign data of varying structure and content, the restrictions are a major disadvantage. In web applications, Java objects are best keep, much like monads in Haskell, kept in a closet out of the way of primary execution.

I hope someone here can express that with more clarity than I have.

My pet peeve is that Java is just the incremental language upgrade to IT departments the world over that we see every 7 years or so. Perhaps my rancor is getting away from me, but it seems like the industry tries to spoon-feed new language developments to its customers; and for what? so as not to scare them? to ensure future revenue? laziness on everyone's part?
But the majority of the above named '2 million' Java developers have never been exposed to first-class functions, ML typing, Sather iterators, the arch-god LISP, the sheer coolness of Ruby (best described as a cross between Smalltalk, Perl, and Kick-Ass), etc, etc. What I would like to know is how to relate to managers and programmers everywhere that it is safe to move into the present.

This thing, that hath a code and not a core,
Hath set acquaintance where might be affections,
And nothing now
Disturbeth his reflections.     -- Ezra Pound, "An Object"

Posted by Ben Adida on
Thanks for the comments. Please continue to submit more! I will put up a new draft based on these comments within a few days, and announce it on this thread. In the meantime, here are some answers to the comments:
  • Carl & others: you're right that I'm not clearly differentiating Tcl the language and AOLserver/Tcl the platform. I will improve this in my next draft. I'm making a statement about the platform much more than about the language.
  • Walter & Talli: I think the issue you're seeing is that I'm straying from my main goal. My attempt here is to speak about the J2EE platform solely within the confines of the OpenACS approach. This is not so much a paper for convincing J2EE people to move to OpenACS. Rather, it is a paper to explain why, where ArsDigita is moving to Java, we're not. I will attempt to make this clearer. However, both of your comments indicate that there is *also* a need for a paper on comparing the J2EE and AOLserver/Tcl platforms more directly, with no initial platform bias. This is *much* more difficult. I'll see if I can make some initial headway in that direction, and am happy to hear others' opinion on that topic, too!
  • Rafael: Yes, this is purely a technical paper for now (thus the title). The business approach is totally different, and I don't intend to batch the two audiences. I am also working on a business-oriented paper, but that's taking a bit longer given that I'm still in the process of observing the way many companies make this Java vs. Other decision.
  • Tom & Kevin: You're right, I need to make my comparisons clearer. The point is to compare development platforms, not languages. I will refine this.
  • Todd: I wrote a paper in late 1999 about how Java is simply inappropriate for web development, mostly based on the strong typing issue you mention and the OO vs. RDBMS issue. So I agree with you. However, I'm looking ahead a bit to the world of XML web services, where the strong typing argument actually plays somewhat in the favor of a strongly-typed language (although you still have to match Java types and XML types). That's why I chose to omit this argument in this particular paper, although I completely embraced it back in 1999. What do you think?
  • Kevin: Please note that your message accuses me of dishonesty and naivete. Your approach is hardly a cooperative way to enter the conversation: you may want to consider how this type of message contributes to the wariness of OpenACS members towards ArsDigita opinions and comments. We'd appreciate somewhat less condescending statements. That said, I'm happy to entertain the possibility that I am completely naive and that I need to see the light. Please help me do so by * explaining* what I'm clearly missing. Tell me how ACS 4.5/5.0 resolves the conflict between OO abstraction and ER datasets. For example, if I have a table of students and a table of professors, where each student has a "Thesis Advisor" reference to a professor, how do you query the data of "students and their advisors" in an OO setting? Do you do it with one SQL query? I'm genuinely interested in this problem. In fact, Philip (gasp! I mentioned his name!) and I discussed this issue 3 years ago: we settled on the idea that only Java + a real OODBMS would provide a better architecture than scripting + RDBMS. Finally, one strong point: please don't question my honesty unless you have serious evidence to back up that kind of statement. Everything I said in that paper is an honest comparison that attempts to rationally explain my intuitive unhappiness with Java on the web. I may be wrong, I may be missing some key brain cells, but I'm not dishonest.
Posted by Roberto Mello on
Excellent paper Ben. Thank you very much. I look forward to the refinements you'll make and for the business-oriented version of this paper.
Posted by Kevin Scaldeferri on
Ben, I'm sorry if my comments were a bit overly-strongly worded.  (Just as an aside, though -- and I don't think this should become an aD vs. OpenACS bickering match -- I don't really think it was any harsher than comments that various members of the OpenACS community have made towards Arsdigitans.)

Since there does seem to be general agreement that this article should be a little clearer about comparing apples with apples and oranges with oranges, I'll leave that issue alone and just comment a little on the O-R mapping issue.

First, I'm certainly not going to claim that "Arsdigita solved the O-R mapping problem."  Our persistence system is still quite young and developing.  Also, it aims to deal with database independence as much as the O-R mapping.  However, already I think it avoids "sometimes increasing the number of database interactions by a factor of 10 or 20".  I honestly can't see how you would make things this bad except by issuing a database statement for every getter and setter call, and I will stand by my characterization of that as naive.  I suppose that if you attempted to do joins in the java layer you could multiply your number of database interactions, but everyone agrees that that is a bad idea, and, besides, our experience with ACS 4 clearly shows that it is very hard to get extensive joins to perform even if you don't have this issue to deal with.

Right now, queries like you describe are dealt with using "DataQueries", which are Java objects that represent a special purpose query.  I'll acknowledge that this isn't the most elegant solution, but it's equivalent to what we were going before in ACS TCL, but with database independence much easier to obtain, so I don't think anyone can really complain.  Work is being done towards the goal of metadata-driven dynamic query generation, but this is far from my area of expertise, so I'm not going to comment further on it.  If people are really interested in how we are dealing with this, I'd encourage you to start a thread on http://developer.arsdigita.com/acs-java/bboard/, since it's more on topic there and you will get the attention of more of the people working on the problem.

I just want to end this with my personal take on this issue.  I can argue for TCL/AOLserver as a good platform for web development.  I can also argue for Java.  The arguments are very different because "web development" is a big subject.  So, there are some types of projects that I would head to TCL for.  If you really are mostly doing string-munging or you want a reasonably simple collaborative app quickly, there are big advantages.  However there are also things that a "real" language is better for.  As Todd said:

_Strong static typing is a boon when a module has predefined functionality (no lambda), certain garantees on inputs, and a large amount of complex operations on internal data. The provided invariance enhances stability on such problem domains._

When I describe the type of systems I work on these days, I tend to de-emphasize the web aspects.  We're building applications that just happen to use the web as their primary interface.  However, they could just as well run as local desktop apps, and if you were writing them in that context, you wouldn't think of doing it in TCL.  You might choose C or C++ or Java or Smalltalk or Lisp, but almost certainly not TCL.  Programming complex applications without real data structures just seems like madness.

Posted by Ben Adida on
Kevin, thank you for taking the time to explain your point of view. I
much prefer this level of discussion.

You are making my point for me, though. The join situation is
precisely what I was referring to. You have two tables, and
abstractions built on top of each individual table. If you want to
pull out data from both tables simultaneously, you're forced to
either issue many SQL statements to perform the join outside of
the database, or you're forced to break your abstraction with your
"DataObject." Once you've pulled out the fields using the join
SQL query, you're forced to create the individual objects (in this
case student and table) within the DataObject class by inherently
breaking the nice abstraction you created for both. You're forced
to expose the internal class structure both to Student and

I've built a complete Java web application as the "Java/DB guy,"
and I was faced with this dilemma. There is no clean solution.
The OO abstraction model is inherently incompatible with the
join semantics of SQL.

So yes, Tcl has issues. It's not a language I want to build an
enormous desktop application in. That's why I rely on SQL data
types and PL/SQL where appropriate. The problem with your
analysis is that you're forgetting the thousands of VB
applications out there. Yeah, VB is a crappy language, but a lot of
the applications you use from day to day are built in VB. Why?
Because a quick and very-high-level scripting language is often
more powerful than a well thought-out Java application. It gives
computer scientists nightmares, but it works.

The other issue is that, when using a strongly typed, highly
structured language like Java, you're often forced to take
shortcuts like the DataObject approach. Suddenly, your
abstractions are broken. The reusability you expected is
seriously endangered.

So which is better? Using Java and being under the illusion that
you have structure, reusability, and generally good software
engineering practices? Or admitting that we have some serious
unsolved problems in this field we call software "engineering"
that cannot be addressed by "pure," "clean" solutions, and going
with a language where less reusability is a fact we admit from
the start, but where one can rapidly develop and deploy an

I don't have the answer to all of these issues. They're not simple.
But my intuition tells me that Java is not the solution because of
the points above and in my paper. Tcl is not *the* solution either,
but it is more effective in getting people up and running quickly
with an application that ends up not being so difficult to tune.

Posted by David Eison on
An ASJ article on the persistence system is being worked on.  This feels a little off topic because it doesn't really have anything to do with Java; one doesn't need a persistence system to use Java, and one doesn't need Java to have a persistence system, so I'll just leave it at that so we can go back to discussing OpenACS explaining its choice to stick w/ TCL.

Regarding the paper (Interesting paper with a lot of heart in it.  Specific nit-picks below):

0) Apples and oranges issue: I don't think this should become a paper about OpenACS/Java.  I'd like to see it more about TCL/Java.  See final comment.

1) The paper seems to write off "marketing" (i.e. customer desire to do projects in Java) as a worthless consideration in a platform, which I don't think is a safe conclusion.  I think everyone reading this forum agrees that projects are easier if everyone involved has a common technology base (e.g. everyone knows TCL), yet a company's desire to do their various projects in Java is brushed aside as false standardization.  This aspect of anti-Java positioning might be worth dropping as an indefensible position for any customer that is bigger than just their website.

2) The "equality of programming languages" section feels to me like it should have references to specific languages removed or relocated ("The AOLserver Tcl environment, for example, is particularly strong at linking in new libraries of functionality"; "There are 2 million Java developers worldwide...") because they interfere with the message when interspersed in the evaluation criteria.  Just a personal preference, though, no strong argument for this one.

3) Ease of hosting seems to be an important criteria that has been run up against in the past and may be worth considering when evaluating languages/platforms.

4) The AOLServer/TCL Platform and Extending AOLServer sections feel like half an argument; they qualify TCL, but they don't address/differentiate vs. Java.

5) "There is no single part of web site development that is made easier on the J2EE framework. " feels very unsupported.  Counterargument: I find testing/validation to be much easier on J2EE than Aolserver/TCL, mostly thanks to junit.  Such a thing could be done for TCL, but I haven't seen it; so this could also be chalked up as a win for availability of proven/useful packages of functionality.

6) The templating scheme feels more a function of OpenACS than of the language, and thus isn't worth arguing about.  The templating scheme in ACS/Java 4.5 is more powerful than the templating scheme in ACS 4.0, but it's not because of language choice.

7) I really don't understand what "complete, DB-backed session management" means w.r.t TCL vs. Java.  Looks similar to comment in #6.

8) After repeatedly asserting that Java is inappropraite for web development, the C#/VB.NET model is used as an example compared to ns_java w/ TCL and now Java is suddenly a good tool for creating "reusable, well-packaged functionality"?  Seems like a complete 180 or a last-ditch clause like "this is our case, but even if you don't agree, it doesn't matter because of this".  It might do better to set this off in  a "Still don't buy it?  Consider mixing the two..." section or dropping it altogether.

Most of the things mentioned as advantages of OpenACS, while being good things, have little to do with TCL or Java - they had to be built, and there's no reason that I know of why they can't be built in Java.  I would prefer to see the paper focus on how they were or weren't easier to build and/or run in TCL than in Java, or really push for the language-doesn't-matter argument (more focus on "where functionality already exists in Tcl, there is no need to clone this functionality in Java" would make for a stronger paper because it's only an assailable position if the assailant strongly believes in the common-language-across-enterprise argument or in the superiority of O-O for web development (which isn't an absurd position, but at least it's highly debatable)).

Posted by Todd Gillespie on
Kevin: this is going to come off as marginally insulting, so I want to warn you up front.

I live and work in the SF Bay Area, and the phrase on everyone's lips here is "We're building applications that just happen to use the web". So I hope you won't hold it against me if I take your last paragraph to be marketing rather than engineering.

Sensitivity warning mode off.

Kevin, you have what appears to be a fatal flaw in your reasoning, and it's right here:

"...as local desktop apps, and if you were writing them in that context, you wouldn't think of doing it in TCL. You might choose C or C++ or Java or Smalltalk or Lisp, but almost certainly not TCL. Programming complex applications without real data structures just seems like madness."
If you were writing a, eg, Win32 app, you'd write it in C or C++ because the GUI libraries are in C and C++. Your choices are limited to the native languages, the languages they have wrappers for, or the wrappers you can write on your own (while staying on timeline). Even then you don't have any good choices, since the wrappers and the mixed language semantics most often cripple speed (the old gtk-- maintainer wrote some excellent analyses on this issue) which is verboten since the GUI enviroment demands response time of a tenth of a second or less. So you're stuck with C/C++. 'Real data structures' are a distant secondary matter in language choice.

"there are also things that a "real" language is better for."
Arrrggh. The 'real' language sling has been used against every interpreted language since the Epoch. I don't think it has any foundation; the languages you term 'real' would be more correctly termed 'system' languages. Having to bash bits does not a more 'real' language make.

I fear you also misunderstood my point on strong typing. It may be more illustrative to use the recent functional language Haskell -- its typing system is much, much, stronger than Java's (and yet pleasing unto the eye of the theorist. Fun, too.). What is found at the conclusion of this spectrum? Proof of my point -- Haskell, standard, is almost totally crippled for I/O. Any interaction with the outside world is packed into a monad where the type system is different; often they are linked languages (the Haskell/C++ combo made a strong showing at this year's ICFP). The point here is a strong static language is excellent in its own little box, but poor for the job of overseeing many components and dealing & processing variable foreign data. It's called the component architecture -- I hear it's becoming quite popular.

Posted by Bob Donald on
The following paragraph needs to be reworded (2nd to last in your document):

"The OpenACS team notes with great interest that Microsoft's .NET platform includes the use of an object-oriented system (C#) combined with a scripting language (VB.NET). In fact, the interactions between VB.NET and C# are much like those of Tcl and Java in ns_java: the reusable, well-packaged functionality is built in the more structured, object-oriented language, while the specific process flow and basic interface manipulations are done in the more flexible scripting language. "

I have spent a significant amount of my prefessional career in the Microsoft development world using C, Visual C++, Visual Basic, ASP.

Visual Basic 6.0 is an object-based language (no inheritance). VB.NET is a object-oriented language just like C#. There are few differences (besides the syntax). VB.NET must be compiled just as C# needs to be compiled. In Microsoft.NET, all of the languages are compiled to IL (Intermediate Language or IL for short). This allows developers to write applications in many different languages and sharing objects between code written in different languages seemlessly. You can even inherit a class written in C# from a class written in VB.NET.

Neither Visual Basic 6.0 or VB.NET is a scripting language. Maybe you were referring to ASP.

Posted by Kevin Scaldeferri on

There is a reason I put "real" in quotes.  It's not to denegrate "scripting" languages.  I use the term because there's no good replacement.  I could say "typed, compiled language" but while more precise it isn't actually accurate.

I do get a little tired of the false marketing-engineering dichotomy.  I mean, don't we want marketing to reflect sound engineering practices? (Suppressing snicker at the use of that phrase to describe programming.)  Sure, a lot of times it doesn't, but occasionally it is accurate.  In this case, I've spent most of the last year building a workflow engine and a personalization engine.  These things don't actually care that your display is web-based.  Web-based UI is certainly a big challenge for sophisticated applications, but it shouldn't actually be a factor in the application design.

Posted by C. R. Oldham on


Thank you for the paper. It is an interesting coincidence--last week I began looking at Tomcat, Turbine, Cocoon, Xalan, and the other Java based options for building web applications. I've already arrived at some conclusions, but first let me do a little critical analysis of your paper.

I agree completely with what others have posted regarding comparison of apples and oranges. I think what you might need is a comparison of OpenACS with the various servlet toolkits already out there. For example, compare AOLserver+OpenACS with Tomcat+Turbine+Velocity (see jakarta.apache.org), or Enhydra+Barracuda (www.enhydra.org).

I especially appreciate your observation that layering data abstractions on top of the relational model breaks SQL semantics. That was my first question when I looked at Turbine--how do I get at the data in the RDBMS? Turbine provides the Peer object (to be fair, you don't have to use them) that does the O/R mapping but Peers are really simple and make doing joins hard.

Some things you haven't covered that might be useful:

  1. Debugging AOLserver+OpenACS can be very difficult, especially when the TCL code is complicated. My shop has wasted hours on debugging when a good, visual debugger that could let us step through the code and see where we were screwing up would have reduced that trial to just a couple of minutes. There are already excellent tools for debugging of java servlets. Is there anything out there for TCL that works with ACS/OpenACS/AOLserver?
  2. You don't spend any time discussing one of the main reasons people go to servlets--the model-view-controller paradigm. So much of the flow control in OpenACS is page-based, and complicated applications can get out of hand quickly. The MVC paradigm (theoretically) can help you overcome that.
  3. Which brings me to my next point--there are lots of tools out there for doing CASE and they are heavily weighted towards Java nowadays. You could argue that an AOLserver+OpenACS shop could use those tools anyway, and we just have to do some translation somewhere, but tool support in general seems to be to be a big issue.
  4. And in the same vein as tool support, there is library support. There seems to be a plethora of library support out there for java, but precious little for Tcl embedded in AOLserver.
  5. Others will say that for large applications, the world is moving away from "business rules in the database" to "business rules in the middleware (servlets)". It seems to me that if I can't represent my rules in the database, and some of mine won't work there for sure, I'd much rather have them in Java than TCL.
  6. Just a few observations, some probably outside the scope of your paper.

Posted by Dan Wickstrom on
I agree that comparing OpenACS with servlet toolkits would probably be a better comparison, but I think you've got to be kidding when you say that debugging aolserver+openacs can be very difficult - especially in the context of comparing it to servlets.

Try downloading acs-java-4 and give it a spin. You will see what I mean. It's deceptively similar to acs-tcl-4, but once your start debugging, you will realize that you're in a whole different world, and it's not a friendly place.

The first thing that you notice is that error messages such as complilation errors and stacktraces don't correspond to anything in your source files. I found several problems in the workflow package, so I decided that I would try debugging it. I knew that .ajp pages in acs-java are converted from .ajp to .generated.ajp files with the tcl-like macros expanded. Naturally, I assumed the error messages would correspond to the .generated.ajp files. This turned out not to be true. The .generated.ajp files are converted to servlets and then compiled before being executed. So when you want to see what line corresponds to an error, you have to track down the corresponding auto-generated servlet file that corresponds to the url that you accessed. Finding the auto-generated file itself is not easy either. All of the auto-generated files are placed in a working directory with extremely long auto-generated mangled names. Usually,they look something like the following:


Multiple versions of the same servlet are left lying around, so make sure you get the latest one.

When you list the working directory with all of the auto-generated servlet files, you end up with a big mess because all of the long file names that are wrapping around in your terminal window.

The net result is that something simple like this:

<%@ include file="/acs.jspi" %>

ad_page_contract {

  @author rhs@mit.edu
  @creation-date 2000-09-18
  @cvs-id index.ajp,v 1.8 2001/02/24 15:45:52 deison Exp
} -properties {

BigDecimal package_id = acs.pkg.getPackageId();

String package_name = [db_string name {
  select instance_name
  from apm_packages where package_id = :package_id

ContextBar context_bar = new ContextBar();

BigDecimal node_id = acs.request.getSiteNode().getNodeId();

String contextPath = request.getContextPath();
db_multirow site_nodes {
  select :contextPath || site_node.url(node_id) as url, acs_object.name(object_id) as name
  from site_nodes
  where parent_id = :node_id
  and object_id is not null


Turns into something like this:

package p_00025ckages.acs_0002dworkflow.www;

import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
import java.io.PrintWriter;
import java.io.IOException;
import java.io.FileInputStream;
import java.io.ObjectInputStream;
import java.util.Vector;
import org.apache.jasper.runtime.*;
import java.beans.*;
import org.apache.jasper.JasperException;
import com.arsdigita.util.*;
import com.arsdigita.acs.*;
import com.arsdigita.acs.html.*;
import com.arsdigita.db.*;
import java.util.*;
import  java.sql.*;
import java.math.BigDecimal;
import java.io.IOException;
import java.io.File;
import org.apache.oro.text.perl.*;
import org.apache.oro.text.regex.*;
import org.apache.turbine.util.mail.Email;

public class _0002fpackages_0002facs_0002dworkflow_0002fwww_0002findex_0002egenerated_0002ejspindex_0002egenerated_jsp_0 extends HttpJspBase {

    static {
    public _0002fpackages_0002facs_0002dworkflow_0002fwww_0002findex_0002egenerated_0002ejspindex_0002egenerated_jsp_0( ) {

    private static boolean _jspx_inited = false;

    public final void _jspx_init() throws JasperException {

    public void _jspService(HttpServletRequest request, HttpServletResponse  response)
        throws IOException, ServletException {

        JspFactory _jspxFactory = null;
        PageContext pageContext = null;
        HttpSession session = null;
        ServletContext application = null;
        ServletConfig config = null;
        JspWriter out = null;
        Object page = this;
        String  _value = null;
        try {

            if (_jspx_inited == false) {
                _jspx_inited = true;
            _jspxFactory = JspFactory.getDefaultFactory();
            pageContext = _jspxFactory.getPageContext(this, request, response,
			"/errors.jsp", true, 8192, true);

            application = pageContext.getServletContext();
            config = pageContext.getServletConfig();
            session = pageContext.getSession();
            out = pageContext.getOut();

            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(7,4);to=(9,0)]

            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(9,41);to=(10,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(10,40);to=(11,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(11,45);to=(12,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(12,39);to=(13,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(13,44);to=(14,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(14,41);to=(15,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(15,40);to=(16,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(16,33);to=(17,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(17,47);to=(18,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(18,48);to=(19,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(19,55);to=(20,0)]
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(20,35);to=(22,0)]

            // end
            // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/acs.jspi";from=(22,2);to=(24,0)]
                PageVariables acs = new PageVariables();
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/packages/acs-workflow/www/index.generated.jsp";from=(0,31);to=(2,0)]

            // end
            // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/packages/acs-workflow/www/index.generated.jsp";from=(2,2);to=(23,0)]
                    Displays the user's task list.
                    @author Lars Pind (lars@pinds.com)
                    @creation-date 13 July 2000
                    @cvs-id index.ajp,v 1.1 2000/12/01 22:34:51 luke Exp
                 */     HashMap validationBlockResults = new HashMap();     HashMap validationBlockErrors = new HashMap();     HashMap validationBlockDefaultErrors = new HashMap(); if (validationBlockErrors.size() > 0)     throw new PageContractException(validationBlockErrors.values()); 
                ContextBar context_bar = new ContextBar();
                CallStack __stack = (CallStack)request.getAttribute("com.arsdigita.acs.CallStack"); if (__stack == null) {  	 __stack = new CallStack(); 	 request.setAttribute("com.arsdigita.acs.CallStack", __stack); } __stack.put("context_bar", context_bar);
                if (request.getAttribute("javax.servlet.include.request_uri") == null) { 
                } else {
            // end
            // HTML // begin [file="/home/nsadmin/tomcat/webapps/acs-java-4/packages/acs-workflow/www/index.generated.jsp";from=(23,2);to=(24,0)]
            // end

        } catch (Exception ex) {
            if (out.getBufferSize() != 0)
        } finally {

You can debug this without any special tools, but it sure is a PIA. If you work on this stuff, it seems that you would have to have some type of visual debugging tool that can quickly resolve the disconnect between your source code and the auto-generated servlet code that is actually executed.

Also, since you must now depend on a visual debugging tool, let's hope you can find a good one. My experience with visual debugging tools is that it's usually faster to use println than to waste your time with those buggy inflexible development environments. That idea of quickly stepping through your code and isolating the problem is a nice one, but ususally you spend all of your time trying to get the visual debugger to work properly.

As far as visual debugger that work with aolserver/tcl, i've heard that tclpro will work, but I wouldn't waste my time with it, as aolserver/tcl is so easy to debug anyway.

And what is special about MVC with regards to servlets? That paradigm can be implemented in tcl as well.

Posted by C. R. Oldham on

Dan Wickstrom writes:

It's deceptively similar to acs-tcl-4, but once your start debugging, you will realize that you're in a whole different world, and it's not a friendly place.

Good point, Dan. Having never dabbled in ACS-Java I was unaware of this. Thank you for the detailed example.

And what is special about MVC with regards to servlets? That paradigm can be implemented in tcl as well.

Sure, it could, but there is no support for that in OpenACS right now and we're back to the underlying technology vs. toolkit issues--all the servlet-based toolkits I looked at were structured around MVC. To embellish Ben's article, I was just looking for reasons why someone would pick a servlet framework over OpenACS and that's one. It was very compelling to me because right now in OpenACS flow control is tied to page views. Or am I mistaken?

To me, MVC seems the logical way to structure a web application that might at some point need to deliver different views of data to different devices. Granted, XSLT support is now in AOLserver, so maybe that solves the problem a better way.

Posted by Bryan Che on
ACS Java 4 was primarily a Java translation of ACS Tcl 4. We designed it so that writing apps in ACS Java 4 would be as similar as possible to writing apps in ACS Tcl 4; rather than Tcl files, you write AJP's. And, you can pretty much re-use the same ADP's.

The architecture for ACS Java 4.5 and beyond is dramatically different from ACS Java 4. It doesn't generate servlets for you from AJP's or anything like that. You actually write the servlets and can use Java IDE's to step through your own code and debug (or just println if you wish). You can also automate testing with JUnit. This is a big win for developing the ACS. At aD, we have now implemented a release process that involves weekly formal builds, automated regression testing, and scalability testing and tuning. Doing these things greatly helps ensure that changes we make to one place in the ACS don't break functionality somewhere else.

Dan's comments are relevant to ACS Java 4, but they don't apply to ACS Java 4.5+. And, they certainly don't apply to Java-based solutions in general. I encourage you to take a look at http://developer.arsdigita.com/acs-java if you haven't already.

Posted by Marshall Trammell,III on
The Notes Overview at aD seems a little intimidating.
Posted by Bryan Che on
The notes app doc was primarily meant for people involved with developing and validating ACS functionality--not for people new to the ACS. I suggest you take a look at http://developer.arsdigita.com/acs-java/acs-core/doc/quickstart.html for the current draft of the ACS Quickstart guide. Note that this is still a draft and will continue to evolve.
Posted by Dan Wickstrom on
"Sure, it could, but there is no support for that in OpenACS right now"

Sure there is. All the elements of the MVC paradigm are contained within openacs. You have the templating system for the view, .tcl pages for the control, and the db for the model. I'll admit that the view is limited by the templating system, as there isn't any support for rendering content in anything other than html, but I would be willing to bet that 95% of the content rendered by servlet engines ends up as html. Also there is nothing inherently limiting in openacs that prevents us from adding xsl/xslt support in the future.

As far as page flows, I don't see where there is a problem for implementing control operations in openacs. Usually the page flows are a linear sequence of operations, and they are quite easy to follow.

I also don't see what you're trying to get at by comparing page flows to the MVC. paradigm. So what if your control logic is implemented by a java class, a tcl proc or a page flow operation in openacs. The servlet method is not inherently easier to understand or implement. In fact, I would submit that it is much more difficult to develop with servlets, because you have a much bigger api, and hence a much bigger learning curve for becoming productive in the servlet environment.

Bryan - when acs-java 4.5+ comes out, I'll take a look at it, but right now it doesn't exist as a released package. I've looked at acs-java, and I have to admit I can't get a clear package of how the new java version will work. It seems bigger, more complex, and I don't have clear idea of wether it will be easier or more difficult to develop in the new java environment. My impression from following the java dev bboards is that the new java acs will be extremely complex, and developers will have a long learning curve in order to become productive. I will be impressed, if it turns out to be easier to develop in acs-java compared to developing in acs-tcl.

Posted by Steve Crossan on
Great paper (& valuable), great comments, good discussion.

I swing both ways :-) so I'll put some arguments on each side:

* David's point 3 in his post above needs emphasising - ease of hosting. My experience of 3 tier Java/web application environments is that they are a huge SysAdmin nightmare - a whole new world of potential memory leaks, strange crashes, uptime measured in days or weeks. There's a story about Brezhnev talking to Ford (I think) saying 'you americans build fighter planes like fine swiss watch. watch fall down. watch break. we russians build fighter planes like micky mouse watch. watch fall down. watch break. pick up watch. shake watch. watch work again.' not the perfect analogy, but that's kinda how I felt starting using ACS 2 years ago after 3 years of Java/RMI/Weblogic/Netdynamics etc. etc.

* In some problem domains, your do want the power of OO abstraction as a way of managing complexity, from design through build to maintenance. CM systems for example, or anything where you're modelling financial entities, tend to benefit from this approach in my experience.

* The performance stuff is valid to an extent, but personally I'm sceptical about that talk. 1) I have a strong feeling no-one really knows about this - it's my experience vs. yours. 2) if i can save a few programmer months of development time and a few more of maintenance time on a project by using an environment more suited to the problem domain, i can afford to spend big on hardware & still come out ahead.

* I agree that it should maybe be split into 2 docs - AOLServer/Tcl vs Java/Tomcat & another one on OpenACS vs. ACS x vs Turbine/Velocity/Barracuda/Enhydra etc. etc. (which C.R. & I are beginning to do some work on so maybe we can exchange notes). But, one argument you use for OpenACS is the '30 modules tested on hundreds of sites' argument familiar from aD. Trouble is - ACS 4.x and beyond is a pretty complete break from the past - new data model, re-factored modules etc. etc. (correct me where I'm wrong here). Up to 3.4.x there's an inheritance and ok you've got a pretty dodgy toolkit in engineering terms in some ways but never mind the quality, feel the width! (and look at the reference sites). Arguably a bit unfair to still use this going forward. As aD found out ACS 4.x performed like a dog in many cases. And now they've thrown it out again and are starting again from scratch.

* it's a crappy argument, but speaking from the POV of a small engineering firm trying to win sales, having to 'explain' Tcl to people who don't want to hear it can be a barrier. one that we try to overcome, but it ain't easy. again though - perhaps that's for a different doc.

Once again, thanks for doing and sharing a great bit of work

Posted by Rob Wright on

I concur with the many other posts that specify that with the current objective of the paper, the best comparison is between AOLServer/TCL and J2EE/Java.

However, if the paper's objective is for the OpenACS community to respond to questions about a Java port/solution, then I think that question is best answered by a paper that argues that for OpenACS, there is no technical advantage in switching from AOLServer/TCL to J2EE/Java. I think that can be easily shown by first enumerating the advertised advantages of J2EE, and then responding with an equivalent AOLServer/TCL(/RDBMS?) feature. Throughout Ben's paper are reasons why not to switch, but these reasons are mixed with criticism of Java in web application development.

I would then follow the first paper with Ben's original statement that "Java and the J2EE platform are not ideal for web application development." This paper would specifically address limitations of Java in web development, and then, if appropriate, present the advantages of an AOLServer/TCL solution. Also, in this paper it is important to include a quantitative evalutation of the performance of Java to avoid discussion of statements such as "sometimes increasing the number of database interactions by a factor of 10 or 20."

And finally, a third paper could be written on the business advantages/disadvantages of J2EE/Java or AOLServer/TCL...if someone has the energy.

that's my two cents...

Posted by Rob Wright on
one other thing, it is worth noting that even in groups that think Java is suitable for web application development, the O-R mapping debate is a frequent topic of discussion. see the jBoss mailing list archives and search for "servlets vs. EJB"
31: Sysadmin Headaches (response to 1)
Posted by good bye on
David's point 3 in his post above needs emphasising - ease of hosting. My experience of 3 tier Java/web application environments is that they are a huge SysAdmin nightmare - a whole new world of potential memory leaks, strange crashes, uptime measured in days or weeks.

I've built and had to maintain systems using ATG Dynamo/ Apache/Oracle, ACS and OpenACS, Tomcat/Apache/Oracle, and old-school Informix/Netscape server (ugh)/Java. I've also acted as the "production sysadmin" for each of these systems. Steve's point about system administration headaches is something that hasn't really been stressed enough in comparing ACS to these other toolkits.

Winamp.com uses dynamo/apache/oracle. Winamp.com has about 20 million "hits" a month. Almost every hit is someone downloading the player, something that isn't logged in the database...just in the server logs. The database is actually used minimally, since the guys who initially wrote it tried to use dynamo's built in 'relationalviews' abstraction which made it impossible to use joins. The database is primarily only used by people searching for "skins and plugins" and uploading the same. The winamp.com forums, which have a lot of db-backed traffic...are actually running on a separate machine using PHP/ MySQL and VBulletin...software that costs $99 a copy and looks like it was written in 3 days by some highschool students. The forums machine is 1 machine running apache/php4/mysql. The Dynamo system, in comparison is 8 separate physical webservers, each with 1 gig of RAM. they point to a huge database server. Each webserver has between 3-7 apache+ dynamo instances running. For no apparent reason, the dynamos will start consuming more and more ram until they all die, due to lack of memory. The on-call OPS guy then will get paged (because this typically happens at 3 am on sunday) and then the next monday will berate the programming team. 20% of my job at winamp was writing perl scripts to more efficiently dump and restart dynamos when they started acting squirrely...and remember, those dynamos were not really even doing anything besides serving up pages.

Contrasting this to ACS, at aD I helped deploy actionnetwork.org. It was a pre-acs system, and was very badly written by the people before me, and badly improved upon by myself. However, even though there was a .CSV upload page that opened and closed multiple database handles about 17 times, the system didn't ever randomly die. It would HANG during a big csv upload...but would recover when the upload finished. Note that the problem here was myself and my predecessor's poor programming, not any inherent problem with AOLserver. Even with crappy applicationlevel programming, actionnetwork.org seemed to work with up to 200,000 users, hitting the database with every connection to the website, sending massive amounts of spam email...on a single e450 with a gig of ram, and a badly configured oracle. It actually worked relatively well for months on a old crummy ultra 10. It did far more with the database than winamp.com did, and when it seemed to break, all I had to do was "restart-aolserver."

some setup notes:

ACS is a pain to set up, especially the first time. OpenACS is the same way. However, when working with say, ATG Dynamo/ Apache/Oracle, you multiply the setup overhead by at least three times.

setting up OpenACS (or OracleACS) requires the following:

  • you have to make sure your database is set up correctly.

    with oracle, this can be awful, without the right wizard. with postgres..it is relatively easy.

  • you need to set up your aolserver right, and compile the oracle driver and put it in the right place
  • you need to edit your aolserver's config.tcl script, then the acs parameters/config.tcl script
  • you need to load datamodel and bootstrap
  • you might need to do some misc stuff, like set up your ld_library_path and edit /etc/inittab
  • for development, you just edit a .tcl page. if you edit a private .tcl page, you need to restart-aolserver to initialize it
  • with Dynamo/Apache/Oracle you need to:
    • get the proper JDK, and set it up
    • get the proper JDBC, and make sure it is set up
    • set up your database...same overhead as ACS
    • figure out how to recompile apache to support dynamo
    • recompile apache a few times using different options (since the documentation is incomplete and incorrect)
    • set up your classpaths correctly
    • make sure httpd.conf is set up right
    • make sure your apachectl is set up right
    • make sure your dynamo startup scripts are set up right
    • edit your jdbc .properties files
    • edit your master dynamo .properties files
    • edit a few more random.properties files
    • for each query you write, you need to edit a relationalviews file
    • for each relationalviews file, you need to create and edit another .properties file
    • you need to run "beanmaker" on the relationalviews file to create some relationalviews components
    • eventually give up and figure out how to turn off the relational views and just use straight up JDBC...since it is impossible to joins with relational views
    • for each class you write, you need to create and edit a .properties file
    • write a perl script that acts as a glorified "make" to compile all your classes together, since one isn't provided with Dynamo
    • to test if your class is working right, you have to compile your whole system, stop dynamo, then stop apache, then restart dynamo, then restart apache...then hope it works.
    • after all this, you get to start designing your "users table" ...
    • I could go on like this, but you get the point.

      to fuel the flame, I get really nervous and sad when I see supposedly bright engineers claiming their java web toolkit is something other than a way to scam bigcorps (and in the past, small startups) out of their cash. If you are going to write a "real application" (which seems to mean a compiled system component) you still do it in C and C++. Financial trading systems are not written in java (at least the ones that work, aren't). Desktop apps are not written in java. Network components are not written in java. Not to say that java doesn't have its place, it seems to work very nicely in the area it was actually designed for...embedded systems...like the NTT cell phones in Japan or in smart cards.

      Note that none of these complaints should affect you, the grungy independent developer. Just figure out the right way to turn each of these situations into cash. It is still relatively easy to make a mint as a enterprise java developer...so many banks and other corporations have hugely fucked java projects right now, that if you actually know what you are doing (and most java developers DON't)...you can charge huge hourly rates to fix easy problems.

      aD actually has the right idea with their java toolkit if they follow the fuck-the-client business model. If they can convince a few deep-pocketed clients to use the new java version, they will be raking in the maintenance and hosting fees. Too bad by the time they finish the "product" the microsoft marketing juggernaut will have convinced the CTOs of the world to use .NET. Sigh...

      However, most of us are not aD, and if your business is building reliable sites in a short amount of time, for smallish clients...(or even big clients) I cannot recommend using any of the java toolkits I've worked with, unless your business model is to fleece the client on maintenance fees until they are out of business.

      I believe this exact thread was written about 3 years ago in the web/db forum back when it was still on photo.net....because I remember typing in comments sadly similar to the ones I just typed about three years ago. It sucks to see how little anything has changed since then.

      Becoming reflective for a minute, although it was kind of fun wasting a 45 minutes of my day venting my frustrations with java, I don't think this thread is going to go anywhere. No one really cares which is better, if someone is going to use java, they are going to use java, and even if Ben's paper is well written and has some concrete examples, it ultimately won't sway anyone. The real way to make people use OpenACS more, is to improve the core functionality, write some killer modules (especially ones that are not found elsewhere), clean up the UI so it looks slick, and attack markets where speed of delivery, reduced maintenance headaches, and inexpensiveness are more important factors than buzzword compliancy.

Posted by David Kuczek on
I only wanted to say that I really liked Rolf's last words:

"The real way to make people use OpenACS more, is to improve the core functionality, write some killer modules (especially ones that are not found elsewhere), clean up the UI so it looks slick, and attack markets where speed of delivery, reduced maintenance headaches, and inexpensiveness are more important factors than buzzword compliancy."

Let's go for some killer modules on openacs :-)
Posted by Adam Farkas on
Rolf --

You'd better take cover; a black helecopter just swung past my house. The pilot was wearing a shirt that said "Accenture" on it, and he didn't look too pleased.

I think they are looking for you. Traitors who expose the "F-The-Client" business model are not tolerated. Better stay in Japan until the heat dies down. Or until the Java fad passes.

Posted by Louis Gabriel on

Thanks for sharing.  Loved your post!

Keep it up,


Posted by Jonathan Ellis on
Just one nit --

at my current company we sell newspaper publishing software written primarily in Java.  (478 kloc Java for our custom apps, 97 kloc of C++ for InDesign plugins, 85 kloc of SQL, plus some php and 4D code that's in a different source tree and I'm too lazy to look up.)  It works quite well and although as everyone knows it's not really "write once run anywhere," porting from Win2k to OSX took one developper about two weeks and basically involved writing some classes to handle Mac file funkiness (resource forks and data forks and how they integrate, I think).  A Linux version would be probably be even less work but there is no market there so we'll probably never know.  Already though, Java is a big win over our previous C++ code that was a HUGE job to maintain for MacOS and WinNT.

So based on our experience I would say Java certainly has its place as a cross-platform environment for desktop apps, and IMO it is MUCH more enjoyable to code in than C++.  Just don't make me write web code with it. :)

Posted by Ben Adida on
Rolf: great comments, and point well taken about the paper. I'm not
trying to sway people as much as I am trying to provide material to
help OpenACS companies that face the "so what about this Java thing"
question from the CTO. Usually, by the time that question comes up,
the client is mostly convinced about OpenACS, but then has this sudden
fear that they must comply with the Java propaganda. This attempts to
show why it's okay to not go with Java on a technical level. The next
paper will make the business case. But you're right that Java fans
won't be convinced.
Posted by Todd Gillespie on
Adam, are you getting enough sun (or Sun) there in Michigan?

Wow, you step away from the console and great discussion crops up. Great posts from Dan Wickstrom, Steve Crossan, and Rolf (who we only see rarely, but is worth the wait). The only question I see left open to me personally is from Ben:

Todd: I wrote a paper in late 1999 about how Java is simply inappropriate for web development, mostly based on the strong typing issue you mention and the OO vs. RDBMS issue. So I agree with you. However, I'm looking ahead a bit to the world of XML web services, where the strong typing argument actually plays somewhat in the favor of a strongly-typed language (although you still have to match Java types and XML types). That's why I chose to omit this argument in this particular paper, although I completely embraced it back in 1999. What do you think?
Looking ahead is always interesting; however, I make my salary in the present and the past (legacy systems). The 'promise' of type-matching is a bit troubling; as I have seen how ruinous type mismatch can be to multiplatform projects. That Java promises stable types reassures me, but it is still a language that has trouble dealing with foreign data. Nor does the XML interface alter, as you said,
The other issue is that, when using a strongly typed, highly structured language like Java, you're often forced to take shortcuts like the DataObject approach. Suddenly, your abstractions are broken. The reusability you expected is seriously endangered.
Why are we worrying about bit-widths of types when we have 1-Ghz processors? I still think using a systems language is inappropriate for these tasks these days.

Anyway, these are all predictive, semantic arguments amongst programmers, and of limited practicality; I can certainly see why you[Ben] do not emphasize this in your paper. As a former sysadmin, a more practical analysis would look very like Rolf's. After having left that racket, were I forced to maintain a fleet of middleware rather than a DB + webserver, my response might be characterized as 'kick and scream like a little kid.'

Posted by Kenny Chan on
Nice work Ben.

Being one of the unfortunate people who is forced to deal with layers and layers of un-nescessary abstractions on a Java based web app platform (Turbine) at work. I can tell you Java is no fun in web development.

In Java (well, to be fair, Turbine), everything is so convoluted and frustrating to me. One functionality in tcl almost everytime needs more than 3 folds of the effort in Java to accomplish (sometimes 10 folds). Java == OO = Robustness? Not so in web development.

Ben, consider some argument on enterprise level web development in your paper to make it sound, cuz it seems everyone thinks Java == Enterprise, while Tcl == Script kiddie's toy.

39: java sucks. (response to 1)
Posted by Henry Minsky on
http://www.jwz.org/doc/java.html This is a good laundry list of what sucks about Java. Many of these things can be worked around, of course, but it's good to remember the features we really like in a language and runtime sometime.
Posted by Ben Adida on
After a long delay (sorry!), I have finished v0.2 of the Java Technical Paper. I've tried to take into account as much of the feedback as possible. In particular, I've made sure that:

- Tcl the language and AOLserver/Tcl the platform are well explained.
- the paper focuses on platform and language comparisons, and thus makes no mention of OpenACS the toolkit.
- the paper clearly mentions that it only explores technical issues.

Please check it out at:


you can always find the original version at:


Posted by Michael Feldstein on
Ben, I found your comment at the end of the draft regarding the similarities between the OpenACS Tcl/Java relationship and Microsoft's VB/C# relationship to be particularly compelling from a marketing perspective. In fact, it's compelling enough that perhaps you ought to consider standing your whole line of argument on it's head. With this current draft, the one thing people will probably remember is that you don't like Java for the web. But that's not really the best message, IMHO. The best message is that, by using a hammer for nails and  a screwdriver for screws, the OpenACS approach has many of the nifty characteristics that MSFT is building into .NET while maintaining openness. Rather than spending most of your rhetorical energy defending the OpenACS team's decision not to convert to Java, perhaps the paper should start with the "two great tastes that taste great together" theme right off the bat.

Also, I wonder if it might be helpful for you to illustrate your points about Java's weaknesses relative to Tcl with some code examples. Now, personally, as a non-programmer, I always found this technique to be somewhat intimidating when reading Philip's work. However, I suspect it would be helpful for at least one of the audiences that really matter and, since your point usually is to show how messy Java can be, even non-programmers can see the difference between one or two lines of Tcl and six or eight lines of Java. As a compromise, you might consider adding hyperlinks that pop up new windows with the code examples. That way people who want to see them can while people who don't can ignore them.

Good work.

Posted by Ben Adida on

Yes, the .NET argument is good from a marketing standpoint. But this
paper is the technical argument, and certainly the technical argument
of "well, Microsoft is doing the same thing" doesn't usually win
converts. The business/marketing standpoint is *much* more intricate,
even with this argument, and I haven't attacked this yet.

On the other hand, code samples might be a good idea to make this more
technically precise. I'm not sure they're needed, but what do people

Posted by Vadim Nasardinov on


I agree with Michael. Code examples would help a great deal. Without them, the paper reads like a marketing piece - not the technical argument that you would want it to be. People who have done both Tcl/AOLServer and Java/JSP/Servlets (such as yourself) may flesh out some of your claims with specific code examples on their own. People who haven't had any experience with one or both of these platforms/development environments, will find a lot of declarative statements that may seem unsubstantiated to those who lack your broad background and technical savvy.

BTW, were you one of the early reviewers of the Java Language Specification? I see the name "Ben Adida" mentioned in the preface to the first edition of the JLS.

Posted by Ben Adida on
My goodness, someone has been doing their share of serious investigation! I did indeed have the honor of working on Guy Steele's team at Sun 5 years ago, for a summer. I was responsible for rewriting the Math library for Java (and making it IEEE standards-compliant) for v1.1, as well as researching garbage collection. Guy Steele was writing the JLS at the time, and the team discussed various aspects of the spec every now and then. So I had a slight role in the JLS process, specifically regarding java.lang.Math. Very slight. But yes, that's my name in the intro.
Posted by Andrew Piskorski on
Ben, this is fairly trivial, but why'd you format your whole paper as
one big HTML table?  That forces me to widen my browser window
unnaturally in order to read it.
Posted by Ben Adida on
because I'm bad HTML designer and a lot of the OpenACS web site is
formatted that way with our standard header and footer.... I'll take a
look at improving this soon. Sorry about that.
Posted by Michael Feldstein on
Regarding the issue of the comparison to .NET, I don't think I
expressed myself clearly. I didn't mean to suggest that you write
anything other than a paper on the technical merits. In fact, I
didn't mean to suggest that you change the substance of your
arguments in any significant way. Rather, I was trying to suggest
that the technical arguments--the meat of the paper--could be
framed in a slightly different way.

You're not really arguing that Java (the language) sucks here;
you're just arguing that it sucks at certain tasks that are critical to
the web. Unfortunately, while you do acknowledge the value of
Java when it is used appropriately (i.e., the way that OpenACS
uses it), that message is somewhat lost in this draft.

I'm simply suggesting that you could shift the emphasis from
"this is why we decided not to port to Java" to "this is why we
decided to keep Tcl and add Java in some very specific ways."
The substance of your arguments would not need to change one
bit; only the organization would shift.

I'm also not suggesting that you make the comparison to the
VB/C# thing be the central organizing principle of the paper. You
can leave that reference at the end, right where it is. But if you
focus on highlighting the benefits of judiciously using both Tcl
and Java within the AOLServer environment (rather than simply
taking a defensive stance against 100% Java), then when
readers get to the end of the paper and see the comparison to
.NET, it will have more impact because it will thoroughly reinforce
your main message. It is my (limited) understanding that Tcl was
conceived as a "glue" language in the first place, and that there
was some thought fairly far back (at Sun? Scriptics?) that Java
and Tcl might be a great combination. There's a heritage here
that you can draw on more. By doing so, your comparison should
have more of the impact you are going for, which is (I think),
"We're not the only ones who think that intelligently integrating a
scripting language with a more strongly typed language can offer
web developers the best of both worlds. Microsoft is promoting a
similar strategy as their own answer to pure Java."

Overall, what I'm trying to say is that the current draft comes
across as a defense of Tcl rather than a confident embrace of
both Tcl AND Java in an environment that leverages the
strengths of each. I think you can convey a much more positive
(and more marketable) message without compromising your
focus on the technical merits.

Now, perhaps I'm overestimating your enthusiasm for being able
to draw on Java libraries. If this feature is just a bone you can
throw to those who really love Java, then the approach I'm
suggesting doesn't make sense. But if you really believe that
there is substantial value in having access to Java (and C, or
whatever) in the ways that the OpenACS community has chosen
to do it, then I see no reason not highlight a genuinely balanced

Posted by Julie Bernstein on
I agree that code samples would be helpful. Even though (or
perhaps especially since) I'm still a fairly novice programmer, I
have always found actual working examples very helpful when
illustrating any technical point. I find examples also make the
narrative more enjoyable and interesting to read.
Posted by Malte Sussdorff on
Okay, I stuck my head out and asked a couple of colleagues of mine to comment on the paper (hit me on the head for distibuting the link if you like). They mentioned a few corrections where in order, not from an evangelist standpoint, but from a technical one (and I need to translate german -> english on the fly, please bear with me):

Imperative programming has proven not to be well suited for complex application development which allows reusability. One step into this direction is OO related programming, but it is still a long way to go (check out component based development or aspect oriented and generic programming). But a lot of small things are not as easy to programm in OO than in other languages (e.g. sorting algorythms and the like). But when it comes down to a complex application (e.g. using the sorting algorythm as a component for encryption or hashing), reusability make it worthwhile again. If OpenACS is all about displaying data on the web, retrieved via SQL from a database, OO is like hitting flies with a canon. If you want to have an extensible and reusable application with some more logik, OO is the way to go. If you want to access this application with Webapplications, Palmtops and normal programms, use an application server. Once that is done, you should choose the programming language. Take C++ or C# for speed, Java for portability and tons of cheap modules. So, use TCL, Java whatever you like for your development but anticipate further needs and their complexity in advance to stay flexible enough to switch the plattform.

EJB-Containers are compatible to each other as long as they follow the J2EE specification. Companies need to distinguish themselves though, therefore they add additional functionality. An intelligent developer does not use those features or writes a layer around them. The comparison between J2EE and TCL lacks the following strenghtes of J2EE: EJBs (Components), Nameservice (JNDI), messaging (JMS), transaction service (JTA/JTS), a mechanism for distribution and all the design patterns around J2EE. Furthermore the Java Connector API, which allows connections to SAP of Host Systems. How would you connect AOLserver to a database not knowing SQL (which is quite common in large companies). Java datatypes match SQL datatypes 1:1. Using java.lnag.String and Stringbuffer allows very good string manipulation. Using Visual Age you can easily debug JSPs and their compilation into HTML. Using a persistent layer over the database allows independency from the database and the structure of the tables (you don't need to change the Java source, if the table structure changes). Using Java the scalability increases in form of multiple layer architectures. Application Server allow vertical and horizontal clustering, therefore allowing a dynamic load sharing on a server farm. Furthermore some points concerning the split between application, presentation and database logic would be in place, including a grafic how this is done with OpenACS. From a marketing perspective it might not be that a good idea to bash on J2EE.

Posted by Malte Sussdorff on
Now to my own $.02:

I think, the ability to integrate Java with J2EE should be made more clearly visible as well as an understanding, when to use this. Using the Java Connector could save OpenACS companies quite some hassle for integration of host (mainframe ?) systems. A clear picture how we seperate application, database and presentation logic is in order too at this place.

It is good to know when to use what kind of technology and even better when OpenACS (and AOLserver for that matter) can actually bridge technologies. That's something I'd love to see more clearly in this article, lessening the "bashing" impression you get from first reading it.

Posted by good bye on
Marketing, shmarketing. I say, bash away on java as much as possible.
I dont know exactly what problems people are having pushing openacs
to clients, but I have found that getting the initial project spec, taking it home, and coming back with their project 60% completed in
two days is a lot stronger marketing tactic than saying "well yes, it will take 6 months to build you a bulletin board, but your system will have an object-relational persistance layer and full J2EE compliance."
Posted by Ben Adida on

I have a feeling your friends worked for a big eBusiness consultant. I
did, too, so I recognize big consulting language when I hear it. I've
also seen the way this stuff *actually* works, and it isn't pretty.

Let's try to clear up some of the marketing hype. What's an
application server? Something that connects back-end data sources,
provides a framework for business logic, and various APIs for session
management, interaction with external systems, an extensible
framework, etc... AOLserver is one darn good application server. Now,
what you're saying is that we should have a 3-tiered system, with
a web server, an application server, and a database server. Okay, we
have a 3-tiered system from a logical standpoint. Database for data.
Logic in Tcl procs and page flows. And templates/presentation in ADP.

You want me to first pick an application server, then pick a language?
That doesn't work. Every application server is inherently tied to one
(or more) programming language. That's because the neat APIs you need
to use have to be implemented in that language. If I pick WebLogic, I
am stuck with Java. If I pick Zend, I am stuck with PHP. If I pick
AOLserver, I am stuck with Tcl (at least as the primordial glue). The
only people who will possibly overcome this soon are Microsoft with
the Common Language Runtime.

Also, are you performing sorting operations in the application server?
I prefer to use the database's highly optimized indexes and an "order
by" request. Oh yes, sounds far too simple for the "big applications
that happen to use the web." But that's the thing, these applications
*are* simple. We're not writing an operating system here. We're
writing simple components of software that need not be nearly as
complicated as the n-tiered, overly macho EJB world. Sure, the
cocktail party discussion is much more entertaining if you have 18
clustered application server boxes and a reboot engineer, but it's not
necessarily the best technical approach.

As for the pitch on all the wonderful features of the EJB world, show
me one site that uses them nicely and that was developed within a
reasonable budget and timeframe. I've seen this architecture at work
with the leading EJB vendor at one of the biggest banks in the US. The
marketing is very pretty. In practice, though, it is the flakiest,
least reliable, most overly-complicated architecture I've ever seen.
It took almost a year to get things working smoothly at this one
client, and they were paying 6-7 digits for support/licensing to the
big vendors.

How would I connect AOLserver to a DB not knowing SQL? How about
abstraction? In fact, OpenACS 4 allows you to put the queries in a
separate location. Thus, you can have a SQL guru come in and write
queries that fit a certain contract that your Tcl code requests.
That's better than OO abstraction around entire entities, because of
the OO/relational dilemma I mentioned in the paper.

As for this supposed independence from the table structure, I
challenge you to prove this to me. The moment you layer OO on top of a
relational model, you're forced to either perform 20 SQL queries where
one join would suffice, or to create OO structures that inherently
break your neat abstractions by joining entities in single queries.

Finally, the Java platform does not magically enable the clustering
that you mention. You can implement that in AOLserver/Tcl if you want.
Have you built one of these clustered systems? If so, I'm very
impressed and would love to read more about your experience. The
potential complications are enormous, however (session failover...),
and I haven't seen them truly solved in any system yet.

Everything you've mentioned so far is mostly Sun marketing. I have yet
to see a real system that was able to make use both of this magic
clustering/scalability aspect and the supposed componentization of
Java. Just because Java has OO capabilities doesn't mean the code is
automatically reusable as nice components. In fact, to get around the
limitations of OO/relational issues, I claim that the resulting Java
code is almost *less* reusable.

The only place where OO/Java makes sense is for specific, less-DB
related issues. A crypto library, for example. That would be a good
reason to use a Java library (although implementing an ns_ module on
top of OpenSSL or BSAFE seems way better).

I had mentioned to Malte offline that I didn't want to get into a
philosophical debate about Java in general. Unfortunately, that's what
this has turned into :( This discussion could get much longer much
more quickly. However, I feel it is important to respond to these
points which are very theoretical and very reasonable-sounding, but
which are contradicted by every practical situation I've faced.

Posted by Ben Adida on
One additional note: why is it that whenever someone mentions a
negative aspect of another technology, people are worried about how
this suddenly constitutes "bashing." Is it not okay to emphatically
point out negative aspects of various technologies? Have we all become
so politically correct that no technology can be bad, it is only "not
adequate for the task at hand?"

Sometimes, an idea is just plain bad. I don't think anyone should be
afraid of saying so. Now, if you want more supporting evidence, that's
a different story. I'll happily add more. But don't be afraid of the
bashing. The worst thing is not to express a clear opinion, IMO.

Posted by Andrew Piskorski on
Imperative programming has proven not to be well suited for complex application development which allows reusability. One step into this direction is OO related programming ...
Sometimes, it's what's not said...

Malte's colleague's comment caught my eye, because just a week or two ago I read Patterns of Software : Tales from the Software Community by Richard P. Gabriel - you know, the guy who founded Lucid and wrote the Worse is Better paper.

Patterns of Software is really a somewhat random collection of Gabriel's articles, and certain parts of it do seem to verge on rambling philosophical mumbo-jumbo. But in other parts Gabriel makes some fairly strong arguments to the effect that the "reuse" argument for OO progamming is greatly overblown, and that abstraction in general as a software technique is greatly over-used, over-emphasized, and just plain abused.

When somebody says "reuse" in the context of OO programming, I guess they usually mean stuff like subclassing and other such OO techniques. Gabriel suggests that "the form of reuse in object-oriented languages hardly satisifes the broad goals of software development", and that "reuse" is a bad term for the reuse-like properties of object-oriented languages. He suggests that a better word and concept for this than "reuse" is "compression" - the characteristic of a piece of code that the meaning of any part of it is "larger" than that piece of code has by itself, which is accomplished by drawing meaning from its surrounding context.

So yeah, while OO programming may be a "step" in the direction of "reuse", it's not necessarily a productive step!

Hoo, well, that's more abstract language crapola than I usually like to get into - time for me to go and write some nice concrete Tcl and SQL code.

I grok Ben's "show me a site where it actually works" style argument much more fully. Also, that sort of argument tends to stay much closer to what I learned in school to be engineering, as opposed to the pointless coffee-shop style philosophical rambling that some programming language, style, and productivity arguments sound like to me.

I don't think there's been too much good science done on how programming languages and other tools impact productivity and maintainability, nor on how mixing several different tools together affects productivity and maintainability. This tends to be a problem for things like Ben's "Why not Java" article. So Ben, it might be useful to point that out, and then cite specific examples of your practical, hands on experience with overly complex and overly brittle systems, as empirical replacements for the lacking hard scientific data.

While it may not be exactly what Ben had in mind for his Java article, I find commentary like his "I have a feeling your friends worked for a big eBusiness consultant ... I've also seen the way this stuff *actually* works, and it isn't pretty ..." or Philip's bashing of Netscape Application Server in his Scalability, Three-Tiered Architectures, and Application Servers article pretty entertaining. "X sucks, here's why, here's what we can can learn from that." - I'm kinda fond of that format. :)

Posted by Michael Feldstein on

One additional note: why is it that whenever someone mentions a negative aspect of another technology, people are worried about how this suddenly constitutes "bashing." Is it not okay to emphatically point out negative aspects of various technologies? Have we all become so politically correct that no technology can be bad, it is only "not adequate for the task at hand?"

I have no problem with "emphatically pointing out the negative aspects of various technologies." There are two issues here. First, the OpenACS team has not, in fact, rejected Java completely out-of-hand. Ben, given your pride in technical superiority uber alles, I'm assuming that you see good reasons to allow its inclusion in the way it has been included. You even mention some of them in your paper. But overall, you come across as saying:

"Java sucks! (But I guess we'll let you use it for a few things if you really insist on it.)"

That may, in fact, be the message you intended, in which case I would reply, "Rock on!" But is it? If so, it doesn't really do the job of convincing people that the OpenACS approach is the best technical solution. At most, it convinces them that Java sucks more.

Second, even if you really and truly intend your main message to be that Java sucks for web programming, given the fact that language debates tend to degenerate into religious wars very quickly, it's pretty easy for readers to cynically dismiss an attack on a language as another religious diatribe, even if there are some good arguments in it. You'll establish more credibility for yourself if you can show your audience that you are rejecting Java for the task at hand with a full understanding of its strengths. I do think it's worth the effort to go out of your way to establish that you are not a language bigot. You can call that political correctness if you want, but I prefer to think of it as being sensitive to your readers, who have probably read anti-language diatribes ad nauseam.

This really isn't about compromising your principles or diluting the purity of your technical position. It's about articulating your case so that the audience hears what you intend them to hear and is convinced by what you have to say. That has as much to do with good persuasive argumentation as it does with the arguments themselves. You can pay attention to presentation and persuasiveness without selling out your principles or compromising the logic of your case.

Posted by Michael Feldstein on

In terms of the tone I am trying to suggest, you can see something very much like what I'm thinking in Don's March 16th posts (particularly the first one) on this thread:

http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5 fid=000bcs&topic%5fid=web%2fdb&topic=

Two caveats. First, I'm not qualified to judge how close Don's actual argument is to Ben's. Fortunately, I'm not talking about the specific positions. I'm talking about tone and rhetorical approach.

Second, it's not yet clear how similar the question that Don was trying to answer is to the one that Ben is taking on. Don was answering the question, "In an ideal world, what language would you build the ACS in today?" I'm not entirely sure what question Ben is trying to answer. It might be something like, "In the real world, why has the OpenACS team chosen the language/environment strategy it has?" In that case, I like Don's tone very much as a model. You could sharpen up the advocacy and still maintain an even-handed approach. On the other hand, the question Ben is trying to answer might also be something more focused, like "Why hasn't the OpenACS team followed ArsDigita into embracing Java?" An article answering the latter question would appropriately be more like the "Why not mySQL" article that Ben wrote earlier, which is, in fact, roughly similar in tone to the current draft. So I guess it all comes down to what the goal is for the paper.

Personally, I find the first question more interesting and compelling than the second one, and I think it would appeal to a broader audience than the relatively small community of people who think of their choices in terms of ACS Java vs. OpenACS.

But if Ben's goal is to write a direct response to ACS Java then it wouldn't be entirely fair of me to criticize him for the paper he didn't write. I'm just offering suggestions that hopefully will help ensure that this paper does what it sets out to do (whatever that is).

If the goal is simply to do nothing more than respond to pressure for a full Java port, then I withdraw my earlier suggestion. Instead, I suggest that the title of the paper be changed to "Why not Java?" I would also suggest that the sentence, "This paper describes the technical reasoning behind the OpenACS decision to stick with the AOLserver/Tcl environment while making limited and well-targeted use of Java. be changed to something more like, "This paper describes the technical reasoning behind the OpenACS decision to choose the AOLServer/Tcl environment over the Java platform, while still making limited and well-targeted use of existing Java resources."

Posted by Talli Somekh on
(Quick not: Michael, your link to Don's post is broken, I believe. I think it's incomplete.)

Michael, I think you and Andrew have brought up good points. I also think that what this discussion is leading to is really two different papers:

a) Why a Tcl based (Open)ACS can be preferred to a Java based ACS and
b) why OpenACS has not embraced Object Oriented Programming

These two parallel each other very closely, but I think they must be separated. The reason is that most of the time the counter argument a person makes to Why not Java is, "Well, Tcl isn't OOP." Once you begin making the argument why OOP might not be best, they say "Well, Java has more developers/APIs/libraries."

The problem is that I don't think a good argument for both can be made in a single paper because they are two different thesis statements that must be addressed. Also, there are non-Java OO systems (Python based Zope) and the issue of whether Tcl's lack of OO features is a disadvantage or not.

I know that many non-programmers, and even hardcore programmers, believe that OOP is a god send. I understand this, because I think that OO is a very intuitive way to think about programming. Why can't I take a piece here, another one here, and another here and have a whole program? Then I'll use these same pieces plus a few others and make another app?

The issue, of course, is that this is not always true. OOP is for really hard problems, perhaps like an OS kernel. But, web systems are *not* OS kernels. (John Sequiera's quote: "Web systems *are* simple.") This is the point that needs to be made *separate*, but very *complementary*, to the Java argument. In other words, the OO argument can be abstracted from the Java argument. :)

So I think two separate papers that make persuasive arguments for both approaches would compliment one another very well. I don't want to suggest that Ben write both of them, because he's burdened enough. I would be happy to take a stab at writing this paper, but I don't have enough technical expertise. If someone volunteers to help me, I would be glad to work on it. There are a coupla guys around that I know who would be good help.


Posted by Talli Somekh on
OK, Michael, I saw Don's post. Interestingly enough, he's making the precise argument that I was asking for...
Don, can I just use your post to write the paper? :)
Posted by Michael Feldstein on
The problem with the link above is that the bboard is inserting a
space in the middle of the URL where the text wraps. If you paste
the URL and remove the space, the link should work.