FULL PRODUCT VERSION :
1.8.0_20

ADDITIONAL OS VERSION INFORMATION :
Windows 7 64bit

A DESCRIPTION OF THE PROBLEM :
Between version 1.8.0_05 and 1.8.0_20 a change was made to XMLEntityScanner to consolidate notifications into the load method. After deugging some corruption problems withing this class I was able to determine that the new logic introduces a bug. The change was made in many places but below is an example of code before the code change :

LINE:548
if (fCurrentEntity.position == fCurrentEntity.count) {
    invokeListeners(1);
    fCurrentEntity.ch[0] = (char)c;
    load(1, false);
}

Invoking the listerners before any changes to the buffer is important because listeners iterates through attributes that are currently being read and fixes their value. Up to this point there value is an ofset and length into the buffer which is about to be replaced.

After the code change the code looks like this:

LINE:540
            if (fCurrentEntity.position == fCurrentEntity.count) {
                fCurrentEntity.ch[0] = (char)c;
                load(1, false, true);
            }

This code changes the first character of the buffer, before the listeners are invoked which means any attributes with data at the begining of buffer is now corrupted.



ADDITIONAL REGRESSION INFORMATION: 
The bug is not present in 1.8.0_05

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Unfortunately I am struggling to create a test file other than our own (which I cannot share). It only happens in a very specific scenarios where the buffer is re-loaded and the first character in the buffer is actually used.


REPRODUCIBILITY :
This bug can be reproduced always.