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

Reply via email to