Why Does XMLEncoder Call Its Instance's Getter Twice?

As I understand it, XMLEncoder requires a no-argument public constructor within the class of object it is asked to encode. It needs this so it can create an instance to compare with the object it is actually going to write, so as to avoid writing default property values. If my understanding were correct, I would expect the getter for each property being written to be called once for the object being written, and once for the object XMLEncoder creates for its comparison. But, in my tests, it appears that XMLEncoder calls the getter for its internally created object twice. Here's my top-level routine:

And here's my Doc class (the class that will be encoded):



At run-time, here's my output:

That makes perfect sense to me, except for Line 04. Why would XMLEncoder make a second call to the same getter in the instance it created? I don't need this for any particular application; I'm just trying to get a firm grip on the operation of XMLEncoder. Most of it makes sense, but this is kind of baffling.

If you really want to know, you'd have to look at the source code of XMLEncoder. You'll be able to find the source code in the file src.zip in your JDK installation directory.

However, why are you so interested to know why it does this? All that's important for you when you use XMLEncoder is that it does what its documentation says it does. How exactly it does that shouldn't bother you. Also, how it exactly works is not specified anywhere, and in a different version of Java it might work differently. Maybe in some future version of Java the implementation is changed and it will call your getter method only once, or maybe three times, or any other number of times. It doesn't matter, as long as XMLEncoder does what its documentation says it does.

Getter methods should be idempotent (they should return the same result every time you call them and not have any side effects), so it shouldn't matter how often XMLEncoder calls them.

Jesper de Jong wrote:...why are you so interested to know why it does this?

Because I'm a nosey little busy-body who can't leave well enough alone.

Getter methods should be idempotent (they should return the same result every time you call them and not have any side effects), so it shouldn't matter how often XMLEncoder calls them.

I had speculated that the second call was involved in some kind of test to see if my getter adhered to this, so I've spent some time trying to make it as non idempotent (aliterpotent? mutaripotent?) as possible. Doesn't seem to make any difference.

Stevens Miller wrote:I had speculated that the second call was involved in some kind of test ...

If you lookup the source code of XMLEncoder, or if you use a debugger and step through the code to see what exactly it does, you wouldn't have to speculate anymore...

Jesper de Jong wrote:

Stevens Miller wrote:I had speculated that the second call was involved in some kind of test ...

If you lookup the source code of XMLEncoder, or if you use a debugger and step through the code to see what exactly it does, you wouldn't have to speculate anymore...

Yeah, I should do it. When I trap the calls to the getter, the call stack is about fifty levels deep. Would be a bit of an exercise but, in the end, will probably be the only way to find out what I'm after.
There's no src.zip in my jdk1.8.0. Were you referring to OpenJDK, or is there another source of the source?

Stevens Miller wrote:There's no src.zip in my jdk1.8.0. Were you referring to OpenJDK, or is there another source of the source?

Then maybe when you installed the JDK, in the installer you indicated that you didn't want to install the sources. The sources for the standard library classes are included in the normal Oracle JDK.

I just downloaded JDK 1.8.0_05 and there it was. You get it by default and I never fuss with the installation defaults, so maybe my prior JDK was from somewhere else (NetBeans, maybe?) and it didn't include the source.

Thanks, Jesper.