Jesper de Jong wrote:I would say that it isn't really good design if a class that doesn't "own" the OutputStream closes it for you. Note that Java's standard library isn't always the greatest source for examples of good class design - some of the classes in the standard library have horrible design mistakes.
You know, that is very heartening to read. I tend to think the standard library is pretty impressive, and my Java is always getting better, so I am reluctant to conclude that the library code isn't perfect. But, sometimes... well, you just find things you think aren't what they should be. Glad to know I may not always be wrong about that.
On the other hand, why would you want to write anything to the OutputStream after XMLEncoder has written a complete document to it? There should normally not be any data after the closing tag of the root element of the XML document.
Like I said, I'm just debugging things. None of this is for production purposes. I've been comparing/testing a variety of ways to use XMLEncoder, all of which should produce the same output. If they don't, I know at least one of them has a bug. Rather than write to files and open them over and over, it's just easier to have it
spray all that XML directly onto my screen.
Replacing all calls to XMLEncoder's close with calls to its flush method is working. (In production, I may end up using try-with-resources, which will close the stream for me; that should work too since, as you point out, it is senseless to write anything after the root element.)