Re: [Geotools-devel] Pledging (again) for implementation separation

[Martin D. <mar...@te...>]

Hello all

There is my 2 cents...



> 1) Both of us now agree that Java1.1 is dead.  Sun are no longer developing 
>    it and the installed user base will do nothing but fall from now on.  
>    GeoTools 0.8 will continue to evolve towards a stable 1.0 release and 
>    will be targeted directly at Java 1.1.

I can't agree more!!! You have made an happy man.



> 2) J2ME is a live platform that is fully supported by Sun and it is still 
>    being developed. Therefore it makes sense for GeoTools2 to support and 
>    target it.

Agree. The drawback of supporting J2ME is lower than supporting JDK 1.1
(for example, J2ME have most of the collection API in java.util). I
still hope that we can organize the modules in such a way that J2SE
implementation will not suffer from J2ME support.



> 3) There will from this point on therefore be three types of modules. Once
>    which are platform independent and ones which target one or other of the 
>    two platforms.

My proposal is that the platform independent one contains only
interfaces, no classes. There is an other reason for having an
interface-only core: RMI. You can't do Remote Method Invocation
without interfaces. OpenGIS interfaces are done this way.



> 4) defaultcore will be renamed j2secore
>    At this point, j2secore can take advantage of and use whatever aspects 
>    of the j2se api it likes.  But it must conform with the core interface, 
>    which can not take advantage of a full j2se

I propose "j2se.core" instead of "j2secore".
To be more complete, I propose three branchs:

     org.geotools.core           (only interfaces)
     org.geotools.j2se.core      (J2SE implementation)
     org.geotools.j2me.core      (J2ME implementation)

And the same for all others packages. All packages in "org.geotools" 
could be mirrored into "org.geotools.j2se" and "org.geotools.j2me".

Interfaces in "org.geotools.core" should contains the lowest
common denominator for all supported platform. Implementation
in "org.geotools.j2se.core" can contains additional API taking
advantage of J2SE (for example exposing an AffineTransform).
Note that interfaces from OpenGIS specification are very
minimalist too.


> 7) meta unit tests need to be created for cases where a j2me and a j2se 
>    implementation of core interfaces are implemented. i.e. a single unit 
>    test built against the interfaces in core will systematicly check that 
>    both j2me and j2se implementations work. [...]

Agree. Test should be performed against interfaces, which are after all 
the public API that the user will see.


> 9) The default assumption for the availability of resources in GeoTools2 
>    will be the current stable release of JxSE as promoted by Sun at any 
>    given time.  By default no additional APIs can be considered to be 
>    available.
> 
>    Note that modules are free to override this assumption.  As noted in 8) 
>    above each module can specify a list of required extensions, a 
>    3DLanscape module can therefore require that Java3D be available but I 
>    would argue strongly that j2secore should not.

Fully agree for current stable release of J2SE. I also agree for letting
each module specify their own requirements. But we should note that
because of inter-module dependencies, some requirements may appear
pretty early. For example a Matrix class is absolutly essential to
coordinate transformations. I use javax.vecmath.GMatrix for that.
So all module using my implementation of Coordinate Transformation
Services (if my implementation is considered good enough for that)
will have an indirect dependencies to JAI and Java3D. Since CTS is
a somewhat fundamental module for most other modules, those dependencies
would appear early...



> 11) java2DRenderer needs to stay as java2DRenderer to distinguish itself 
>     from PDFRenderer, SVGRenderer

I don't think so. In my understanding, targeting a different device
(Screen, Printer, image buffer, PDF, SVG...) is not Renderer's job:
this is the Graphics2D's job. According my understanding of the Batik
project (http://xml.apache.org/batik/), we create a SVG file with the
following steps:

   * Get a special Graphics2D object from the Batik library.
   * Just use this Graphics2D object with our Renderer in the usual way.

This is the way to print and the way to write in an image buffer, and
this is also the way to create a SVG file with Batik. I guess it would
be the same for creating a PDF file. Consequently, just one Renderer
implementation for J2SE that work with any Graphics2D seems enough to
me.


> 12) platform specific implementations of core interfaces should remain in 
>     the same package as the interface.
>     e.g.
>     org.geotools.rendering.java2DRenderer
>     org.geotools.rendering.j2meRenderer
> 
>     Most developers will only be targeting one or the other, and will have 
>     checked out modules accordingly so will not see or have access to 
>     confusing classes.
>     The unit test can therefore be:
>     org.geotools.rendering.RenderTest
> 
>     And thus have package level access to both Renderers, something which is 
>     often very important for unit tests to be able to do.


Developper can check up only one module, but we still have mixed classes 
in the JavaDoc. We still have the risk of accidental use of wrong
classes for our target platform, especially for users installing both
implementations (after all, a J2ME application is likely to talk with
a J2SE server somewhere, especially if our interfaces are RMI enabled).
It also impose the addition of prefix in front of every classes in order 
to distinguish them ("j2seRenderer" and "j2meRenderer"). If we go ahead
with common packages, we will be very tempted to write a lot of classes
targeting all platforms. I believe it is dangerous: since we can't guess
what future will be, we may want to add J2SE feature later that we
didn't imagined at the time the class was created. I'm all for common
interfaces, but I believe that common implementations jeopardize our
future. I still believe that we should put each implementation in their
own package.

About unit test: If we want our unit test to work on both J2SE and J2ME
implementations, then it must performs the test against interfaces only.
Consequently, it is limited to interface's public members only; putting
it in the same package than implementation will not change much. I
suggest that if we feel that a package-private feature should be tested,
then this test is likely to be implementation-dependent. Consequently,
this test would be a special test for e.g. J2SE implementation only, not
J2ME. My proposal it:

   1) org.geotools.renderer.RendererTest performs test on all renderer.
      It doesn't need access to package-private members, since it would
      be implementation dependent test and consequently could not apply
      to every renderers.

   2) org.geotools.renderer.j2se.RendererTest performs test on the
      J2SE implementation of Renderer only. It have access to package-
      private members. This RendererTest would not exists if we feels
      that the general test (#1) is complete enough.

   3) Same for org.geotools.renderer.j2me.RendererTest.


Just my 2 cents...

		Martin.