Eitan Suez's Blog

September 2005 Archives

No docdoclet for xdoclet?

Xdoclet did a very good thing: not only did they use a doclet-like mechanism to produce xml files and other artifacts to make j2ee and web development easier, they gave us a better design than javadoc in that the code generation is template-driven. My understanding is that xdoclet v1 used the xdt template engine while xdoclet 2 is now based on generama (where one can choose to use velocity or freemarker template engines). All this is now old history.

The interesting thing to me is that the javadoc standard doclet (which remains the defacto standard) still doesn't employ this design pattern. That is, it generates its html pages in code without resorting to templates. This makes it difficult for anyone to enhance these pages or come up with alternative pages ( modifying stylesheet.css doesn't quite cut it :-) ), as Kohsuke found out recently (see his recent blog entry).

So another way to put it is that a rich variety of plugins exist for xdoclet such as ejbdoclet, webdoclet, hibernatedoclet, etc.. but the glaring omission to me is that there is no "docdoclet", that is an xdoclet plugin for generating javadocs.

One of the things I did when I developed ashkelon a number of years ago was to take apart the standard doclet and produce the jsp template equivalent thereof. So hiding in the ashkelon project under htdocs/basic reside these templates.

I'm now thinking that it would be very desirable to have an xdoclet-like mechanism for producing alternate javadoc ui's; ones with ajax features, for example. I can think of many scenarios where a developer might want to add a section to a class's doc page, just like kohsuke did for jaxb 2.

I've started working on adding an feature/option to ashkelon to alternatively produce static docs from the same jsp templates that i use to produce the dynamic version of ashkelon (less the dynamic features such as search). I actually have a working prototype. Maybe once this feature is finished and tested and I cut a new version of ashkelon, it might help folks more easily extend the production of javadocs in interesting ways.

Evolving the Java language..

We all know that Java 5 represents one of the most significant evolutions of the Java language since its inception. And Java 5 is taking root and sprouting at different rates in different environments. The tool makers are the rapid adopters, of course. The IT houses are obviously going to proceed more slowly, more cautiously.

So I was thinking about all of these new features in the language, some in APIs, things like annotations, varargs, the foreach statement, and generics. Improving a language is obviously not an easy thing. Especialy if it's an established language. It's a delicate matter. You have to be careful about maintaining compatibility while at the same innovating and adding features of value.

Then something interesting occurred to me, which I thought I'd share with you..

There are a few things in the language which I believe most of us will agree are particularly annoying. I can think of two of them at the moment:

1. the fact that the transfer of variables to inner classes requires that these variables be marked final
2. the fact that in a constructor we are restricted from using the super() constructor invocation to the first statement in the constructor (that is, we can't invoke super() after having performed some initialization).

So I thought to myself: here's are a few opportunities to improve the java language that are simple and straightforward. Why not address these first?

I'm obviously taking the liberty here to talk about things I know little about. I am not a language design implementor. But we all know that these restrictions don't exist in certain other languages (e.g. ruby); that ultimately they're artificial. There must exist a way to remove these restrictions from the Java language (?). I find it curious that this has not yet been done.

My Dream JDesktopPane..

One area of Swing that does not appear to be getting much attention these days (or that may have fallen out of favor with developers) are the elements that make up the Multiple Document Interface: JDesktopPane and JInternalFrame.

I believe that there's tremendous potential in further developing the Swing features in this space.

What I am envisioning is nothing less than a JDesktop that rivals the modern desktops of operating systems today, in terms of feature sets. I'd like to share this vision with you. These would be some of the features in 'my ideal java desktop':

1. the ability to easily dock panels along the edges of a JDesktopPane (I do realize that there exist commercial implementations of this feature today)
2. multiple workspaces (like we have on linux desktops)
3. apple-like features: minimizing frames with effects?
4. ctrl-tabbing to switch between jinternalframes
5. a dock
6. easy default keyboard shortcuts for hiding the current internal frame, or, the one i really like from the macos is 'hide others' (command-option-h)
7. a trash
8. standard window arrangement features such as tile & cascade (why not?)
9. the ability to move/place iconized views of jinternalframes anywhere on the jdesktoppane, to configure the placement behavior ('snap to grid' etc..)

Opportunities are rife for improving this area of the Swing API. I believe such an environment could become the basis for some really nice and powerful rich desktop applications.

I realize I'm not explaining myself fully here. "Why would one want to create effectively a 'desktop within a desktop' type of application??" you may ask.

This raises a much deeper question. It is my belief that desktops today, albeit nice, are an incomplete model of a virtual world. The world of today's operating systems desktops is a poor world of files, folder, and applications. It is a primitive model that I believe could be made significantly richer. The desktop metaphor is effectively an object oriented user interface platform and is an excellent foundation upon which to build applications with rich domains. Imagine the ability to place representations of domain objects in folders, to search/query for objects with the facility that we query files today, to invoke their methods with a right-click gesture, to plug in model extensions, to integrate different models into a single user interface substrate. You'd use the same environment, the same runtime application to do email, to file documents, to write checks, or to do software development. More so, there would exist an overarching consistency in terms of how you manipulate objects, regardless of their type.

Well, I've gone considerably beyond the scope of this blog entry, so I better stop here. :-)

This work is licensed under a Creative Commons License.