Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »


FeatureCollection is not a java.util.Collection


Jody Garnett,Michael Bedward,Andrea Aime




back in black

This page represents the current plan; for discussion please check the tracker link above.


History and Motivation

FeatureCollection needs to lighten up to be happy; the original FeatureCollection implementation was a java.util.Collection offering iterator based access to features stored in memory. When the data access layer was rewritten for DataStore the concept of a FeatureResults was introduced wich could be thought of as a "prepared statement" (able to fetch results each time it was asked). This is a nice light weight "streaming" model for data access that does not force us to load the data into memory.

The intension was to treat it a bit more like a Java ResultSet (so several iterators could be open against the same paged results). But the road to hell is paved with good intensions.

And the FeatureResults interface was in for some hell: 2.1.x Bring Back FeatureCollection was a last ditch community lead request to bring back the FeatureCollection api and allow iterators to be used (thus not existing current code). The compromise that was reached was to ask users to FeatureCollection.close( Iterator ) each iterator after use; so that we could still offer a nice streaming based approach to data access.

For GeoTools 2.5.x we made the migration to Java 5 and we could no longer allow FeatureCollection to implement java.util.Collection because of the new "for each" syntax did not offer a callback for us to close our iterators.

Bring back FeatureResult

In the spirit of Bring Back FeatureCollection here is our last minuet 2.7.x request to complete the journey; formally recognise that FeatureCollection is not a java.util.Collection and turf Iterator access (and other concepts that mirror in memory storage).

Remove the Listeners

First up is the add/remove listeners; a recent code review shows that they are only implemented by the new JDBCNG FeatureCollection (because justin is apparently very responsible). Due to everyone else not being responsible we can safely remove these since no client code could of depended on being sent an event.



Asking for your feature collection to be "loaded" into a DefaultFeatureCollection is the currently documented way of avoiding all this streaming nonsense and loading your data into memory.

The result is understood to be a java.util.Collection that also implements FeatureCollection. I think we should formalise this; and offer it as a migration path to anyone having trouble making the switch off iterator.

We may also wish to consider a different implementation for DefaultFeatureCollection:

  • TreeSetFeatureCollection - is used currently and is slow
  • ListFeatureCollection - is new and untested, but may be faster in day to day use?
  • SpatialIndexFeatureCollection - cannot be modified once made; not a suitable replacement

getSchema and getDescriptor()

This is a long standing hole in the API: FeatureCollection Descriptor for FeatureMembers

It sounds like this is just an additional method:

May also consider making the api consistent?


This proposal is the subject of a grass roots revolution on the geotools-devel list; indeed the revolution is on going and will not be televised.

Voting has not started yet:



no progress






lack mandate/funds/time


volunteer needed

  1. Deprecate iterator based methods
  2. Remove add/remove listeners (as they were not implemented)
  3. Update default implementation
  4. Update wiki (both module matrix and upgrade to to 2.5 pages) |
  5. Remove deprecated code from GeoTools project
  6. Update the user guide
  7. Update or provided sample code in demo
  8. review user documentation

API Changes


describe subject is being changed


describe what is being changed

Documentation Changes

list the pages effected by this proposal

  • No labels