Hey Martin, My +1 here would be for Guice or for Spring -- (though Spring introduces a ton of bloat). I've heard good things about Guice and 700kb is pretty small compared to Spring :)
Cheers, Chris On 12/10/12 1:21 AM, "Martin Desruisseaux" <[email protected]> wrote: >Hello all > >I committed today a "DefaultNameFactoryTest" file. If one looks at the >source code [1], the interesting aspect is that this file doesn't >contain any test. Instead it just creates a SIS DefaultNameFactoryTest >instance, passes it to the super-class constructor and inherits all the >tests defined in GeoAPI [2]. This illustrates the GeoAPI >inter-operability goal, admittedly only at the test suite level in this >case. > >In this test case, DefaultNameFactory is instantiated directly. However >in a production environment, we need to allow users to specify their own >Factory instance. In Geotk, we tried to do that using >java.util.ServiceLoader. However while ServiceLoader is still very well >suited to situations where we need *all* instances of a given interface >(all map projections, or image readers for all formats, etc.), it become >difficult when we need to select one instance among many possibilities. >An alternative proposed years ago was to use Spring, but I would like to >avoid making such dependency mandatory. > >Since 2009, JSR-330 [3] is providing an @Inject annotation for that. >JSR-330 is a 2.4 JAR file available on Maven central under Apache 2 >license, so it seems a reasonable dependency. Note that JSR-330 provides >only annotations - implementations is another matter, discussed below. > >Those annotations are now included in JEE 6 [4]. So they do not >introduce any new dependency in JEE environments. But it would introduce >dependency in JSE environments. In addition to the above-cited JSR-330 >JAR files, JSE environments would need an implementation. One impossible >implementation is Google Guice [5], also available on Maven Central >under Apache 2 license. However this is an almost 700 kb dependency, >with some transitive dependencies (I didn't analysed them yet). However >I'm not yet familiar with Juice - in particular does it forces >applications to be run is some kind of containers? > >An alternative could also be to provide our own trivial implementation >(just hard-coded references to the factory implementations), which users >can replace by Guice or JEE when such environment in available. Since I >have never experimented JSR-330 yet, I don't know if it is a reasonable >approach. > >Any though? > > Martin > > >[1] >https://svn.apache.org/repos/asf/sis/branches/JDK7/sis-utility/src/test/ja >va/org/apache/sis/util/type/DefaultNameFactoryTest.java >[2] >http://www.geoapi.org/geoapi-conformance/apidocs/org/opengis/test/util/Nam >eTest.html >[3] http://jcp.org/aboutJava/communityprocess/final/jsr330/index.html >[4] http://docs.oracle.com/javaee/6/api/javax/inject/package-summary.html >[5] http://code.google.com/p/google-guice/ >
