JosiahGoeman

Gotcha. I have changed the behavior for XMLExporter to save the position in the referenced PR, so I'll need to revise that.

Wait, why did GitHub include the BufferAllocator commit from my previous pr? That commit is already in the target branch.

Yes, the files changed are correct.

Alright, I think this should be ready for review.

> > I'd guess that BinaryExporter maybe has some sort of check for that sort of dependency issue. > > The test succeeds with `XMLExporter` in v3.7.0-stable, which means there...

Looks like it was indeed that simple. And here I was thinking my test suite was so thorough. -_- I added a test for the reference-loop case.

I figured out the problem with BitSets. It looks like DOMOutputCapsule was writing the indices of each set bit in the BitSet similar to how BitSet.toString() works, but DOMInputCapsule was...

Also figured out why readString() was returning defVal for empty strings. [Element.getAttribute() returns an empty string when the attribute doesn't exist](https://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/Element.html#getAttribute_java.lang.String_). It looks like DOMInputCapsule was interpreting an empty string...

Is there any reason I shouldn't deprecate [DOMSerializer](https://github.com/jMonkeyEngine/jmonkeyengine/blob/d71feba8d312e26cec0a49cde68d1bb588f81454/jme3-plugins/src/xml/java/com/jme3/export/xml/DOMSerializer.java#L50) in favor of using [Transformer](https://docs.oracle.com/javase/8/docs/api/javax/xml/transform/Transformer.html)? DOMSerializer is only used by XMLExporter and it doesn't appear to be doing anything that can't be...

For the time being, I'm going to assume its OK so long as XML files written with the old version still load properly. Easy enough to revert if needed. More...