Henri Gomez wrote:
> Well I'm more usefull in IO area. Also I will be more than happy to see if
> we could 'arrange' the spec and avoid the use of byte[] in execute call
> returns since I'm using huge XML-RPC replies in my day jobs and it hurt
> badly the JVM. IO will be more interesting in such case
Don't know, what exactly you are thinking of, but one of the primary
targets of the streaming branch was being able to get rid of byte[].
However, while we are talking about, there might be a different topic,
which came up just yesterday in a discussion here:
We do have an application which deals with large strings and large
base64 streams (aka byte arrays). It is not desirable to put them into
memory. A nice extension (which I am going to realize at some point
anyways, if you won't do it) would be like the following:
- Create configurable options maxByteArraySize and maxCharArraySize
with default values 0 and a configurable option tmpArrayDir with
default System.getProperty("java.io.tmpDir").
- Change the readers for byte[] and String (ByteArrayParser and ...
heck, the latter one might be tricky, because String may sit directly
within the value tag, so it's the RecursiveTypeParserImpl itself)
as follows: If the created object is within the configured size,
then the byte array or String is returned, as usual. However, if
that is not the case, then a temporary file is created and a
reference to the file is returned. The reference should have
streaming accessors, of course.
- Create a utility class, that recursively scans an array,
collection, or map for such references and replaces them with
the byte arrays or strings. (Not all software locations are
prepared for such things.)
How about that? Other ideas quite welcome. This is just my proposal how
I'd try to attack the problem.
Jochen
