Hey Martin, +1 these all make sense to me.
Cheers, Chris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: [email protected] WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Martin Desruisseaux <[email protected]> Organization: Geomatys Reply-To: "[email protected]" <[email protected]> Date: Wednesday, December 10, 2014 at 12:00 AM To: Apache SIS <[email protected]> Subject: Proposed guidelines for SIS development >Hello Marc and all > >Thanks Marc for the commits on the shapefile module. Can I take this >opportunity for checking if we agree on some guidelines for SIS >developments? > >Do not forget to use "svn move" when moving files (do not rely too much >of the IDE for doing the proper thing), otherwise history is lost. For >example AbstractResultSet, AbstractCollection, etc. lost their history >as a result of their move. > >The new committed classes put the "abstract" or "final" keywords before >the "public", "protected" or "private" ones, while the rest of Apache >SIS uses the reverse order. While it is technically not required, I >would like a consistent coding convention for Apache SIS. The order used >by the rest of Apache SIS is consistent with the customary order as >specified by the section 8.1.1 of the Java Language Specification [1], >which is also the order used by the JDK source code and tools like >"javap". Do we agree to follow this customary order? > >I suggest to never use java.util.Logger.getLogger(String) for getting a >logger, but rather org.apache.sis.logging.Logging.getLogger. It is >almost the same, except that the later gives us a possibility to >redirect to Apache Common loggins or Log4J if desired. This is really >needed when using Apache SIS in some larger applications which require >the use of Log4J (using any other framework causes all our logging >messages to disappear - I agree it is silly, but such applications exist). > >The new AbstractAutoChecker and AbstractAutoCheckerList classes in the >sis-utility module duplicate the functionalities of >IndexedResourceBundle. While I did no benchmark, I would expect >IndexedResourceBundle to have higher performance mostly because it >caches the MessageFormat (it also loads the resources from a binary file >and uses index for accessing directly the resources, but the effect is >probably much smaller). It also provides compile-time safety for the >keys, integrates with the internationalization mechanism of the Java >logging framework (which can defer MessageFormat usage until needed) and >with the InternationalString defined by GeoAPI. I would suggest to use >IndexedResourceBundle as a consistent localization mechanism for Apache >SIS. What do you think? > > Martin > > >[1] http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.1.1 >
