«

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/...putStream.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

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/...putStream.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

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/ap...ava/index.html

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

Bye

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/

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

Jan Burse schrieb:
> 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
>

Last but not least, the solution poster might also
profit by getting some feedback etc..

Bye

On Tue, 29 Nov 2011 00:22:48 +0100, Jan Burse <>
wrote:

>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

Leaving out critical details can lead to suggestions that are not
so good, or even bad.

>forum, so when somebody posts a solution here everybody
>profits from this, not only eventually me.

That is the idea, yes.

Sincerely,

Gene Wirchenko

On 28/11/2011 19:52, Robert Klemme wrote:
> *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.

Long story short, *what* in the world needs some kind of in-memory file
virtualization, that could not be done better with the ultra-simple
concept of ArrayList? Why is there such a need for bytes, what are bytes
any use of?

In the Java World it is often the case that you do not want to work with
bytes, you merely write and read them on the boundaries of your program
to the external world. You'd usually work with structured data, and
therefore not keep bytes lying in-memory.
Still, it rarely makes anything more complex than it needs to be.
Everytime one feels it does, one should just question one's approach to
the task.
I spoke of ArrayList just as an example. Whatever the case is, someone
can probably point out a satisfactory way to address it. It might have
nothing to do with file virtualization, though.

--
Mayeul

Mayeul schrieb:
> I spoke of ArrayList just as an example. Whatever the case is, someone
> can probably point out a satisfactory way to address it. It might have
> nothing to do with file virtualization, though.

Well idea is not to change the original application which uses
already some byte serialization in a fundamental way. But only
to replace the temporary files by memory streams.

Of course one could opt for a total rewrite of the original
application, but then there is no guarantee that a non-byte
serialization gives a better design.

Also we cannot deduce from the requirement of an byte input /
output stream that the application deals with binary data. It
could be also that on top of the byte input / output stream
character reader / writer are created.

So that basically the application deals with character streams,
and maybe with something like documents or some such. It might
be that ArrayLists come into play when working with documents,
but only peripherically, for example JTextPane & Co.. there is
an array of elements involved which represent paragraphs.

But when you strip all the styles from JTextPane & Co you
get to the characters of the paragraphs. And XML / HTML shows
you for example how you can serialize characters and styles
into character streams.

Now again one could opt for working with a DOM instead of working
with streams. But in XML both options are viable and not alien
to Java. Sometimes stream based approaches are even more efficient
than DOM based approaches.

So be it as it is, the requiremets stands at it is, there is
the request for memory streams, despite possible alternative
designs. Just assume that among the variant designs, we currently
focus on memory streams and not something else.

Bye

Jan Burse wrote:
> So be it as it is, the requiremets stands at it is, there is
> the request for memory streams, despite possible alternative
> designs. Just assume that among the variant designs, we currently
> focus on memory streams and not something else.

Doesn't seem like this group has what you're looking for. The thread's gone on for a while with no movement on your rather narrow and close-to-the-vest requirements. I suggest expanding your search beyond Usenet.

GIYF. And it's faster, too.

--
Lew