Just a few note that popup from my mind:
* Shouldn't DefaultObjectCache and ObjectCacheEntry be package-privates?
* ObjectCacheEntry.lock doesn't need to be volatile, since the field
is never modified (it can be final). Unless I'm missing something,
"volatile" just add overhead in this context.
* In DefaultObjectCache, the following lines are not really consistent:
cache = Collections.synchronizedMap(new HashMap()); // Line 45
synchronized (cache) { ...} // Line 131
Because Collections.synchonizedMap doesn't use 'cache' as the lock.
It use a private lock instead. It may be better to not use
Collections.synchronizedMap(...) and uses 'synchronized (cache)'
explicitly where needed.
* I'm not sure to understand the intend of various 'test(...)'
methods? (especially the difference compared to 'get(...)'
is not clear to me).
How do we process if I would like to perform some edition in the code that do
not impact functionality (e.g. factor out some redundant method calls)? Should
I
wait that your project is more advanced in order to avoid to disturb?
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
