avro

AVRO-3186: Use consistent logic to find SpecificData by class (#1304)

SpecificDatumReader.SpecificDatumReader(Schema writer, Schema reader)
  -> SpecificData.getForSchema(reader)
     // It breaks if system class loader fails to load generated class,
     // thus returns an empty SpecificData.

SpecificDatumReader.readField()
  -> datum = readWithoutConversion(oldDatum, field.schema(), in);
     // conversion is null for union field
    -> GenericDatumReader.read(Object old, Schema expected, ResolvingDecoder in)
      -> Conversion<?> conversion = getData().getConversionFor(logicalType);
         // returns null wrongly

Without this patch, the unit test fails:

java.lang.ClassCastException: class java.lang.Long cannot be cast to class java.time.Instant (java.lang.Long and java.time.Instant are in module java.base of loader 'bootstrap')
	at foo.Bar.put(Bar.java:113)
	at org.apache.avro.generic.GenericData.setField(GenericData.java:826)
	at org.apache.avro.specific.SpecificDatumReader.readField(SpecificDatumReader.java:139)
	at org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:247)
	at org.apache.avro.specific.SpecificDatumReader.readRecord(SpecificDatumReader.java:123)
	at org.apache.avro.generic.GenericDatumReader.readWithoutConversion(GenericDatumReader.java:179)
	at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:160)
	at org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:153)
	at org.apache.avro.specific.TestSpecificData$1.run(TestSpecificData.java:75)

The separate class loader scenario probably happens in OSGi module and Java 9 module too.