[geotk] Can I prevent Geotoolkit from spawning new threads?

[Martin Desruisseaux]

Jon Blower a écrit :

> In Google App Engine applications cannot write to the local disk
> anyway - they must use Google's I/O abstractions to write to their
> distributed file store.  Files can only be read from the local
> filesystem from inside the application's WAR file.  So I was thinking
> of packaging epsg.properties in the application's WAR and reading CRSs
> from there.  Presumably somewhere in the GeoTk code there is a method
> for parsing WKT that is not dependent on factories (even if it's
> buried somewhere in a private method)?

Yes, an application could instantiate directly the PropertyEpsgFactory class 
without using any Factory at all. He would have to cache the result himself if 
he wish to, which also avoid the WeakValueHashMap issue.


> I'm not sure why Geotk needs a WeakHashMap implementation, since there
> is one in the JDK.  I'm also not sure why weak collections need
> background cleanup threads; entries will automatically disappear from
> WeakHashMaps when the keys are garbage-collected.  (The JDK doesn't
> have a WeakHashSet or Cache implementation AFAIK.)  I guess there must
> be a reason though?

Just realized that I misnamed the class in my email: Geotk provides 
Weak*Value*HashMap. The JDK WeakHashMap applies to keys, while Geotk 
WeakValueHashMap applies to values.

A search for WeakValueHashMap in Google shows an amazing amount of projects 
which developped this functionality on their own (JScience, JBoss, Apache, ...).

The garbage collector sets the referent to null in WeakReference, the background 
thread is for removing immediatly the corresponding entry from the Map. This is 
a bit different from JDK WeakHashMap, which removes the corresponding entry only 
when a method is invoked on that WeakHashMap instance (so Geotk has a more 
aggressive cleaning policy).

But anyway it should not be an issue if PropertyEpsgFactory is used directly.


>> The whole java.awt.geom package is excluded from this white list.
> 
> Oh dear.  :-(  This looks like the biggest problem.  I wonder if it's
> possible to provide awt.geom as a separate JAR in user space?  I shall
> investigate on the GAE forums and see if I can find a reason why it's
> omitted.

The javax.vecmath package could also be used as a substitute of AffineTransform, 
but that would be change that I would prefer to isolate on a mercurial clone and 
would require significant work. But after that point, WMS/WCS implementors would 
still be faced to the exclusion of the whole java.awt.image and javax.imageio 
packages as well.

	Martin