I recently commited a long awaited internal API change, letting resource
loaders rely on Readers+encoding rather than on InputStreams
(commits 1752784 and 1752787).
As Nathan commented in VELOCITY-793, "Providing B.C. support would be
nice, but is certainly not required nor even expected.". But I've got a
little issue of conscience about how to handle backward compatibility here.
We've got a method to deprecate or suppress:
InputStream getResourceStream(String source)
and a new method:
Reader getResourceReader(String source, String encoding)
For now, I handled B.C. by deprecating getResourceStream(), and
implementing getResourceReader() to rely on the former one. It will
serve the purpose of letting existing resource loaders work without any
modification.
But it has a big defect: someone implementing a new resource loader will
typically want to just implement all absctract methods, which means he
will have to implement getResourceStream(), and won't be asked to
implement getResourceReader()...
So I think we have to deprecate the ResourceLoader class itself, and
create a new ResourceReader class.
The new ResourceReader class will lack the getResourceStream() method.
The deprecated ResourceLoader class will inherit ResourceReader, leave
getResourceStream() abstract, and implement getResourceReader().
If you have another proposal to name the ResourceReader class, I'm
interested. (ResourceFetcher? ResourceProvider?)
Claude
