2) Hints does not work
> >
> > This was a surprise to me; basically our Hints are a straight extension of
> > the Java2D rendering hints; to "fix" this I would need to look into breaking
> > that relationship; and possibly relaxing our Hints class to allow Object as
> > a key (so either Java 2D rendering hints could be used; or our GeoTools
> > hints).
> > This one annoys me as I don't think I could handle it without disrupting
> > existing implementations.
> Uh, this is indeed quite annoying. Why is this happening in the first place?
Hints
-------
My impression is that the Java2D rendering subsystem is not present
(http://developer.android.com/reference/packages.html); and thus the rendering
hints class is not available.
Remember the game (http://en.wikipedia.org/wiki/Dalvik_(software):
1) google does not want to pay for a JVM license
2) create their own Dalvik VM
3) compile Java -> .class
4) recompile .class -> .dex
5) run and enjoy
The problem is step (5).
ServiceRegistery vs ServiceLoader
---------------------------------------------------
Now when we grabbed a plugin system for GeoTools we chose the one from ImageIO
(http://download.oracle.com/javase/1.4.2/docs/api/javax/imageio/spi/ServiceRegistry.html)
- I assume this is where our use of rendering hints comes from?
My understanding is they have migrated this solution to java.util for Java 6
(http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html).
Yep; the ServiceLoader implementation is much more clean then what we are
using; same solution just now "official".
Let me check something - is ServiceLoader available? Yes it is ....
- http://developer.android.com/reference/java/util/ServiceLoader.html
So if this works Factory SPI must be available on Andriod; so we could Java6
and ServiceLoader to avoid ServiceRegistery.
Dropping Rendering Hints
------------------------------------
Just a second; ServiceRegistery does not mention Hints at all (it is not
present in andriod so we would have to move to ServiceLoader anyways).
But still let us see how hints are used; looking at the code it is only
FactoryRegistery (which extends ServiceRegistery) which uses hints.
(So this trouble is of our own making and not the fault of using
ServiceRegistery at all).
The minimal change to Factory would be:
BEFORE:
interface Factory {
//Map<RenderingHints.Key, ?> getImplementationHints();
Map<Object, Object> getImplementationHints();
}
(Note the use of ? was wrong in that it implies all the values would be the
same type)
This change would let us use our own Hints; and still supply rendering hints to
pass over to gt-render module.
We could then break our Hints class to not extend Rendering Hints (I am
actually fine with that as it would make it more explicit that this is a
general purpose solution):
public class Hints /*extends RenderingHints */ {
...
}
We already have our own Key and ClassKey classes so we should be alright. ------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
