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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#10316

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

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

#10319

On Tue, 29 Nov 2011 00:22:48 +0100, Jan Burse <janburse@fastmail.fm>
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

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

#11764

On 11/28/2011 6:22 PM, 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
> forum, so when somebody posts a solution here everybody
> profits from this, not only eventually me.

It happens all the time that people ask for help
with implementation of solution XYZ while there is another
solution ABC that is a much better solution
for the problem to be solved.

Picking the right solution is the difficult part and
implementing it is the easy part (if it is a good
solution).

The interest in helping implement XYZ when poster
will not reveal what problem is being solved is not
particular attractive, because the chance that XYZ
is optimal is very small.

Arne

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

#11802

Arne Vajhøj schrieb:
> On 11/28/2011 6:22 PM, 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
>> forum, so when somebody posts a solution here everybody
>> profits from this, not only eventually me.
>
> It happens all the time that people ask for help
> with implementation of solution XYZ while there is another
> solution ABC that is a much better solution
> for the problem to be solved.
>
> Picking the right solution is the difficult part and
> implementing it is the easy part (if it is a good
> solution).
>
> The interest in helping implement XYZ when poster
> will not reveal what problem is being solved is not
> particular attractive, because the chance that XYZ
> is optimal is very small.
>
> Arne
>
>

Well I can assure you, the memory
streams are not used to wipe your ass.

If you post more of this narrow minded
stuff, I might get injured from laughing...

Bye

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

#11820

On 2/7/12 12:59 AM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>> On 11/28/2011 6:22 PM, 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
>>> forum, so when somebody posts a solution here everybody
>>> profits from this, not only eventually me.
>>
>> It happens all the time that people ask for help
>> with implementation of solution XYZ while there is another
>> solution ABC that is a much better solution
>> for the problem to be solved.
>>
>> Picking the right solution is the difficult part and
>> implementing it is the easy part (if it is a good
>> solution).
>>
>> The interest in helping implement XYZ when poster
>> will not reveal what problem is being solved is not
>> particular attractive, because the chance that XYZ
>> is optimal is very small.
>>
>> Arne
>>
>>
>
> Well I can assure you, the memory
> streams are not used to wipe your ass.
>
> If you post more of this narrow minded
> stuff, I might get injured from laughing...
Only a fool calls his teacher foolish.  There is nothing narrow minding 
about Arne's post. There is however close-mindedness in your own reply.

Engineers look over the most solutions, and choose the ones that work 
"best" (where "best" is situational).  Often times, not having to 
implement potentially tricky algorithms is a good start. As well as not 
having to refit existing API's to support a different mode of operation.

If, as an engineer, you decide XYZ is the right solution, but need help 
finding how to implement XYZ, it is often a good idea to explain how and 
why you came to your conclusion.  Either you'll get second opinions on 
other approaches you might not have considered, or you'll get agreement 
and instantaneous help on XYZ.

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

#11842

On 2/7/2012 3:59 AM, Jan Burse wrote:
> Arne Vajhøj schrieb:
>> On 11/28/2011 6:22 PM, 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
>>> forum, so when somebody posts a solution here everybody
>>> profits from this, not only eventually me.
>>
>> It happens all the time that people ask for help
>> with implementation of solution XYZ while there is another
>> solution ABC that is a much better solution
>> for the problem to be solved.
>>
>> Picking the right solution is the difficult part and
>> implementing it is the easy part (if it is a good
>> solution).
>>
>> The interest in helping implement XYZ when poster
>> will not reveal what problem is being solved is not
>> particular attractive, because the chance that XYZ
>> is optimal is very small.
>
> Well I can assure you, the memory
> streams are not used to wipe your ass.
>
> If you post more of this narrow minded
> stuff, I might get injured from laughing...

I think it requires an unusual understanding of "narrow"
to consider looking at other possible solutions to be
narrow minded.

Arne

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

#11847

Arne Vajhøj schrieb:
> I think it requires an unusual understanding of "narrow"
> to consider looking at other possible solutions to be
> narrow minded.
>
> Arne
>

Well with your attitude you would not be
fit to implement against a specfication.

Which means you would not be fit to work in
a large team where contract based
components are built.

Because of your relentless stupid asking
you would not be able to write one single
code of line.

My specs were and are pretty clear...

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

#11855

In article <jgtd9s$lta$1@news.albasani.net>,
 Jan Burse <janburse@fastmail.fm> wrote:

> Well with your attitude you would not be
> fit to implement against a specfication.

Some specifications are better than others:

<http://geekfun.pl/pm_build_swing.gif>

Thank you for reminding me how much I value the critical feedback of my 
colleagues and my manager's diligence in fostering peer review. I shall 
bring baked goods to my next meeting.

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

#11857

John B. Matthews schrieb:
> In article<jgtd9s$lta$1@news.albasani.net>,
>   Jan Burse<janburse@fastmail.fm>  wrote:
>
>> Well with your attitude you would not be
>> fit to implement against a specfication.
>
> Some specifications are better than others:
>
> <http://geekfun.pl/pm_build_swing.gif>
>
> Thank you for reminding me how much I value the critical feedback of my
> colleagues and my manager's diligence in fostering peer review. I shall
> bring baked goods to my next meeting.
>

The cookies will not make the people who should
understand or feedback on the spec more intelligent.
See what happended in this thread. I wrote:

On 11/26/2011 6:10 AM, Jan Burse wrote:
 > 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.

Then this clever guy who will never be able to code
or suggest solutions wrote:

On 02/07/2012 2:59 AM, Arne Vajhøj:
 > Given that memory/available address space is
 > bounded then what you can store in memory will
 > be bounded no matter what.
 >
 > You will just need to code to handle it.

Was this a reminder from theoretical computer
science that we deal with finite machines, or
what? Thats new to me. (no)

Looks smart, but is just this relentless stupid
asking and commenting that would allow to expell
any person in some peer reviewer postion from the
team for fooling around and not working.

Bye

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

#11859

On Wed, 08 Feb 2012 20:23:17 +0100, Jan Burse <janburse@fastmail.fm>
wrote:

[snip]

>Looks smart, but is just this relentless stupid
>asking and commenting that would allow to expell
>any person in some peer reviewer postion from the
>team for fooling around and not working.

     What team?  Ask a question, and you go antago.

Sincerely,

Gene Wirchenko

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

#11858

On Wed, 08 Feb 2012 12:18:09 -0500, "John B. Matthews"
<nospam@nospam.invalid> wrote:

>In article <jgtd9s$lta$1@news.albasani.net>,
> Jan Burse <janburse@fastmail.fm> wrote:
>
>> Well with your attitude you would not be
>> fit to implement against a specfication.
>
>Some specifications are better than others:
>
><http://geekfun.pl/pm_build_swing.gif>
>
>Thank you for reminding me how much I value the critical feedback of my 
>colleagues and my manager's diligence in fostering peer review. I shall 
>bring baked goods to my next meeting.

     Bagels with cream cheese are good, too.  Have them cut into
quarters so they are easy to handle and less likely to make a mess.

     I, too, appreciate good peer review.

Sincerely,

Gene Wirchenko

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

#10321

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

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

#10323

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

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

#10326

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

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

#10333

On Tue, 29 Nov 2011 14:37:48 +0100, Jan Burse wrote:

> 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.
>
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?
 


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

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

#10334

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.

The memory stream should work like a >>TEMPORARY FILE<<,
than can be opened, and thus shared by multiple readers
and writes. And the readers and writers should be able
to perform a seek() in any direction if desired.

Bye

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

#10336

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.


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

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

#10338

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.

Remember requirement is something along:

     class MemoryStream {

          InputStream createInput();
          OutputStream createOutput();
	 ...

     }

     class MemoryInput extens InputStream {
          ...
     }

     class MemoryOutput extens OutputStream {
          ...
     }

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

#10340

On 11/29/2011 1:59 PM, Jan Burse wrote:

> 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 sa


OK, I'll throw myself on this grenade.

<http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayInputStream.html#ByteArrayInputStream%28byte[]%29>

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

#10346

In article <jb3l16$ork$1@dont-email.me>, markspace <-@.> wrote:

> On 11/29/2011 1:59 PM, Jan Burse wrote:
> 
> > 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 sa
> 
> 
> OK, I'll throw myself on this grenade.
> 
> <http://docs.oracle.com/javase/7/docs/api/java/io/ByteArrayInputStream.html#ByteArrayInputStream%28byte[]%29>

This related example uses an in-memory byte stream to transport 
character encoded data:

<http://groups.google.com/group/comp.lang.java.programmer/msg/4f6eab3230444531>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web