Currently, Lucene4c makes extremely limited use of APR.
It's basically used for a very small amount of memory allocation (which
we could do without due to GCJ's garbage collection), and to let us
integrate with APR pools, for cleanup purposes.
Additionally, we seem to require the use of jlibtool, rather than GNU
libtool, which means we need APR because that's where jlibtool comes
from. This is debatably more of a bug in our build system than a
dependency though, and we should probably fix it.
So the question becomes, do we want to continue requiring APR, which
adds a non-trivial dependency, just so that we can integrate with pools?
The pool integration could probably be handled just as well with the
addition of a few wrapper functions, so it's debatable if it needs to be
handled in the core system.
The other potential reason for keeping APR is that it leaves us the
ability to retain an API that could actually be implemented in pure C,
without requiring a GC. If someone actually picks up the C
implementation someday and wants to finish it, it would be nice to be
able to use the same interface we use for the GCJ backed version, and if
we start to depend totally on the GC without leaving APR pools in the
picture to provide an alternative we'd be painting ourselves into a
corner so to speak.
So what do people think?
-garrett
It's basically used for a very small amount of memory allocation (which
we could do without due to GCJ's garbage collection), and to let us
integrate with APR pools, for cleanup purposes.
Additionally, we seem to require the use of jlibtool, rather than GNU
libtool, which means we need APR because that's where jlibtool comes
from. This is debatably more of a bug in our build system than a
dependency though, and we should probably fix it.
So the question becomes, do we want to continue requiring APR, which
adds a non-trivial dependency, just so that we can integrate with pools?
The pool integration could probably be handled just as well with the
addition of a few wrapper functions, so it's debatable if it needs to be
handled in the core system.
The other potential reason for keeping APR is that it leaves us the
ability to retain an API that could actually be implemented in pure C,
without requiring a GC. If someone actually picks up the C
implementation someday and wants to finish it, it would be nice to be
able to use the same interface we use for the GCJ backed version, and if
we start to depend totally on the GC without leaving APR pools in the
picture to provide an alternative we'd be painting ourselves into a
corner so to speak.
So what do people think?
-garrett