This is split off from https://bugs.openjdk.java.net/browse/JDK-8144015 as the issue is sufficiently distinct from
all the others there

Pasting info from that original report :
The differences are very small and only in the visible advance.
java.version = 9-internal
Left-to-right (One style): Advance = 161.67188, Visible advance = 150.23633
Right-to-left (One style): Advance = 161.67188, Visible advance = 150.23438
MISMATCH in advance.. Right-to-left (One style): Advance = 161.67188, Visible advance = 150.23438, previous values were: [161.67188,150.23633]
Left-to-right (Multiple styles): Advance = 161.67188, Visible advance = 150.23633
MISMATCH in advance.. Left-to-right (Multiple styles): Advance = 161.67188, Visible advance = 150.23633, previous values were: [161.67188,150.23438]
Right-to-left (Multiple styles): Advance = 161.67188, Visible advance = 150.23438

ie for visible advance we have
LTR = 150.23633
RTL = 150.23438

Also note the text invokes fractional metrics .. if we turn that off then
as should be obvious integer rounding makes it a non-issue.

We can observe the difference with the text "A ".
The idea of the test was to see how RTL & trailing spaces affect the
logical and visual advance.
for the above case we get for visible advance :
LTR: 8.666016
RTL: 8.65625
Note that " " - text just containing spaces - correctly reports 0.0

The issue is that in the Harfbuzz code we take the floating point advance supplied by the font rasteriser
and convert it to a fixed point format needed by harfbuzz.
The format chosen is 26.6. Ultimately this gets converted *back* to floating point.

However the font data internally to the rasteriser (T2K) originally was 16.16 before it
was converted to floating point.
So the 26.6 format can lose some precision that is available in 16.16.
So when code in TexttLayout that wants the advance of SPACE gets that without
going via harfbuzz (ie it indirectly calls FontStrike.getGlyphMetrics(),which is *the same (internal) API*
that harfbuzz used to obtain the advance, it gets it without that loss of precision.

Arguably the test should be more forgiving. Exact comparisons of floats is often not what you want.
but in this case I think it may be possible instead to use 16.16 for harfbuzz too and perhaps get the
same results as we used to in previous releases as well as consistent results.