aws / aws-lambda-java-libs

Official mirror for interface definitions and helper classes for Java code running on the AWS Lambda platform.

Home Page:https://aws.amazon.com/lambda/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bug: JSON serialization ignores fields from child classes (Java 8 Lambda runtime works, Java 11 Lambda runtime fails)

Dretch opened this issue · comments

I noticed this issue when updating my lambda function from Java 8 to Java 11, and it seems to be related to the code in this repository.

The problematic situation occurs when a lambda function declares that it returns TestParent, but actually returns an instance of TestChild:

  public class TestParent {

    public String parentField = "parentField";
  }

  public class TestChild extends TestParent {

    public String childField = "childField";
  }

To reproduce the issue, please run the attached test case (maven project): aws-lambda-json-child-field-bug.zip

It should fail with an error like below:

org.junit.ComparisonFailure: 
Expected :{"parentField":"parentField","childField":"childField"}
Actual   :{"parentField":"parentField"}

You can see that the fields from TestChild are missing. This is the issue, and this seems to be new -- in the Java 8 lambda runtime this worked ok.

Thanks for any help!

Hi @Dretch,

I tried your sample and I couldn't get it to pass with Java 8. Could you provide a sample which is passing.

Thanks,

Thanks for looking @msailes

The issue does not seem to be Java 8 vs Java 11 per-se, but rather the Java 8 lambda runtime vs the Java 11 lambda runtime. So I am not expecting the test to pass simply using a Java 8 JRE.

I'm not sure if the code in this library even existed in the Java 8 lambda runtime, but nevertheless the code in this library does behave differently to the equivalent code in the Java 8 runtime.

I have created a proof-of-concept that shows how the Java 8 runtime works but the Java 11 runtime does not: https://github.com/Dretch/java-11-lambda-missing-fields-poc (see project README).

Hopefully this helps to investigate the issue.

Hi @Dretch,

You are correct, there is a difference between the two versions in this case. The fix would be to use the child type instead.

Thanks.

Hi @msailes ,

Unfortunately in my real application there is more than one child type, and which type will be used is not known until runtime - so it is not possible to statically declare the child type.