HollowObjectTypeMapper should not reflect on fields of JDK classes

[PaulSandoz]

The class HollowObjectTypeMapper reflects on a field of java.lang.String, the value field of the boxed primitive classes, and in general any JDK class that is given (e.g. BigDecimal). This is very fragile, since the name and type of a field can change and, in addition, the semantics of a field's value can also change. For example, in Java 9 the internal field of String holding the characters was changed from char[] to byte[] to support compact strings and the semantics were also changed. Those bytes could represent a Latin-1 or UTF-16. This resulted in a couple of bugs in Hollow.

HollowObjectTypeMapper mostly behaves correctly now. It accesses public methods of JDK classes String, Date and Enum to get values but it still reflectively accesses values from boxed primitives. The latter is fragile if the internals of boxed classes are changed (especially with Unsafe access). This might be a very small risk but there is a potential for change if these classes can be transformed, compatibility, to value classes (or in general for other JDK classes that can be transformed compatibility).

This may also be an opportunity to replace Unsafe access with MethodHandle access (subject to performance tests) and configurable access to other JDK types that can map to primitive components (such as BigDecimal or BigInteger).