I was thinking about the discussion on more complex feature models that have taken place recently. I was wondering if it was really necessary to modify JUMP's feature model to obtain some of the services that a more complex feature model would allow.
I think that you could use "relationships" to model complex features instead of embedding one feature as the attribute of another feature, as you would in a more complex feature model. (When I say relationship, I mean something similar to the relationships that exist between table records in an RDBMS.)
For example, let’s say that I want to model a municipal road system as a complex feature. This road system contains a number of road segments. You could approach this in two or three different ways:
 You could represent the municipal road system as a FeatureCollection. This FeatureCollection would also be a Feature with its own unique attributes, like "NumberOfRoadSegments". It would contain RoadSegment features as members of its collection.
 You could represent the municipal road system as a more complex Feature object. One of the attributes of this feature could be a Java Collection or some similar container that held references to the RoadSegment features.
I think that both of these options are somewhat cumbersome, and would require some tweaking of OpenJUMP's innards. (Although the first option is probably less cumbersome than the second.) What if we that like a relational database designer for a minute and "normalized" our data? If I was designing a traditional RDBMS to model a municipal road System I would use two tables. The MunicipalRoadSystems table would store its attributes in the table columns, and one of these attributes would be a unique identifier. This would likely be the primary key for the table. The RoadSegments table would store the attributes of individual road segments in its table columns. Each record in the RoadSegment table would also include the primary key or unique identifier for a road system. This would establish a relationship between the road segment and the road system. (Or I might have a third table that stored both the road segment unique identifier and the road system unique identifier. This would allow a road segment to be part of more than one road system. This would be a relationship table used to model a many-to-many relationship.)
Now, consider a third option for representing a municipal road system based on the "normalized" RDBMS approach.
 You create a non-spatial FeatureCollection to represent the MunicipalRoadSystem. (This is similar to the MunicipalRoadSystems table in the RDBMS.) You then create a spatial FeatureCollection that stores a Feature for each road segment. You then design a plug-in that manages relationships between features and presents an API for these purposes to the developer.
I can’t think of anything you could do in the first two approaches that couldn’t be done in the third approach. The third approach also has two distinct benefits:
 It doesn’t require modification of OpenJUMP’s current Feature Model, which is both simple and elegant.
 It involves the creation of a system for managing relationships between features. Although this can be used to model complex features as I have described, it can also be used to model relationships between simple features. This is a powerful bonus.
When I have to explain what a GIS is to someone unfamiliar with the topic I usually say something like “its an intelligent computer-based map”. If the person has some technical skill or is familiar with computers I’ll say something like “it’s a database that can handle location information” instead.
I find that I can often devise solutions to GIS software design problems if I try to remember that a GIS is a “database that can handle location information”. Although this is an oversimplification, I find it allows me to take advantage of relational database design principles.
This alternative to representing complex features is an example of this principle in action.
The Sunburned Surveyor