• JXErrorPane -- DONE

• JXTitledSeparator -- DONE

• Renderer-based Highlighting

• JXErrorDialog^? -- DONE
• JXHeader -- DONE

• JXStatusBar -- DONE

1. starting from the lightweight, widget-targeted classes (example: TableColumnXX)
2. to usage of those collaborators by the widget (example: JXTable api related to the enhanced TableColumnXX).
3. after that: - from cross-component collaborators (example: Highlighter)
4. to usage of those collaborators by a sample widget (JXTable api related to highlighter)
5. to analogous usage by the other interested widgets (JXList, JXTree api related to highlighter)

• JXTable - enhanced base api
• JXTable - enhanced column support

• JavaBean -- DONE

Collection Components

That's my favourite name to denote components for showing collection-type data like lists, trees, tabular data.They allow a rich user-interaction which is fully configurable by developers. They support advanced interaction themes (like f.i. sorting, searching) in a consistent manner. This leads to a huge api which has to be broken down into bounded clusters to be manageable for review. The approach I'm using in review preparation is bottom up:

• starting from the lightweight, widget-targeted classes (example: TableColumnXX)
• to usage of those collaborators by the widget (example: JXTable api related to the enhanced TableColumnXX).
• after that: - from cross-component collaborators (example: Highlighter)
• to usage of those collaborators by a sample widget (JXTable api related to highlighter)
• to analogous usage by the other interested widgets (JXList, JXTree api related to highlighter)

Component support

• JXTable enhanced columns
• JXList
• JXTree
• JXTreeTable

Cross-component themes

• Renderer-based Highlighting
• Sorting/Filtering
• Searching
• Rollover
• Action

• EyeDropperColorChooserPanel
• JXColorSelectionButton
• ColorUtil
• JXImageView
• ListComboBoxModel
• MapComboBoxModel
• EnumComboBoxModel

• JavaBean
• JXPanel
• JXLoginPanel^?
• JXErrorDialog
• JXHeader
• JXGraph
• JXMultiSplitPane
• JXTitledPanel^?
• JXTitledSeparator
• JXStatusBar

<-- This creates the navigation links to :  Home | Help | Index | etc.  -->

SwingLabsAPIReview

<-- this automatically adds a header showing the name of this page -->

<-- Your JavaDesktop? article goes here. Please try to include at least one sentence describing this topic. -->

<-- Also please try to include at least one sentence describing where each link goes. -->

<-- Please make sure some other page points to your new article so that others can find it! -->

<-- For more on how to write Javapedia articles please read the WritingArticles? page. -->

Introduction

Motive

Process

The process is to tag all code as "dev" to begin with. (In the future, this will be done by leaving all "dev" code in one or more development branches, and only having "rc" quality code in the trunk.) Then take components through the review process (first internal, then public). Finally, change to "rc" for the component once approved (in the future, this will mean committing to the trunk). Every component, package, and class will pass through this process (some quicker than others). At the end of this process, comprehensive unit tests, javadocs, and tutorial documentation must be written for the component.

What "comprehensive" means is: the unit tests must pass Jeanettes muster (our resident Unit Test advocate). JavaDocs^? must be complete (all tags where the belong, written according to the guidelines posted here http://java.sun.com/j2se/javadoc/writingdoccomments/). Tutorial docs must exist on swinglabs.org according to Josh Marinacci's standards (our resident writer).

Reviews can be lengthy. Due to this, what I suggest is that we'll do a review here at Sun, and publish the materials and findings to that review in the wiki. We'll then hold a second review externally. The idea is that all minor issues will shake out during the internal review and make for a more expeditious public review.

I like to use two sources of material for reviews: the javadoc and a set of powerpoint slides. This means that javadoc must be written for components to be reviewed :). More importantly, it makes it easier on reviewers. I like to use powerpoint to exhibit code samples, design decisions, use cases, and other supporting documentation. For the purpose of being web-friendly, I'd rather publish these slides as .pdf files rather than powerpoint.

Once reviewed and approved by both internal and public review "boards" (comprising committers -- of course everyone is free to chime in) the code is marked as RC.

Question: What I'm still not quite clear about is what are the criteria for an "api review"?

The first requirement is a piece of code that is ready to be defended. What we don't want to do is to devolve into a design-by-committee review, which is what happens to poorly or incompletely thought out API. It's ok to go into it with a few open questions, but we also need to have a suggested solution to think about.

Also, expect that even the most trivial code (like JXPanel) is going to be revised during the process. In a successful review a year and a half ago (or thereabouts) Bino brought in the authentication framework. It looked different afterward, but has essentially been stable since.

Be prepared to defend why a certain design was taken. Why not one of several alternative designs? What makes the proposed solution better? More complicated API needs to be more rigorously defended, particularly with why the complicated API was chosen. Are the use cases enabled by the more complex API worth it?

Of course a list of requirements up front is critical. What are we trying to achieve with this API? If the requirements are off, the review will most likely be postponed until the requirements are refined and API refined as necessary.

Reviews