Thursday, April 10, 2014

Wednesday, March 26, 2014

Java Language Puzzle 4

How does one access the Class object associated with a primitive type? This can be necessary when using reflection.

Wednesday, March 19, 2014

Sapphire 8 : Outline Decorations

Multiple text decorations can now be added to the nodes in the master-details editor page outline in order to show additional information in a way that is set apart from the main node label.


A definition of a text decoration is composed of text and an optional color. Both of these properties support Sapphire EL. When text is null, the decoration is not shown. Multiple decorations can be specified for one node.

        <label>${ Name == null ? "Uncategorized" : Name }</label>
            <text>${ ( Items.Size == 0 ? null : Concat( "(", Items.Size, ")" ) ) }</text>

The framework API has changed accordingly.

@Label( standard = "text decoration" )
@XmlBinding( path = "text-decoration" )

public interface TextDecorationDef extends Element
    ElementType TYPE = new ElementType( TextDecorationDef.class );
    // *** Text ***
    @Type( base = Function.class )
    @Label( standard = "text" )
    @XmlBinding( path = "text" )
    ValueProperty PROP_TEXT = new ValueProperty( TYPE, "Text" );
    Value<Function> getText();
    void setText( String value );
    void setText( Function value );
    // *** Color ***
    @Type( base = Function.class )
    @Label( standard = "color" )
    @DefaultValue( text = "#957D47")
    @XmlBinding( path = "color" )
    ValueProperty PROP_COLOR = new ValueProperty( TYPE, "Color" );
    Value<Function> getColor();
    void setColor( String value );
    void setColor( Function value );
public interface MasterDetailsContentNodeDef
    // *** Decorations ***
    @Type( base = TextDecorationDef.class )
    @Label( standard = "decorations" )
    @XmlListBinding( path = "" )
    ListProperty PROP_DECORATIONS = new ListProperty( TYPE, "Decorations" );
    ElementList<TextDecorationDef> getDecorations();
public final class TextDecoration
    public String text()
    public Color color()
public final class MasterDetailsContentNodePart
    public List<TextDecoration> decorations()

Friday, March 7, 2014

Sapphire 8 : Check Box Group

Sapphire already includes a slush bucket and a check box list presentation alternatives for a possible values list.



However, in some cases where the set of possible values is known to always be small, a more compact presentation is desired. The new check box group presentation fills this need.

The check boxes can be arranged either horizontally or vertically.



The presentation will utilize ValueImageService and ValueLabelService, if present on the list entry's value property. The services must be attached to the value property's global service context.




  1. The property is a list property
  2. The list property has a PossibleValuesService
  3. There is exactly one possible member type
  4. The member type has exactly one property and that property is a value property
  5. The value property has @Unique annotation

Automatic Activation

This presentation does not activate automatically.

Manual Activation

The following style codes will activate this presentation as long as the applicability conditions are met.

  • Sapphire.PropertyEditor.CheckBoxGroup - produces horizontal presentation
  • Sapphire.PropertyEditor.CheckBoxGroup.Horizontal
  • Sapphire.PropertyEditor.CheckBoxGroup.Vertical

Thursday, March 6, 2014

Sapphire 8 : Event Suspension

Model events can now be suspended while performing a multi-step operation. This can be helpful in avoiding distracting flashing of the UI as the model goes through the intermediate states.

     * Suspends all events related to this element and everything beneath it in the model tree. The suspended
     * events will be delivered when the suspension is released.
     * @return a handle that must be used to release the event suspension
    Disposable suspend()
     * Suspends all events related to this property and everything beneath it in the model tree. The suspended
     * events will be delivered when the suspension is released.
     * @return a handle that must be used to release the event suspension
    Disposable suspend()
final ElementList<PurchaseOrderEntry> entries = po.getEntries();
final Disposable suspension = entries.suspend();

    final PurchaseOrderEntry entry = entries.insert();
    entry.setItem( "USB Cable" );
    entry.setQuantity( 2 );
    entry.setUnitPrice( "2.5" );

Monday, March 3, 2014

Announcing Sapphire 0.7.1 Release

On behalf of all who contributed, I am very proud to announce the availability of the Sapphire 0.7.1 release.


Thursday, January 30, 2014

It is time to reboot Eclipse Development Process

Eclipse Foundation has a reputation for being heavy on process, especially among up-and-coming projects that compare us unfavorably to other open source communities, such as GitHub. Eclipse Development Process (EDP) is very prescriptive on what must be done by member projects at various stages with little regard for the fact that there is not a one true way of developing software. Perhaps it doesn’t have to be this way?

Creation Review

To create a project, the team must find an existing project willing to host it and create a document to sell the idea to the PMC and EMO. If the team succeeds in convincing the gatekeepers, there is a waiting period for the creation review and another waiting period while the project name is reviewed for potential trademark issues. It can take many months to get a project created.

I propose that we automate the creation process and remove all of the reviews. A developer should be able to create a project after entering a name, a short description and the initial set of committers. The trademark review can be done asynchronously and the status publicized with a badge on the project dashboard. To make this manageable, project termination must be similarly automated. Any project with no measurable activity is given a few notices and then automatically archived.

IP Review

Each third-party dependency and a non-committer contribution must be reviewed by Eclipse Foundation’s legal team to ensure IP cleanliness. This is a valuable differentiator that draws many projects to Eclipse Foundation, but why should EDP mandate it for all projects and force it as a requirement for every release?

I propose that we replace the IP Review prior to a release mandate in EDP with an “IP Reviewed” badge that can be awarded to a release. For maximum flexibility, the badge can be earned either before or after the release date. This would allow projects to decide if their specific community requires the extra degree of safety afforded by the review. Maybe IP cleanliness is something that a project achieves after a few releases instead of being stuck unable to make a release until all the issues are sorted out.


When a project is created, it enters an incubation phase where the team must learn how to be a good project and get all the initial IP ducks in the row. Once the project team feels they’ve suffered the indignity of the egg for long enough, they petition for a graduation review and another document must be prepared. Then a small group of individuals will review the state of the project and hopefully confer upon the project the “mature” mantle.

This process assumes that once a project matures, it stays mature, but in practice many mature projects regress after the graduation review to the point that they operate worse than some incubating projects.

As an adopter of many open source projects, I find the incubation bit of little value when evaluating a project. Instead, I head to Ohloh to check on the project activity, I head to the project’s forum to see if adopter questions are answered in a timely manner and I head to the releases page to see if the project has been making regular releases.

We could easily replace the incubation and the graduation review with a better project dashboard and automated badges keyed to various aspects of project vitality. I’d love to see Eclipse Foundation partner with Ohloh for the source repository analysis.

Release Reviews

For each release, a project is required to produce a plan in a tightly-prescribed format with milestones, themes and other such content. At the end of the release, the project is required to produce a release review document, which frequently repeats much of the content from the plan, just using a different verb tense. Then the project must seek approval from the PMC and EMO, a release review must be scheduled and a waiting period must be observed.

I have nothing against projects that find this approach valuable, but this is mandated for all projects.

I propose that all of this is scrapped and replaced with a much less prescriptive system. In the portal, the project lead adds a release by specifying a version, a description, a release date and a set of links to various relevant resources. The portal then displays a release dashboard showing this information and a Bugzilla report. The release dashboard should be sufficient for the community to get a very good understanding of the purpose of the release and the progress, but if necessary the project can always augment with links to the wiki. Once the release is ready, the project lead presses the big “release” button and the release is marked as completed. There is no need to seek approval from anyone and no waiting period.


We need to ask ourselves why Eclipse Foundation exists. I don’t believe that EDP as it exists today is central to Eclipse Foundation’s mission. We should scrap it and replace it with a much smaller set of rules, where only those rules that are justified as absolutely essential are included. This will make life less frustrating for the existing community and ensure that Eclipse Foundation remains competitive to become a home for the next big thing.