Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10224 > unrolled thread

Fav. Memory Stream Impl.

Back to article view | Back to comp.lang.java.programmer

Contents

  Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 18:39 +0100
    Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-25 10:34 -0800
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 20:59 +0100
        Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-25 12:16 -0800
          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 21:23 +0100
            Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 21:23 +0100
              Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-25 13:00 -0800
                Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 22:32 +0100
                  Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-25 22:36 +0100
                    Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-25 23:22 +0100
    Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 17:00 -0500
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-26 12:10 +0100
        Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-27 21:43 +0100
          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-28 00:13 +0100
            Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-28 08:14 +0100
              Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-28 09:10 +0100
                Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-28 02:47 -0800
                  Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-28 14:58 +0100
                    Re: Fav. Memory Stream Impl. Robert Klemme <shortcutter@googlemail.com> - 2011-11-28 19:52 +0100
                      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 00:22 +0100
                        Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 00:39 +0100
                        Re: Fav. Memory Stream Impl. Gene Wirchenko <genew@ocis.net> - 2011-11-28 17:03 -0800
                        Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 21:06 -0500
                          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-02-07 09:59 +0100
                            Re: Fav. Memory Stream Impl. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-07 09:59 -0800
                            Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2012-02-07 21:02 -0500
                              Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-02-08 09:55 +0100
                                Re: Fav. Memory Stream Impl. "John B. Matthews" <nospam@nospam.invalid> - 2012-02-08 12:18 -0500
                                  Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-02-08 20:23 +0100
                                    Re: Fav. Memory Stream Impl. Gene Wirchenko <genew@ocis.net> - 2012-02-08 13:18 -0800
                                  Re: Fav. Memory Stream Impl. Gene Wirchenko <genew@ocis.net> - 2012-02-08 13:18 -0800
                      Re: Fav. Memory Stream Impl. Mayeul <mayeul.marguet@free.fr> - 2011-11-29 12:25 +0100
                        Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 14:37 +0100
                          Re: Fav. Memory Stream Impl. Lew <lewbloch@gmail.com> - 2011-11-29 07:37 -0800
                          Re: Fav. Memory Stream Impl. Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-29 20:26 +0000
                            Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 21:34 +0100
                              Re: Fav. Memory Stream Impl. Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-29 21:05 +0000
                                Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-29 22:59 +0100
                                  Re: Fav. Memory Stream Impl. markspace <-@.> - 2011-11-29 14:06 -0800
                                    Re: Fav. Memory Stream Impl. "John B. Matthews" <nospam@nospam.invalid> - 2011-11-29 21:23 -0500
                                  Re: Fav. Memory Stream Impl. Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-30 01:08 +0000
                                    Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-30 14:03 +0100
        Re: Fav. Memory Stream Impl. Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 20:59 -0500
    Re: Fav. Memory Stream Impl. Roedy Green <see_website@mindprod.com.invalid> - 2011-11-26 00:26 -0800
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-26 12:05 +0100
        Re: Fav. Memory Stream Impl. Lew <lewbloch@gmail.com> - 2011-11-26 11:22 -0800
          Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2011-11-26 20:44 +0100
            Re: Fav. Memory Stream Impl. Lew <lewbloch@gmail.com> - 2011-11-26 17:15 -0800
      Re: Fav. Memory Stream Impl. Jan Burse <janburse@fastmail.fm> - 2012-01-28 00:11 +0100

Page 1 of 3  [1] 2 3  Next page →

#10224 — Fav. Memory Stream Impl.

Dear All,

Would be interested in a good memory stream
implementation. Requirement will be multiple
readers / writers and positioning.

Just found this code:

http://www.mikepaul.ca/index.php?option=com_content&view=article&id=3:net-style-memorystream-for-javaj2me&catid=4:mobile-dev&Itemid=4
.Net style MemoryStream for Java/J2ME!
Thursday, 27 May 2010 22:52 | Written by Michael Paul

Although it has read / write and positioning,
I don't think it is thread safe. Any other
implementations around.

Maybe some operations that provide InputStream /
OutputStream factory methods.

But

[toc] | [next] | [standalone]

#10230

On 11/25/2011 9:39 AM, Jan Burse wrote:
> Dear All,
>
> Would be interested in a good memory stream implementation.

What is a "memory stream?"

Java already has bounded and unbounded queues, in thread safe and 
non-thread safe version.  For special pruposes Java also has things like 
memory buffers for logging.

What's the actual use model for this thing?

(Esp. for those of us who don't know anything about C#/.Net)

[toc] | [prev] | [next] | [standalone]

#10232

markspace schrieb:
> For special pruposes Java also has things like memory buffers for logging.

Which classes? Part of JDK or some utility?

[toc] | [prev] | [next] | [standalone]

#10233

On 11/25/2011 11:59 AM, Jan Burse wrote:
> markspace schrieb:
>> For special pruposes Java also has things like memory buffers for
>> logging.
>
> Which classes? Part of JDK or some utility?


It wouldn't kill you to look through the Java API yourself, you know. 
Specifically for the logger, since that's what you seem to be interested in:

<http://docs.oracle.com/javase/7/docs/api/java/util/logging/MemoryHandler.html>

[toc] | [prev] | [next] | [standalone]

#10234

markspace schrieb:
> On 11/25/2011 11:59 AM, Jan Burse wrote:
>> markspace schrieb:
>>> For special pruposes Java also has things like memory buffers for
>>> logging.
>>
>> Which classes? Part of JDK or some utility?
>
>
> It wouldn't kill you to look through the Java API yourself, you know.
> Specifically for the logger, since that's what you seem to be interested
> in:
>
> <http://docs.oracle.com/javase/7/docs/api/java/util/logging/MemoryHandler.html>
>
>
>

No the memory stream need not be cyclic. The Java/J2ME
code reference I gave has maximally 256*chunks of size
16384 each. And there is something with a cicular buffer
in it.

But I guess the .NET memory streams are not cyclic. I am
looking for something like the .NET memory streams, so
that I can get rid of temporary file names in my
application.

Bye

[toc] | [prev] | [next] | [standalone]

#10235

Jan Burse schrieb:
>
> But I guess the .NET memory streams are not cyclic. I am
> looking for something like the .NET memory streams, so
> that I can get rid of temporary file names in my
> application.

http://msdn.microsoft.com/en-us/library/system.io.memorystream.aspx

[toc] | [prev] | [next] | [standalone]

#10236

On 11/25/2011 12:23 PM, Jan Burse wrote:
> Jan Burse schrieb:
>>
>> But I guess the .NET memory streams are not cyclic. I am
>> looking for something like the .NET memory streams, so
>> that I can get rid of temporary file names in my
>> application.
>
> http://msdn.microsoft.com/en-us/library/system.io.memorystream.aspx

<http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html>

<http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayInputStream.html>

[toc] | [prev] | [next] | [standalone]

#10237

markspace schrieb:
> On 11/25/2011 12:23 PM, Jan Burse wrote:
>> Jan Burse schrieb:
>>>
>>> But I guess the .NET memory streams are not cyclic. I am
>>> looking for something like the .NET memory streams, so
>>> that I can get rid of temporary file names in my
>>> application.
>>
>> http://msdn.microsoft.com/en-us/library/system.io.memorystream.aspx
>
> <http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayOutputStream.html>
>
>
> <http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayInputStream.html>
>
>
>

The memory stream should be sharable.
Thats why I wrote:

 > Requirement will be multiple readers / writers

And also seekable.
Thats why I wrote.

 > and positioning.

To my knowledge ByteArrayOutputStream and ByteArrayInputStream
do not satisfy these requirements.

Bye

[toc] | [prev] | [next] | [standalone]

#10239

Jan Burse schrieb:
> The memory stream should be sharable.

Well to some extend ByteArrayOutputStream and
ByteArrayInputStream are shareble. They are
at least thread safe, I find:

    public synchronized void write(int b) {

So the same output object can be used by multiple
threads. And the same input object can be used
by multiple threads.

But I would like to be able to do the same as with
a temporary file. Some threads open it for read,
and some threads open it for write.

Bye

[toc] | [prev] | [next] | [standalone]

#10244

On 25.11.2011 22:36, Jan Burse wrote:
> Jan Burse schrieb:
>> The memory stream should be sharable.
>
> Well to some extend ByteArrayOutputStream and
> ByteArrayInputStream are shareble. They are
> at least thread safe, I find:
>
> public synchronized void write(int b) {
>
> So the same output object can be used by multiple
> threads. And the same input object can be used
> by multiple threads.
>
> But I would like to be able to do the same as with
> a temporary file. Some threads open it for read,
> and some threads open it for write.

Why do you want to do that with binary data?  What is your use case?

Kind regards

	robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#10241

On 11/25/2011 12:39 PM, Jan Burse wrote:
> Would be interested in a good memory stream
> implementation. Requirement will be multiple
> readers / writers and positioning.
>
> Just found this code:
>
> http://www.mikepaul.ca/index.php?option=com_content&view=article&id=3:net-style-memorystream-for-javaj2me&catid=4:mobile-dev&Itemid=4
>
> .Net style MemoryStream for Java/J2ME!
> Thursday, 27 May 2010 22:52 | Written by Michael Paul
>
> Although it has read / write and positioning,
> I don't think it is thread safe. Any other
> implementations around.
>
> Maybe some operations that provide InputStream /
> OutputStream factory methods.

Use java.nio.ByteBuffer and handle concurrency in your code.

Arne

[toc] | [prev] | [next] | [standalone]

#10265

Arne Vajhøj schrieb:
> Use java.nio.ByteBuffer and handle concurrency in your code.

ByteBuffer does not extend automatically. If I do
put and reach the size of the byte buffer, I will
get an exception BufferOverflowException.

That is at least how I interpret the javadoc.

I am not looking for a bounded memory stream, it
should be unbounded, like (temporary) files are.
You just write and write and write, thats it.

Size control of the memory stream can be done
via close truncate for example.

The reference to the memory stream should be
still valid when an input stream or output stream
sitting on it does a close. With the same memory
stream reference I should be able to create new
input or output streams over it, that will work
on the previously written content.

Bye

[toc] | [prev] | [next] | [standalone]

#10281

On 11/26/2011 12:10 PM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>> Use java.nio.ByteBuffer and handle concurrency in your code.
>
> ByteBuffer does not extend automatically. If I do
> put and reach the size of the byte buffer, I will
> get an exception BufferOverflowException.
>
> That is at least how I interpret the javadoc.
>
> I am not looking for a bounded memory stream, it
> should be unbounded, like (temporary) files are.
> You just write and write and write, thats it.
>
> Size control of the memory stream can be done
> via close truncate for example.
>
> The reference to the memory stream should be
> still valid when an input stream or output stream
> sitting on it does a close. With the same memory
> stream reference I should be able to create new
> input or output streams over it, that will work
> on the previously written content.

http://docs.oracle.com/javase/6/docs/api/java/io/PipedInputStream.html
http://docs.oracle.com/javase/6/docs/api/java/io/PipedOutputStream.html

Still, why do you want to do this?  What problem are you trying to 
solve?  I'm not convinced that it is a good idea - especially when using 
unbounded buffers.

Cheers

	robert

[toc] | [prev] | [next] | [standalone]

#10282

Robert Klemme schrieb:
>
> http://docs.oracle.com/javase/6/docs/api/java/io/PipedInputStream.html
> http://docs.oracle.com/javase/6/docs/api/java/io/PipedOutputStream.html
>
> Still, why do you want to do this?  What problem are you trying to
> solve?  I'm not convinced that it is a good idea - especially when using
> unbounded buffers.

A pipe is not a memory stream. In a pipe the reader
does read where the writer does write. But I don't
have this requirement.

The only requirement I have, is that I can use
the memory streams in place of >>TEMPORARY FILES<<.
Whereas >>TEMPORARY FILES<< have a name and usually
exist on some media.

The memory streams should not exist on some media,
except in the memory. But they should share with
 >>TEMPORARY FILES<< multiple readers / writers and
positioninng. Since I can use a >>TEMPORARY FILES<<
name and open a RandomAccessFile with it.

So basically in my application I would like to have
some class, call it MemoryStream. And It would like
to be able to instantiate it. And this instance serves
than as a kind of a file name.

So this instance I should be able to use where I normally
would use the >>TEMPORARY FILES<< name. The only places
that come to my mind are:
   - creating an input stream from a file name, should
     then work from a memory stream instance.
   - creating an output stream from a file name, should
     then work from a memory stream instance.
   - creating a random acccess file from a file name,
     should then work from a memory stream instance.

What the memory stream instance will have in common
with a >>TEMPORARY FILES<< name, is that it will go
away when the application closes. So they are very
similar to >>TEMPORARY FILES<< with the option delete
on close.

Also I would like to be able to use the same memory stream
to open input streams, output streams, random access files,
as many as I want. This is also provided by >>TEMPORARY
FiLES<<, once a >>TEMPORARY FILES<< name is established, it
can be used for all kinds of stuff.

Here is a little example:
    A large clip board: This could be realized by a temporary
    file. When you make the copy operation, you simply write
    the copied content into the temporary file. When you make
    the past operation you reopen the temporary file and
    read the content that should be pasted from it.

The above could be realized by even passing the >>TEMPORARY
FILES<< name around in the system clipboard, so that the copy
paste works across applications. Provided that the applications
understand the content type.

But memory streams cannot passed around like this. Here is
the difference to >>TEMPORARY FILES<<. In their simple
implementation they are confined to the application that
created them.

Of course we could extend them and provide some RMI extension
of them, or what ever, so that the a memory stream references
becomes mobile. Or we could implement them in special shared
memory of the operating system, so that a direct shared access
from multiple applications is possible.

This mobility and shared access across multiple application,
which is a property of >>TEMPORARY FILES<<, is not required
for the memory streams I am looking for. So I guess if my
grandmother could program as she can knit pullovers for me,
she might do a memory stream class for me.

But unfortunately she knows only COBOL and I am looking for
a Java library. But she assured me that something like this
must exist on the web, and that I don't need to go into lengths
to code it by myself. So she told me:

    It's not difficult, but why reinvent the wheel?

Bye

[toc] | [prev] | [next] | [standalone]

#10285

On 11/28/2011 12:13 AM, Jan Burse wrote:
> Robert Klemme schrieb:
>>
>> Still, why do you want to do this? What problem are you trying to
>> solve? I'm not convinced that it is a good idea - especially when using
>> unbounded buffers.
>
> A pipe is not a memory stream. In a pipe the reader
> does read where the writer does write. But I don't
> have this requirement.
>
> The only requirement I have, is that I can use
> the memory streams in place of >>TEMPORARY FILES<<.
> Whereas >>TEMPORARY FILES<< have a name and usually
> exist on some media.
>
> The memory streams should not exist on some media,
> except in the memory. But they should share with
>> >TEMPORARY FILES<< multiple readers / writers and
> positioninng. Since I can use a >>TEMPORARY FILES<<
> name and open a RandomAccessFile with it.
>
> So basically in my application I would like to have
> some class, call it MemoryStream. And It would like
> to be able to instantiate it. And this instance serves
> than as a kind of a file name.
>
> So this instance I should be able to use where I normally
> would use the >>TEMPORARY FILES<< name. The only places
> that come to my mind are:
> - creating an input stream from a file name, should
> then work from a memory stream instance.
> - creating an output stream from a file name, should
> then work from a memory stream instance.
> - creating a random acccess file from a file name,
> should then work from a memory stream instance.
>
> What the memory stream instance will have in common
> with a >>TEMPORARY FILES<< name, is that it will go
> away when the application closes. So they are very
> similar to >>TEMPORARY FILES<< with the option delete
> on close.
>
> Also I would like to be able to use the same memory stream
> to open input streams, output streams, random access files,
> as many as I want. This is also provided by >>TEMPORARY
> FiLES<<, once a >>TEMPORARY FILES<< name is established, it
> can be used for all kinds of stuff.
>
> Here is a little example:
> A large clip board: This could be realized by a temporary
> file. When you make the copy operation, you simply write
> the copied content into the temporary file. When you make
> the past operation you reopen the temporary file and
> read the content that should be pasted from it.
>
> The above could be realized by even passing the >>TEMPORARY
> FILES<< name around in the system clipboard, so that the copy
> paste works across applications. Provided that the applications
> understand the content type.
>
> But memory streams cannot passed around like this. Here is
> the difference to >>TEMPORARY FILES<<. In their simple
> implementation they are confined to the application that
> created them.
>
> Of course we could extend them and provide some RMI extension
> of them, or what ever, so that the a memory stream references
> becomes mobile. Or we could implement them in special shared
> memory of the operating system, so that a direct shared access
> from multiple applications is possible.
>
> This mobility and shared access across multiple application,
> which is a property of >>TEMPORARY FILES<<, is not required
> for the memory streams I am looking for. So I guess if my
> grandmother could program as she can knit pullovers for me,
> she might do a memory stream class for me.
>
> But unfortunately she knows only COBOL and I am looking for
> a Java library. But she assured me that something like this
> must exist on the web, and that I don't need to go into lengths
> to code it by myself. So she told me:
>
> It's not difficult, but why reinvent the wheel?

There is a lot of "could" and "should" in there but no description of a 
real problem you are trying to solve.  Basically if you want to use 
other libraries which depend on java.io to open files you have little 
chance to smuggle a "memory stream" in there without going through the 
effort to modify byte code of classes.  So your "memory stream" could be 
made to work easily with your own code only.  But then, you'd probably 
be far better off using a data structure with specific type and not 
sequences of bytes.  If you need to store unstructured text, you can use 
a StringBuffer.  If you need to store other kinds of data you can use 
any of the classes from java.util.

Kind regards

	robert


PS: I hope you are aware that writing to files does not necessarily 
create disk IO.  For short lived temporary files chances are that you 
delete the file before it got written to disk.  And then there are in 
memory file systems available which you can mount and use like any other 
file system and which hold all the data in memory only.

[toc] | [prev] | [next] | [standalone]

#10287

Robert Klemme schrieb:
> Basically if you want to use other libraries which depend on java.io to
> open files you have little chance to smuggle a "memory stream" in there
> without going through the effort to modify byte code of classes.

No, I don't think that the above claim is right. Look see what
is written for the class InputStream:

	This abstract class is the superclass of
	all classes representing an input
         stream of bytes.
	http://docs.oracle.com/javase/1.4.2/docs/api/java/io/InputStream.html

So with proper OO I could implement:

     class MemoryStream {

          InputStream createInput();

     }

     class MemoryInput extens InputStream {
          ...
     }

The factory method could return a MemoryInput instance
from a MemoryStream instance. Similarly I could
provide OutputStrem createOutput etc..

The MemoryStream would be not the first stream that
has been created outside of java.lang via proper OO.
Think for example of the request and respons streams
of a web server. They are also made like this.

Bye

[toc] | [prev] | [next] | [standalone]

#10289

On Nov 28, 9:10 am, Jan Burse <janbu...@fastmail.fm> wrote:
> Robert Klemme schrieb:
>
> > Basically if you want to use other libraries which depend on java.io to
> > open files you have little chance to smuggle a "memory stream" in there
> > without going through the effort to modify byte code of classes.
>
> No, I don't think that the above claim is right. Look see what
> is written for the class InputStream:
>
>         This abstract class is the superclass of
>         all classes representing an input
>          stream of bytes.
>        http://docs.oracle.com/javase/1.4.2/docs/api/java/io/InputStream.html
>
> So with proper OO I could implement:
>
>      class MemoryStream {
>
>           InputStream createInput();
>
>      }
>
>      class MemoryInput extens InputStream {
>           ...
>      }
>
> The factory method could return a MemoryInput instance
> from a MemoryStream instance. Similarly I could
> provide OutputStrem createOutput etc..
>
> The MemoryStream would be not the first stream that
> has been created outside of java.lang via proper OO.
> Think for example of the request and respons streams
> of a web server. They are also made like this.

And how do you make library code use your memory stream factory
class?  Remember, there will by typically a line like this somewhere

FileInputStream fileIn = new FileInputStream(fileName);

There is no factory.  There is just an invocation of the constructor.

From what you write I get the impression that you are hooked into your
idea of using in memory piles of bytes as replacement for temporary
files because it looks like a good idea (and simple to do) on first
sight.  But I haven't seen anything so far which would convince me
that it's really a good idea altogether.

Kind regards

robert

[toc] | [prev] | [next] | [standalone]

#10291

Robert Klemme schrieb:
> And how do you make library code use your memory stream factory
> class?  Remember, there will by typically a line like this somewhere
>
> FileInputStream fileIn = new FileInputStream(fileName);

I will replace these constructors. The input streams /
output streams are factored via methods from the
memory stream instance, and not passed as an argument
to other constructors.

> From what you write I get the impression that you are hooked into your
> idea of using in memory piles of bytes as replacement for temporary
> files because it looks like a good idea (and simple to do) on first sight.

Well it might be a matter of taste what is a
good idea and what not.

In the present case I am expecting more performance,
since these memory streams will be used in high
frequency for small contents of about 10-50 bytes.

Maybe a part of Google Protocol Buffers could do:
http://code.google.com/intl/de-DE/apis/protocolbuffers/docs/reference/java/index.html

They have newInput() and newOutput(). Have to check.

Bye

[toc] | [prev] | [next] | [standalone]

#10301

On 28.11.2011 14:58, Jan Burse wrote:
> Robert Klemme schrieb:
>> And how do you make library code use your memory stream factory
>> class? Remember, there will by typically a line like this somewhere
>>
>> FileInputStream fileIn = new FileInputStream(fileName);
>
> I will replace these constructors. The input streams /
> output streams are factored via methods from the
> memory stream instance, and not passed as an argument
> to other constructors.

And I said you will have to use bytecode manipulation for this in case 
of other libraries (i.e. ones which you do not control or have access to 
sources to).

>> From what you write I get the impression that you are hooked into your
>> idea of using in memory piles of bytes as replacement for temporary
>> files because it looks like a good idea (and simple to do) on first
>> sight.
>
> Well it might be a matter of taste what is a
> good idea and what not.

In a way, yes.  I'd rather say it's a matter of goals which one wants to 
achieve.  There are means which work well for some ends and not so well 
for others.  If the goal is clear solutions can often be pretty easy 
aligned according to "good" and "not good".

> In the present case I am expecting more performance,
> since these memory streams will be used in high
> frequency for small contents of about 10-50 bytes.

*What* content?  Why do you not answer this question?  You didn't even 
state that you do not want to answer the question (which I could 
understand if you do not want to leak out ideas you are working on). 
But coming here and asking while at the same time ignoring those who are 
willing to help to find a good solution is not a strategy to success.

Regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#10315

Robert Klemme schrieb:
> *What* content?  Why do you not answer this question?  You didn't even
> state that you do not want to answer the question (which I could
> understand if you do not want to leak out ideas you are working on). But
> coming here and asking while at the same time ignoring those who are
> willing to help to find a good solution is not a strategy to success.

Strange approach to make help dependent on disclosure
of application details. Please note this is a public
forum, so when somebody posts a solution here everybody
profits from this, not only eventually me.

Bye

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web