Hello !
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.
=> I specified a move in Tortoise SVN I was using, I check what happened.
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?
=> OK.
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).
=> org.apache.sis.logging.Logging was carrying others dependencies from the
project and I wished to have a driver for Squirrel made of one or two jars
only.
But I correct this.
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?
=> The goals of these (yet still incomplete) classes are not to log
messages, even if they are doing this too, it's to grant the objects
inheriting them the ability of auto-checking themselves, and if they find
some troubles then, to list all the errors, warnings they can find and not
only the first one. But, I have not put the parts doing the auto-checking of
the objets yet and I understand really well why find these classes gruesome
! I am really sorry ! Soon I will complete these classes.
The overall idea of these classes is to allow the API to check an object
entirely before doing something important with it. Most of the time, I use
this feature before inserting or updating a business object into a database.
I ask, for example, my Customer object about itself : "Do you feel ok ?", if
the object replies : "no, I have no Name" or something else, I will throw an
InvalidCustomerException. Because if I carry a Customer object from function
to function it has to be ok (in memory at least) : it has respect some core
rules. This kind of defensive programming is really useful when you are
reading business objects from a database that has not be written by you and
seldom contains errors you cannot figure easily : you detect theses errors
immediately. And silently or not, depending what you want.
I will move this classes outside the log package, even if they will stay on
utility jar.
Marc.
