So, here's a real, concrete example of the need for case by case back
compat. See https://issues.apache.org/jira/browse/LUCENE-1662
It's completely stupid that ExtendedFieldCache even exists. It is a
dumb workaround for a made up problem that has nothing to do with real
coders living in the modern age of development where IDE's make
refactoring these types of things very cheap. Namely, the notion that
interfaces must never change lest every 6-9 months some minute number
of users (I'd venture it's less than 1% of users) out there, who by
any account are completely capable of implementing hard core Lucene
internals (like extending FieldCache), yet are seemingly incapable of
reading a CHANGES file with a huge disclaimer in it, have to recompile
(GASP!) their code and put in a dummy implementation of some new
interface method. Yet, here we are with Yonik fixing very real
problems that are a direct result of coding around back compat. (along
with a mistake; it took a long time for this issue to even be
discovered) that very much effect the usability of Lucene and the day
to day experience of a good number of users.
In other words, the real fix for L-1662 is for ExtFieldCache to be
folded into FieldCache and for the file to be removed, never to be
heard from again.
The same can be said for the whole Fieldable issue, but that's a
different day.
Ranting,
Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
