Eitan Suez's Blog

Community Archives

That Open Source Feelin'

I wanted to wait for the dust to settle a bit before airing my comments on the now dated news that Sun Microsystems has open-sourced Java.

I recall clearly a period of activity on java.net where many (including me) voiced their desire to see Java open-sourced.

Now that this has happened I'm amazed at the correlation of this event with my own experiences. In my career I've open-sourced two projects: ashkelon and JMatter.

Each time the process of letting go and embracing open source was very difficult, even arduous. I took what felt like forever to arrive at the decision. Surprisingly after the decision was made, the feeling was very positive, very rewarding: that I'd shared my work with the community. The same thoughts reverberate: "why did it take me so long to do this?" I believe the reward is of equal or greater magnitude to the effort; that is, it's worth doing.

With my first project, I hadn't yet read Eric Raymond's Cathedral and the Bazaar. I was a novice when it came to managing an open source project. I still regret that I wasn't able to make the project flourish, though I don't regret for a moment open-sourcing the project. Many used my code and some sent me improvements. There was also at the time an obstacle to this project: the fact that one could not legally publish online javadocs for Java's APIs.

Another correlating fact was my choice of license. Both my projects are available under the GPL. So it's a great feeling of validation to see that Sun has also chosen this license.

One odd way to describe how I feel about Sun open-sourcing Java is that the positive feeling is of equal magnitude to the negative feeling I had when hearing the news of the Novell ship sinking. It gives me hope for the future.

In my mind the parallels that exist between the events that play out in real life: the battle being waged between the forces of open and close code, and between the Star Wars saga are striking. I don't mean to sound cheesy here, but we see time and again how sometimes organizations exert their force by proxy, sometimes anonymously (as in the case of SCO).

One item I've been ranting about to friends (and on this site) for too long is how companies can get away for charging people for software they don't use. Each time I purchase a notebook computer and quickly wipe the disk clean to install Ubuntu, I pay the famous "microsoft tax" for a license of windows I did not ask for.

I would like publicly thank Sun Microsystems for choosing to side with its community, to side with the open-source community on Java. I sincerely hope that a few years from now Sun will be able to say: "we made a good decision; and it has paid off handsomely."

A better way to build business software applications

Each time I look at the task of constructing a business software application, I see tremendous repetition. Each application has many facets, most of them are generic. Yet each time we appear to rebuild each facet from scratch. For example, we construct new authentication screens. We build an object model for our domain. We must construct mechanisms for browsing and searching objects, mechanisms for creating new objects, for viewing objects, for editing and deleting objects: the CRUD (Create, Read, Update, Delete) operations. Let's also not forget validation.

Oftentimes, we deal with scheduling activities and must develop or integrate calendars into our software applications. Inevitably, our customers will require a mechanism to produce reports. We will also supplement our user interfaces with wizards, by walking a user through a series of steps. We need to persist our objects to databases, we need an authorization mechanism. We need audit mechanisms to find out when information was edited, by who.

Many of these tasks are generic, orthogonal to the problem domain. Must we keep on constructing new implementations each time we start on a new project? Is it even feasible to produce implementations of these concerns (e.g. authentication, authorization, CRUD, a user interface, searching, reporting, wizards, etc..) that are completely decoupled from the business domain in question? Can we even entertain the thought?

To me, the NakedObjects framework is a proof of concept. It demonstrates that it is indeed feasible to implement many of the various concerns of application development generically. Usually the tradeoff is adherence to certain framework conventions, though others have shown that many of these conventions are not absolutely necessary.

Look at the scaffolding generators in Ruby on Rails. Trails is another project that embodies these same ideas. The idea is basically that a domain model can be constructed that is to a large extent ignorant of the context it runs in. This sounds like the Spring Framework and Dependency Injection. But it goes well beyond injecting transactional rules or turning JNDI on its head. Indeed, a long time NakedObjects proponent, Dan Haywood, is working on his own framework (see Essential), and is leveraging the Spring Framework for it. The Naked Objects folks have recently coined the term "The Naked Objects Architectural Pattern" to categorize frameworks that adhere to their architecture concepts and ideas.

In Ruby, one uses the piece of metadata :attr_reader to tag fields that one wants to expose with getter methods. In NakedObjects, there's a fieldOrder piece of metadata to relate how fields should be laid out on a form in a user interface. It is specified in a manner analogous to Ruby's :attr_reader. This manner of specifying metadata is also in line with the DRY (Don't Repeat Yourself) principles given to us by the pragmatic programmers. It expresses our intent succintly and without duplication.

Let's set aside the "can it be done" question for a moment and envision the rewards. What do we have to gain as an industry if we manage to develop a system that provides generic implementations for these generic aspects of business application development?

Imagine an ecosystem, similar to Eclipse, but not for tooling. Instead, this ecosystem would be a runtime infrastructure ecosystem, where providers supply competing implementations of these various concerns (this is what Rails is evolving towards by the way).

• developers would spend the vast majority of their time directly addressing customers' problems
• conversely, very little time would be spent building software infrastructure
• software infrastructure would become standardized
• development time and cost would decrease dramatically
• infrastructure components would be of higher quality
• the size of the code that pertains directly to a specific project would shrink dramatically
• our abilitly to read, understand, and extend other people's code would likewise improve
• we would have true decoupling of concerns
• the developer would simply plug in their object model (the data and behaviours) into a an infrastructure that would supply everything else
• we'd be able to pick which aspects we want to include in our application at deployment time (the true, original vision of J2EE by the way)
• our applications would inherit new features when infrastructure upgrades came along, without even altering a single line of code in our applications

I'm not even mentioning the benefits to developer-customer relations, the closer mapping between a user interface and its object model with direct benefits to customers' understanding of the logic behind a business application (hence the term "Naked Object").

Aside

Many people have been saying "Move over Java, Ruby is the new language in town." I do agree to some of the arguments but not all of them. How much of this is a language issue? I do admit that maybe implementing such a system is easier and simpler in Ruby. But that does not mean that it cannot be done in Java. Java has reflection. Java does not have mixins. Java has AOP. So there are tradeoffs. I suppose if you really want to do it from scratch, Ruby might be a better choice, from a certain point of view. If you're building a rich client that needs to run cross-platform with a minimum of fuss, I'd say that Java is the better choice. Smalltalk could be just as good a choice, perhaps a better one. Paul Graham says it's LISP and I know he's got some very good reasons.

My contention is that the debate has been focusing disproportionately on the language as the root enabler of frameworks such as Rails. The ecosystem I dream of can be constructed in Java. We would reap serious savings in development time, development cost, similar to the time and cost savings that are being boasted about by the Rails community.

I have developed my own framework that embodies these ideas. At this time, this framework addresses only workgroup business applications. It does not tackle the important issue of transport. I have recently employed this framework to construct a small solution for a customer. The numbers are in line with my expectations. On this particular job, I spent under two weeks implementing the solution when the original estimate had been in the order of two months. So how much does this have to do with language?

[Footnote: blog entry cross-posted on Eitan's personal weblog]

community docs update..

in a java.net article i wrote on ashkelon a few months ago, i'd mentioned the idea of resurrecting a community docs web site based on ashkelon. the original site was at dbdoc.org, whose name always felt a little inadequate. so i checked on openjavadocs.org and lo and behold, it was available.

so i've been thinking about doing this very thing: bringing the site back, under a new (more appropriate) domain name.

then i realized that i originally wrote ashkelon primarily to serve my personal javadoc api referencing needs. i mean, i didn't design it to support large numbers of users, or for the population and update of apis to be so frequent to become a significant overhead. i personally use it to document the dozen or so apis that i happen to be using over a given period of time. when i come across another api that i want to leverage, i'll put it in my local copy of ashkelon.

the process used to go like this: download the source code, update the sourcepath, create an api xml file for it, invoke the ashkelon 'add' command to populate the db, and restart the web app. the whole process could take me 5-10 minutes at the most. for 100 apis, that's a couple of days! (ouch).

so i spent a little time to try to improve the situation. i haven't yet cut a new version of ashkelon but i've committed a fairly significant number of changes and improvements. here are a some of them:

1. sourcepath is no longer required, even discouraged. instead, ashkelon is now aware of source code repositories (svn or cvs). in the api xml file, i now specify where the repository lives. when i do an 'add' now, ashkelon will simply fetch the code for me.

2. i've had this small "apixml" script that would generate the skeleton xml for me from a javadoc package-list. that's a nice little time saver. i also keep these xml files around in ashkelon's source code repository so that others could use them.

3. i've slightly improved the post-population algorithm. adding j2se14 on my old powerbook used to take me 7 minutes. now it takes 4.

4. i've improved the web app's caching mechanism from being totally dumb to being just a little dumb. i don't technically need to restart the web app after an 'add' anymore

so now the process is a little more streamlined: create the api xml file (using the apixml tool), invoke the 'add' command. this takes me maybe 3-4 minutes now for your average api.

the dilemma is that we always generate more great ideas than we have time for. i have lots of plans for this site but who knows if i'll ever get to them. maybe as a community we can. but there are a few things that i have to do to allow openjavadocs.org to truly be a community-enabled system: giving you control over managing apis.

here's a partial to-do list, sorted by degree of importance (descending):

1. set up a system where adding or updating apis on openjavadocs.org is distributed. the api management overhead could be made minute if it were shouldered by the entire community. anyone wishing to add (or update) an api would simply complete an online form. the request would be placed on a queue and processed into ashkelon shortly thereafter, or maybe that night (i have begun working on this).

2. i wrote ashkelon back in the days before the ascent of o/rm's (hibernate et al). it's high time i totally replace direct jdbc calls with hql. for one thing it'll take care of caching for me.

3. let go of ashkelon's api xml format altogether and rely on stronger maven integration. the maven project.xml file could become the defacto source of all the information ashkelon needs to do its javadoc'ing. (actually i already have a maven project.xml adapter. but i haven't yet changed my personal practice of using the original xml format)

4. i want to take the ui's markup to a higher semantic level (yeah, i'm a ui freak). it's already highly semantic but i want to be able to make ashkelon into an ashkelon zen garden.

there you have it. an update on where i am. i know that david walend had blogged on the topic of community javadocs for java.net. i also realize the response out there was very positive. anyone interested in helping out please let me know. as with most things open source, i won't commit to a specific timeline. but now at least you know where i'm trying to go with this. thanks. / eitan

"On the road again"

I'm about to embark on a set of trips: I'm participating in the 2005 'No Fluff Just Stuff' software conferences tour. The first conference is up in Milwaukee; the tour is detailed on the NFJS web site.

I last participated in 2003, giving talks on a couple of open source projects. My talks in 2003 included the Castor data binding framework for Java, XUL, and my ashkelon open source documentation system.

So, after absence from the symposia in 2004, I'm looking forward to getting back on board, so to speak. I'll be giving four to five talks this time around, four of which are new topics.

One aspect of these conferences that I really like is that they seem to attract top-notch attendees. With few exceptions, almost every attendee I've met at NFJS events was there for all the right reasons:

not because he or she was "sent" there or "had to" be there, but because he or she is truly passionate about his work; they take it seriously, and they enjoy being active players in their industry.

This reminds me of the reasons i decided a number of years ago to start attending my local jug meetings. Something happens to you somewhere in your career where you feel a true passion for your work. You start seeking others in the field with whom you can relate, and discuss all kinds of software problems that you mutually find fascinating (i guess we all do this virtually as well through our blogs and web site informal publications).

I find these interactions very satisfying. Over the years, I've had the pleasure to meet some real talent in Austin (Texas, where I live). likewise, I feel lucky that through NFJS, I've also gotten to know some national talent in the field, not to mention the opportunity to interact with other geographic Java communities.

It's for those same reasons that I'm attracted to open source: you're allowed to participate in the process, you're encouraged to join mailing lists, contribute to discussions, contribute patches, make a difference.

So, surprisingly, it looks like Willie Nelson's song "On the road again" applies to me quite fittingly this year (with a minor edit, that is):

On the road again
Just can't wait to get on the road again
The life I love is writin' software with my friends
And I can't wait to get on the road again

Who would have thought?

Reporting from Texas - Our July JUG Meeting

The Austin JUG held its July meeting two days ago. The topic was "JavaOne 2003 Recap." We had a great turnout (close to 100 people crammed into our meeting location) and the level of interest was high. Five members who attended JavaOne gave a short talk on their experience at the conference and participated in the discussion panel that ensued. What I particularly enjoyed was how complementary each of the speakers' talks were to one another. It was coincidental but it worked out great.

First up was Doug Bateman who attended JavaOne as part of the ServerSide.com press team covering the conference. He discussed one of the main themes of the conference: the new features that are planned for J2SE 1.5 (generics, autoboxing, foreach loops, and more). This talk was nice and technical and to the point.

Next Lynn Sheen focused on what's new with J2EE and specifically EJB. Lynn attends every JavaOne and is a hardcore disciple of the platform. The talk was by no means restricted to the technical. Lynn relayed how the experience of the conference is just as strong a driver. And she didn't fail to end her talk with a re-enactment of the now traditional T-shirt toss (only with a single T-shirt though).

Third up was Albert Leigh, who works for Sun MicroSystems in Austin, Texas. Albert gave a great overall perspective of the conference and its main message of "Java Everywhere." Albert had also participated in setting up and running the hands-on labs at JavaOne and showed us pictures of the lab rooms and the activities that took place.

Rob Sartin spoke next. Rob spoke at JavaOne; he presented the technical session: TS-3055, "Extremely Accessible Servlets." What I particularly liked about Rob's talk was his ability to put his experience into perspective. He started by recalling a debate at another conference a long time ago (back in 1996) between C++ developers and persons who had already envisioned how Java would grow to become a mainstream programming language.

Michael Yuan spoke next. He delivered a BOF at JavaOne. Michael is quite active in the community. He frequently writes or co-authors articles for JavaWorld and various magazines such as Dr. Dobbs' Journal. He also has a book coming out on J2ME. Michael's talk blended much humour. He pretty much had the whole room laughing the entire time. One of Michael's most important messages was not to overlook the J2ME platform and the important role that handheld devices are going to play in the coming years. Furthermore, skills in programming J2SE readily transfers to programming in J2ME.

The final Discussion Panel included all the speakers, plus me. The format was quite simple: have the audience fire questions to the panelists to discuss and answer. What I really like about JUG meetings is how much the events include attendees. Alex Moffat who had also attended the conference didn't hesitate to relate his experiences in the guise of a question to the panel. That was great! I took the opportunity to talk about java.net and some of my participation with blogging on java.net.

Overall, the meeting was a great success and generated much interest. This interest was reflected in the increase in posts to our discussions list, which in the previous weeks had seen relatively little traffic.

One item I failed to mention is a tradition was have at our JUG to hold a preliminary, short talk ahead of the main event. Our board member Damon Clinkscales came up with the idea. We call this short talk 'the technotizer' (as in the analogy to appetizers before the main meal). Our technotizer for July was given by Jeff Gaer, a veteran programmer, about a Java-based rules engine API called Mandarax.

I'm glad that through this blog I am able to share some of the happenings in my corner of the woods, Austin, Texas.

Impressions of "Mac OS X for Java Geeks"

I recently read Will Iverson's "Mac OS X for Java Geeks" and thought I'd contribute my impressions of this recently published book.

In summary:

• a quick read
• a good book
• nice diversity of topics
• well-balanced selection of topics

This is one of these topics where you know it's a hot topic but you can't quite define it. Maybe it's because Mac OS X and Java are fairly orthogonal.

On the one hand, there exist Apple extensions to Java which allow you to do cool things but that sort of defeats the very purpose of Java. On the other hand, anything pure Java has nothing to do with OS X.

Nevertheless I believe the author did a good job with this book in terms of its structure, and covering various Mac OS X'ish things related to Java from bundling a Java desktop application for the Mac OS X platform, to Apple-specific APIs such as the spelling framework, quicktime, and speech. Other topics covered pertain to installing popular Java apps such as Tomcat or Jboss on OS X. There's also the prerequisite how to set up mysql and postgresql for Mac OS X. Lastly, I enjoyed the last topic on Web Services and the sample AppleScript clients that call the java web services developed in that chapter.

The main dilemma with a book on this topic is that Apple has been moving fairly fast with upgrades and redid a lot of things with the release of J2SE 1.4.1 for OS X, including how apps are bundled. The Jar bundler is now the main utility for bundling apps (and no longer the MRJ AppBuilder).

An easy read, doesn't assume much (if any) a priori knowledge of various Java APIs, Mac OS X, or databases.

Excited about new O'Reilly book on Tomcat

Don't ask me why but I ordered my copy of the O'Reilly Tomcat book online instead of picking it up at the bookstore at JavaOne. My copy just came in the mail.

It's nice to see how Tomcat has matured and that we now have access to a bound reference on this popular server which has become an industry workhorse.

Thanks to the authors, the contributors, and to O'Reilly for a very needed and very apt new book in their Java series.

http://www.oreilly.com/catalog/tomcat/

This work is licensed under a Creative Commons License.