Re: TeeOutputStream?
On 06/08/2011 03:31 AM, Henk van Voorthuijsen wrote:
On Jun 5, 2:17 am, Knute Johnson<nos...@knutejohnson.com> wrote:
I'm working on a project where I need to send the same data to two
OutputStreams so I went snooping around on the net for some code to
snatch. Most of the examples I found had what I think is a significant
flaw. That is if for example the write() method looks like this;
public void write(byte b) throws IOException {
os1.write(b);
os2.write(b);
}
if OutputStream os1 throws an IOException, no attempt to write the data
to os2 will happen. This probably isn't too big a concern for writes
but what about close()?
public void close() throws IOException {
os1.close();
os2.close();
}
If os1 throws an IOException on the close() method, then os2's close()
method will never get executed possibly leaving the stream open and the
attached resources still around. What about;
public void close() throws IOException {
try {
os1.close();
} finally {
os2.close();
}
}
This guarantees that both close() methods will get called. If both
methods throw IOExceptions the caller will never see the first one as it
will be hidden.
What do you think? Have I completely over thought this?
You might want to wait for JDK 7's "try with resources" feature. All
your concerns have been addressed there - im much more detail.
Java 7 is a long way off and I'm writing code today. That said, I do
like to use the latest stuff.
--
Knute Johnson
s/knute/nospam/
p it'll probably crash within
minutes and very possibly never ship. With Java and C# a mediocre coder
is much more likely to be able to release his poor code - humans being
humans, such a coder will blame the language for bloat and slowness and
errors.
If you run across a Java app that's a memory hog, why do you think it's
the fault of the language? It never occurred to you that it might be the
programmers? It's not like more than 25% (being charitable) of all
programmers working today should even be let near a keyboard, after all.
well, I think it actually partly goes both ways.
while many programmers do suck... both Java and C# implement things in
many cases, in ways which are fairly costly...
for example, in C, a string is just a glob of 8-bit characters in
memory, and so doesn't really take much more memory than the space to
store these characters.
in Java, a "String" is a class instance containing an array of 16-bit
characters...
just at the outset, this is a good deal more expensive (I calculated for
my own technology, reaching an approx 7x difference for the memory cost
of storing the string "Hello"). granted, the JVM may have a lower base
overhead, and it will drop and approach 2x as the string gets longer (a
lot of the overhead was mostly related to the cost of the object
instance and array headers).
but, even 2x is still a significant space overhead... (due to UTF-16 vs
UTF-8...).
also, there are many places internally where "new" will be used in
copious amounts due to the basic design of the VM architecture, ...
a lot of this is still likely not exactly free either, and a lot of this
may add up...
or such...
No argument from me, but in over a decade of working with Java I've yet
to see a "memory hog" bloated application that couldn't have been
improved to make it acceptable. Which means it could have been written
that way to start with.
Good design helps a great deal - minimize coupling and you minimize the
number of references that are held, keeping other objects around. Cut
down on object lifetimes by creating them when definitely needed, and
make sure they are cut loose as soon as possible after their usefulness
is done. Re-use immutable value objects when possible (flyweight), or
singletons - try to recycle. Use the right data structures. Use pools.
Understand GC and the Reference API.
Etc etc etc. Jack Shirazi's "Java Performance Tuning" book came out in
2000, and it ought to have been a must read for every Java programmer
from the gitgo. I wonder what percentage of Java programmers ever read
it. A lot of it still holds true; there's plenty other updated material
to cover newer Java.
AHS