Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!usenet.ukfsn.org!not-for-mail
From: Martin Gregorie <martin@address-in-sig.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Fav. Memory Stream Impl.
Date: Wed, 30 Nov 2011 01:08:21 +0000 (UTC)
Organization: UK Free Software Network
Lines: 49
Message-ID: <jb3vm5$ii7$1@localhost.localdomain>
References: <jaojsb$hso$1@news.albasani.net> <4ed0101b$0$282$14726298@news.sunsite.dk> <jaqhed$23v$1@news.albasani.net> <9jflnkFnrgU1@mid.individual.net> <jaug5s$hsi$1@news.albasani.net> <9jgqmvFjc4U1@mid.individual.net> <javfl2$bni$1@news.albasani.net> <6b19df45-6141-45f0-ae2e-8ff30ece4928@y42g2000yqh.googlegroups.com> <jb042k$rjp$1@news.albasani.net> <9ji3juFomgU1@mid.individual.net> <4ed4bfc0$0$8819$426a74cc@news.free.fr> <jb2n7d$kgk$1@news.albasani.net> <jb3f5b$e7l$1@localhost.localdomain> <jb3flh$c34$1@news.albasani.net> <jb3hff$e7l$3@localhost.localdomain> <jb3kjd$nb5$1@news.albasani.net>
NNTP-Posting-Host: 84.45.235.129
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: localhost.localdomain 1322615301 19015 84.45.235.129 (30 Nov 2011 01:08:21 GMT)
X-Complaints-To: usenet@localhost.localdomain
NNTP-Posting-Date: Wed, 30 Nov 2011 01:08:21 +0000 (UTC)
User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master)
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10345

On Tue, 29 Nov 2011 22:59:06 +0100, Jan Burse wrote:

> Martin Gregorie schrieb:
>> On Tue, 29 Nov 2011 21:34:54 +0100, Jan Burse wrote:
>>
>>> Martin Gregorie schrieb:
>>>> As you say the individual file sizes are a few tens of bytes, have
>>>> you looked at using ByteInputStream and ByteOutputStream?
>>>>
>>>> If you have considered them, why are they unsuitable?
>>>
>>> They could play a part in the game. But two problems are unsolved:
>>> sharing and positioning.
>>>
>> My bad: I meant ByteArrayInputStream and ByteArrayOutputStream
>>
>> The names are a little confusing: ByteArrayInputStream reads *from* a
>> byte array. The ByteArrayOutputStream writes *into* a byte array.
>>
>> I've used them to move byte arrays to and from CLOB columns in
>> databases,
>> where they were straight-forward to use with CLOB sizes ranging from a
>> few bytes to a few megabytes, though I never had more than one or two
>> instances in use at a time.
>>
>>
> I don't see a constructor where I could hand over a buffer content from
> the memory stream. So that multiple reader and/or writers can share the
> same buffer content.
>
The idea is that you write to the ByteArrayOutputStream, close it, grab 
the byte array using toByteArray() and store that until it is needed. 
Then you construct a ByteArrayInputStream with the byte array as the 
constructor argument. This does, of course, assume that you never want to 
write and read an instance simultaneously. 

I'd think implementing non-simultaneous access should be easy enough to 
bury inside a <MemoryStream> class.

Beyond that I'm guessing since you've said little or nothing about 
whether you need simultaneous read and write access to a <MemoryStream> 
instance, whether an instance gets read more than once and how many 
instances can exist at the same time.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |