[armedbear-devel] is there a good method to read/write java byte arrays?
alessiostalla at gmail.com
Wed Mar 17 16:55:52 UTC 2010
On Wed, Mar 17, 2010 at 5:32 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> On Wed, Mar 17, 2010 at 5:22 PM, Mark Evenson <evenson at panix.com> wrote:
>> On 3/17/10 5:04 PM, Alessio Stalla wrote:
>>> I wrote sys::%make-byte-array-output-stream in order to make the
>>> runtime compiler capable of generating bytecode without using
>>> temporary files; it wasn't meant to be used by the ABCL user, and as
>>> such it's not very polished (for example, the type of a
>>> byte-array-output-stream is simply STREAM). In any case, it's defined
>>> in the ByteArrayOutputStream Java class, and as you correctly noted,
>>> it explicitly sets the element type to (unsigned-byte 8). As a quick
>>> and dirty solution, you could more or less copy-paste that class and
>>> replace "output" with "input" :) (as well as update Autoload.java to
>>> make ABCL know of the new primitives).
>>> We should probably polish it a bit and release it as an extension.
>> Well, at least we should quickly whip out the inverse version so David
>> doesn't have to rely on hacking Stream.java (although I'm not sure when
>> telling Stream that initAsBinaryStream() means a format of unsigned 8bit
>> bytes will fail).
>> I think we can commit to the interface you've implemented in
>> ByteArrayOutputStream, as those are the basic necessary operations.
>> Or maybe I am not seeing what potential problems there would be with
>> this as a short-term strategy, Alessio?
> No problem at all in the implementation per se; however, when we'll
> make it an "official" extension, the interface will change (if
> anything, symbols won't probably be in sys anymore and they won't be
> prefixed with %). Since this functionality will have approximately 1
> user in the near future :), I think it's ok to commit a quick fix for
> David. I'm working on it right now.
Committed as r12557.
More information about the armedbear-devel