There's no way to respond to quite all of the fascinating questions you are raising in one message, but I'm packing up tonight to head for Beijing to speak at the inagural Java China Conference (http://www.javachina.cn), so I've got a few minutes to wax philosophical. This is also probably worth a couple of blog entries, too, but those will have to wait until I have time to sit down and compose them.
A (very few) scatttered comments inline ... not commenting on something doesn't mean I do not find it interesting, just that I have a limited amount of time to respond tonight. On 9/9/05, Murray Collingwood <[EMAIL PROTECTED]> wrote: > > I'm just a humble Struts user (and relatively new), and I don't claim to > speak for the > group as a whole. > > I have read through Donald Brown's presentation (Struts 1.3 and beyond) > and I get the > feeling that the goal posts just don't stop moving. I'm afraid that this is the nature of the software developer landscape. You've heard the term "Internet time"? That is the environment in which we (as application architects) need to decide which technoogies to become dependent upon. The gamble, of course, is that the lifetime of the technology will correspond with the lifetime of the application you build on top of it. Sometimes you win, sometimes you lose. Ironically, Struts 1.x triggers people to respond at both extremes, as well as everywhere in the middle: * It evolves very slowly, engendering confidence that I can count on support over a multiple year lifetime for my application. * It evolves very slowly, and since it was originally designed five years ago, it is hopelessly out of date relative to current best practices, and should be tossed on the trash heap. Both answers are quite reasonable and understandable ... depending on your perspective. The time I have spent learning and creating a Struts application should be > an > investment in my future development, not a stepping stone to a whole new > set of > technologies that will continue to slow my productivity (through on-going > training). I think this goal is reasonable in the short term, but naive in the long term. You have to *count* on the technologies you understand today becoming obsolete -- and the pace of that obsolescence is higher in software than in any other profession I've ever looked at (although they *all* suffer from this). A couple of thought points on this topic to consider: * My son (now in his early 20s) is also a geek -- he really likes PHP, but I love him anyway :-). In between contract jobs, he's working towards a college degree ... but he's taking my advice to do something other than Computer Science. Why? Because even if he were following the traditional route of doing college in four years, anything *technical* he learned would be totally obsolete by the time he graduated. It's important to learn the fundamental principles of good software development, but you've got to understand that the point technologies you use at any given time are ephemeral. * I took my own advice when *I* was in college :-), and have a Business Administration degree, with an emphasis in Accounting. You'd think (from the outside) that there couldn't possibly be a profession that changes slower than accounting, but I can guarantee you that this is not the case. Once you get past double entry bookkeeping, everything I learned in college (even if I remembered it all, 30 years later) would be totally obsolete. * The same sort of thing happens in scientific fields all over the map. For example, I aced a test on Astronomy by (among other things) nothing that Jupiter had 12 moons, Saturn had 9, and so on. Those facts were considered true at the time ... but not any more. * Would you trust a doctor today to diagnose you with a 1950s medical education? Or even a 1990s medical education? Like basically all professions, medicine (and software) assume that a lifetime of learning new things is a fundamental requirement for success. I spent more time on this particular paragraph than the others below, to give you a feel for why I answer some of those questions the way I do. Who, and this is my question, who makes the decision whether a technology is > going to > be good for the greater community? Who asks the questions "Do we need > it?", "Will > the technology provide significantly greater returns than training > costs?", "Will the > technology last long enough to deliver those returns?" Software development is like everything else ... it doesn't come with a crystal ball. At best, someone tries to create an answer to perceived needs, and then the market responds by indicating whether (a) the need was actual, and (b) the provided solution actually met that need. Open source software has very different economics on doing this sort of stuff than you see in traditional product development at corporations that build and sell "stuff", but it's the same basic issues under the covers. Nobody knows *for sure* what the future holds, and what people will want then. And different open source projects do things differently -- at Apache, though, the direct day-to-day decisions of what happens next are up to the committers on that project. There's good writeups of roles and responsibilities that are worth looking at ... a good starting point for exploration is: http://jakarta.apache.org/site/getinvolved.html At Struts, in other words, the actual decisions about what code gets committed to the workspace is made by the committers (of which there are currently 15 or so). In turn, those committers get driven by what interests them, and what input they get from the community. Successul open source projects tend to listen to the latter more than unsuccessful ones, but it is very difficult to generalize on detailed practices. Who is it that has decided we need to keep extending the Struts framework > without > considering the developers' need for better problem identification and > documentation of > the existing Struts system. This list gets so many emails of people > struggling with > existing technology: Dynaforms, Validation, Iteration, Cookies, Flow > control, and the > number of different versions of everything "out there" that we need to > know about in > order to work with this system. Personally, I'm in agreement with you ... the Struts 1.x architecture needs to be fundamentally replaced. That's why I spend my own personal open source development time on Shale, where I am not stuck with concerns about backwards compatibility. An incredible number of lessons have been learned in the five years that Struts has existed. But those lessons cannot be fully harvested without creating something completely different. That being said, there are *millions* of applications based on Struts 1.x in the word today. It would be totally irresponsible for the Struts development community to abandon the developers who created those applications. Therefore, it is entirey appropriate that an evolutionary path occur -- in parallel to one or more "revolutionary" paths, since we don't have crystal balls handy :-). Who answers the question, "Why aren't we getting better error checking / > debugging > facilities for Struts?" On this kind of "evolutionary" question, the answer is simple: "because nobody has gone out and built a revised mousetrap that has better features." Struts is not the creature of a corporate entity ... it is a labor of love by volunteers. And there are no boundaries on who those volunteers might be -- it could be you! What have *you* done to solve this problem? Reminds me of how I got involved in open source software in the first place. I was working on a startup, and we (of course) had no money, and needed a cheap application server solution. Apache JServ (predecessor to Tomcat) fit the bill ... but they sat at version 0.9 for months and months ... until my son told me "Dad, you know Java, it's open source, go help them fix it!" So I did. It would be amiss of me to say Struts alone is responsible here, we should > include > Tomcat, MySQL, Connector/J, JSP, Java. And I'm not saying everybody is > doing a > terrible job, just asking whether we need to refocus our development > efforts. > > I'm not a fan of Microsoft but at least they have somebody that makes > those decisions > and they appear to be developing their technology for productivity. They > have > documentation. They have tutorials. They have backward compatibility. And, > have > you noticed how many websites are using .NET technology! The number seems > to > growing much faster than J2EE or JEE. I'll have to both agree and disagree with you with regards to Microsoft. Yes, they have an overall story that is pretty effective, and enough developers to build cradle-to-grave technologies to make it come true. That is quite different from the Java ecosystem, where it's a bunch of cooperative efforts, instead of a single monolithic organization, that makes it all happen. But "backwards compatibility"? Give me a break. Ask any VB developer what it will take them to learn VB.Net. Or how easy it is to convert an ASP page to ASP.Net. It's learning a new technology and applying it. Note that this is, again, the nature of the beast. You can't champion both "backwards compatibilty" and "rapid radical innovation" -- the two goals are in a substantal degree of conflict. When I was looking for an ISP to host my Struts application I found many > more > companies providing Microsoft servers with .NET than Unix/Linux servers > with the > necessary version of Tomcat or JBoss. > > If I were to write a web product to be sold and run inhouse, I would > probably develop it > using Microsoft technology, it's just so much easier to say, "requires IIS > 6+ and > SQLserver 2005+" and know that it will work. If you had to ship your > product how many > technologies with specific versions would you have to list? I'll let others comment on the "know it will work" comment :-). My personal experience with building JSF components and getting them to work in IE, for browsers that theoretically implement the W3C standards for HTML, makes me chuckle reading this paragraph. Is Struts in danger of becoming just an academic exercise? If Struts is > going to be > productive then we need to see: > * more documentation (and I'm not talking about the API, I'm sick of > trying to read the > API and guess the usage of the taglib functions) plus tutorials, online > training etc, > * more tools for building our applications (I know there are some but I'm > on NetBeans > and it appears to be lagging behind, Eclipse and Exadel I found to be too > inflexible), > * more error checking of the configuration files and better error messages > indicating > what the real problem is, maybe even warnings before the program runs, > * more debugging utilities (spying on the http conversations and being > able to > examine the contents of our beans), > * more backward compatibility so that I don't have to spend hours > upgrading my app > when my server updates or I move to a new server, > * more stability in the platform we choose (with reference to the recent > Tomcat bugs > that were brought to the attention of this list). Have you looked around yet? In the Java web application framework space, Struts is ***by far*** the leader, even today, in terms of robust support and documentation (not just from the project itself, but from tools and third party sources like books and knowledgeable consultants). JSF is getting there. Nothing else is even close. That being said, it's still an open source project. If *you* believe that the sufficient resources are insufficient, where's *your* contribution to make it better? If I were asked to vote it would probably be a conservative vote to > consolidate our > current technologies with better tools and a better product. > > Okay, there, I said it. It's out of my system and open for discussion. > Kind regards > mc I hope you'll find my comments useful in furthering this kind of discussion. But I'm starting from a different place than you ... I personally think it is a waste of time to improve the tools and documentation support for a five year old architecture that is definitely showing its age. It's time to leverage all the things we've learned in the past few years ... and provide *transition* strategies for existing framework users (while also providing incremental improvements and bugfixes to those who cannot transition as quickly as we geeks might like). But, assuming that you can learn a technology once and let it be the foundation for an entire career is hopelessly idealistic. Craig
