You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/10/11 17:47:32 UTC
Checked collections commit
Hello all
The last commit added CheckedArrayList, CheckedHashSet and
CheckedHashMap, which extend the standard JDK classes with the addition
of synchronization, runtime type checks and write permission checks.
Usually, the synchronization and type checks are provided in the
standard JDK by the following methods:
* Collections.synchronizedSet(Set)
* Collections.checkedSet(Set, Class)
However the standard synchronizedSet(Set) method does not allow us to
specify a lock different than 'this'. In the metadata implementation, we
wanted to synchronize on the metadata object that own the collection
rather than the collection itself.
The check for write permission is a little bit different than the
standard Collections.unmodifiableSet(Set) method, in that it is
determined by a condition external to the collection itself: in our
case, it is determined by whether the metadata which own the collection
has been made "read only".
By extending directly the ArrayList, LinkedHashSet and LinkedHashMap
classes instead than creating wrappers around arbitrary List, Set and
Map, we avoid the indirection levels of Collections.synchronizedSet
wrapping Collections.checkedSet wrapping LinkedHashSet for instance.
Those 3 particular implementations are used very often, so I though that
they were worth special treatment. When we really need wrappers around
arbitrary implementations, the standard java.util.Collections methods
are perfect for that.
The base class of metadata objects has been updated for using those
checked collections. So things are slowly starting to fall in place.
Martin
Re: Checked collections commit
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
This makes total sense to me, and allows to take advantage of downstream flexibility where we simply
want to standardize on interfaces like Lists and Collections.
Cheers,
Chris
On Oct 11, 2012, at 8:47 AM, Martin Desruisseaux wrote:
> Hello all
>
> The last commit added CheckedArrayList, CheckedHashSet and CheckedHashMap, which extend the standard JDK classes with the addition of synchronization, runtime type checks and write permission checks. Usually, the synchronization and type checks are provided in the standard JDK by the following methods:
>
> * Collections.synchronizedSet(Set)
> * Collections.checkedSet(Set, Class)
>
> However the standard synchronizedSet(Set) method does not allow us to specify a lock different than 'this'. In the metadata implementation, we wanted to synchronize on the metadata object that own the collection rather than the collection itself.
>
> The check for write permission is a little bit different than the standard Collections.unmodifiableSet(Set) method, in that it is determined by a condition external to the collection itself: in our case, it is determined by whether the metadata which own the collection has been made "read only".
>
> By extending directly the ArrayList, LinkedHashSet and LinkedHashMap classes instead than creating wrappers around arbitrary List, Set and Map, we avoid the indirection levels of Collections.synchronizedSet wrapping Collections.checkedSet wrapping LinkedHashSet for instance. Those 3 particular implementations are used very often, so I though that they were worth special treatment. When we really need wrappers around arbitrary implementations, the standard java.util.Collections methods are perfect for that.
>
> The base class of metadata objects has been updated for using those checked collections. So things are slowly starting to fall in place.
>
> Martin
>
Re: Checked collections commit
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Adam
Please feel free to ask as you want, no problem :)
The Cache class is for any kind of object associated to an identifier.
For example Coordinate Reference Systems (CRS) are often specified as
the primary key value in the EPSG database. For example "EPSG:4326"
stands for a geographic CRS using the WGS84 datum, and "EPSG:3395"
stands for a Mercator projection using the WGS84 datum. SIS will provide
a factory creating CRS objects from an EPSG code. But if the same EPSG
code is specified many time, we want to return the existing instance.
This will happen often since GIS applications typically contain
thousands of geometries using the same CRS.
This applies also to metadata, for example getting a CI_Citation object
from an ISBN code. This could apply to images where the identifier could
be the absolute path name, etc. In the later case, since images can be
large, we need to measure the cost of keeping those objects in a cache.
About caching of map tile, maybe the Cache class could be used for that,
but we way also use something more specialized. We could take
inspiration from the TileCache interface from Java Advanced Imaging [1]
for instance.
Martin
[1]
http://download.java.net/media/jai/javadoc/1.1.3/jai-apidocs/javax/media/jai/TileCache.html
Le 14/10/12 09:35, Adam Estrada a écrit :
> Martin,
>
> I am catching up on emails from a long week of conferences and a little
> vacation time so please forgive me if this response sounds redundant or at
> all dense. Is your cache class to be used as an actual map cache to store
> and retrieve map tiles? It kind of sounds like that as we often test to see
> if cached tiles have been changed by counting pixels and their values
> before generating new ones. If nothing has changed, leave them alone,
> right? Can this class be used like that or is that the intent?
>
> Adam
Re: Checked collections commit
Posted by Adam Estrada <es...@gmail.com>.
Martin,
I am catching up on emails from a long week of conferences and a little
vacation time so please forgive me if this response sounds redundant or at
all dense. Is your cache class to be used as an actual map cache to store
and retrieve map tiles? It kind of sounds like that as we often test to see
if cached tiles have been changed by counting pixels and their values
before generating new ones. If nothing has changed, leave them alone,
right? Can this class be used like that or is that the intent?
Adam
On Thu, Oct 11, 2012 at 1:02 PM, Mattmann, Chris A (388J) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> Hi Martin,
>
> Thanks for mentioning it and these classes seem very useful for managing
> Mapped collections which
> themselves are useful in the spatial metadata context. I see why they are
> necessary to tackle upfront.
>
> Cheers,
> Chris
>
> On Oct 11, 2012, at 9:38 AM, Martin Desruisseaux wrote:
>
> > Hello Chris
> >
> > Le 12/10/12 01:16, Mattmann, Chris A (388J) a écrit :
> >> This makes total sense to me, and allows to take advantage of
> downstream flexibility where we simply
> >> want to standardize on interfaces like Lists and Collections.
> >
> > Thanks a lot :-). Maybe the Cache class is also worth to mention (while
> not yet used in SIS). This class implements the Map interface and uses
> internally the java.util.concurrent package (including the
> ConcurrentHashMap). It provides a mechanism for blocking a thread which
> asked the value for a key when that particular value is in process of being
> calculated by another thread. It also replaces automatically the references
> to oldest values by weak references when the "cost" of all entries is over
> a threshold. The "cost" is used-specified, but a good example is the amount
> of pixels in an image. The oldest values are replaced by weak references
> rather than discarded because if strong references still exist somewhere
> else in the application, removing the value from the Cache will not save
> anything. Quite the opposite, it would duplicate objects if the value is
> recomputed.
> >
> > The difference between Cache and WeakValueHashMap is that
> WeakValueHashMap has no concurrency support and uses only weak references
> (no mechanism replacing strong references by weak references after some
> cost threshold). WeakValueHashMap is used only for avoiding object
> duplications (reuse existing instances); it can't be used as a cache since
> it doesn't retain entries from being garbage collected.
> >
> > Regards,
> >
> > Martin
> >
>
>
Re: Checked collections commit
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
Thanks for mentioning it and these classes seem very useful for managing Mapped collections which
themselves are useful in the spatial metadata context. I see why they are necessary to tackle upfront.
Cheers,
Chris
On Oct 11, 2012, at 9:38 AM, Martin Desruisseaux wrote:
> Hello Chris
>
> Le 12/10/12 01:16, Mattmann, Chris A (388J) a écrit :
>> This makes total sense to me, and allows to take advantage of downstream flexibility where we simply
>> want to standardize on interfaces like Lists and Collections.
>
> Thanks a lot :-). Maybe the Cache class is also worth to mention (while not yet used in SIS). This class implements the Map interface and uses internally the java.util.concurrent package (including the ConcurrentHashMap). It provides a mechanism for blocking a thread which asked the value for a key when that particular value is in process of being calculated by another thread. It also replaces automatically the references to oldest values by weak references when the "cost" of all entries is over a threshold. The "cost" is used-specified, but a good example is the amount of pixels in an image. The oldest values are replaced by weak references rather than discarded because if strong references still exist somewhere else in the application, removing the value from the Cache will not save anything. Quite the opposite, it would duplicate objects if the value is recomputed.
>
> The difference between Cache and WeakValueHashMap is that WeakValueHashMap has no concurrency support and uses only weak references (no mechanism replacing strong references by weak references after some cost threshold). WeakValueHashMap is used only for avoiding object duplications (reuse existing instances); it can't be used as a cache since it doesn't retain entries from being garbage collected.
>
> Regards,
>
> Martin
>
Re: Checked collections commit
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Chris
Le 12/10/12 01:16, Mattmann, Chris A (388J) a écrit :
> This makes total sense to me, and allows to take advantage of downstream flexibility where we simply
> want to standardize on interfaces like Lists and Collections.
Thanks a lot :-). Maybe the Cache class is also worth to mention (while
not yet used in SIS). This class implements the Map interface and uses
internally the java.util.concurrent package (including the
ConcurrentHashMap). It provides a mechanism for blocking a thread which
asked the value for a key when that particular value is in process of
being calculated by another thread. It also replaces automatically the
references to oldest values by weak references when the "cost" of all
entries is over a threshold. The "cost" is used-specified, but a good
example is the amount of pixels in an image. The oldest values are
replaced by weak references rather than discarded because if strong
references still exist somewhere else in the application, removing the
value from the Cache will not save anything. Quite the opposite, it
would duplicate objects if the value is recomputed.
The difference between Cache and WeakValueHashMap is that
WeakValueHashMap has no concurrency support and uses only weak
references (no mechanism replacing strong references by weak references
after some cost threshold). WeakValueHashMap is used only for avoiding
object duplications (reuse existing instances); it can't be used as a
cache since it doesn't retain entries from being garbage collected.
Regards,
Martin
Re: Checked collections commit
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Martin,
This makes total sense to me, and allows to take advantage of downstream flexibility where we simply
want to standardize on interfaces like Lists and Collections.
Cheers,
Chris
On Oct 11, 2012, at 8:47 AM, Martin Desruisseaux wrote:
> Hello all
>
> The last commit added CheckedArrayList, CheckedHashSet and CheckedHashMap, which extend the standard JDK classes with the addition of synchronization, runtime type checks and write permission checks. Usually, the synchronization and type checks are provided in the standard JDK by the following methods:
>
> * Collections.synchronizedSet(Set)
> * Collections.checkedSet(Set, Class)
>
> However the standard synchronizedSet(Set) method does not allow us to specify a lock different than 'this'. In the metadata implementation, we wanted to synchronize on the metadata object that own the collection rather than the collection itself.
>
> The check for write permission is a little bit different than the standard Collections.unmodifiableSet(Set) method, in that it is determined by a condition external to the collection itself: in our case, it is determined by whether the metadata which own the collection has been made "read only".
>
> By extending directly the ArrayList, LinkedHashSet and LinkedHashMap classes instead than creating wrappers around arbitrary List, Set and Map, we avoid the indirection levels of Collections.synchronizedSet wrapping Collections.checkedSet wrapping LinkedHashSet for instance. Those 3 particular implementations are used very often, so I though that they were worth special treatment. When we really need wrappers around arbitrary implementations, the standard java.util.Collections methods are perfect for that.
>
> The base class of metadata objects has been updated for using those checked collections. So things are slowly starting to fall in place.
>
> Martin
>