v4 Events Lib - Major Version Change

[msailes]

The next major version of the aws-lambda-java-events library is now being worked on. As part of this we are considering changes around serialization. Our goals are to make it easier for customers to handle different serialization scenarios, reduce package size and to more easily add new events to the library.

Our current plans include enabling customers to bring their own serializer by implementing the PojoSerializer interface and including a provider-configuration file under META-INF/services.

To make it easier for new event objects to be added we are exploring ways to remove the use of mixins in the serialization library.

For example the SecretsManagerRotationEvent uses the SecretsManagerRotationEventMixin.java to change upper case attributes Step, SecretId and ClientRequestToken to lower case ones. This is required because Jackson expects lower case attribute names. Instead Jackson annotations will be added directly to the event fields which require them.

At this time we’ll also change the existing event objects to all follow the same design. Lombok annotations @Data, @NoArgsConstructor, @Builder(setterPrefix = "with"), @AllArgsConstructor and @Singular(when needed) will be added to events without them.

The joda-time dependency will be removed in this release.

[msailes]

@ilopmar, @olegz, @GoodforGod, @sdelamo, @FieryCod

[drissamri]

I'm not entirely aware on how the internals work right now. In my experiments around cold start performance I have always opted to use Jackson-jr instead of regular Jackson since it positively impacts the cold start. Now I use this, but internally ofcourse jackson regular is still being used so it's a double hit on performance.

Will this change make it possible to have internal serialization also leverage faster frameworks and be replace the current (slower) Jackson lib?

[sdelamo]

For a sample SQS event such as:

{
  "Records": [
    {
      "messageId": "19dd0b57-b21e-4ac1-bd88-01bbb068cb78",
      "receiptHandle": "MessageReceiptHandle",
      "body": "Hello from SQS!",
      "attributes": {
        "ApproximateReceiveCount": "1",
        "SentTimestamp": "1523232000000",
        "SenderId": "123456789012",
        "ApproximateFirstReceiveTimestamp": "1523232000001"
      },
      "messageAttributes": {},
      "md5OfBody": "{{{md5_of_body}}}",
      "eventSource": "aws:sqs",
      "eventSourceARN": "arn:aws:sqs:us-east-1:123456789012:MyQueue",
      "awsRegion": "us-east-1"
    }
  ]
}

I assume it Is currently working because you are using Jackson with

        mapper.configure(MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES, true);

https://github.com/aws/aws-lambda-java-libs/blob/master/aws-lambda-java-events/src/main/java/com/amazonaws/services/lambda/runtime/events/SQSEvent.java

If records is always Records in the JSON payload. It would be great if you could annotate with @JsonProperty. Replace:

public class SQSEvent implements Serializable, Cloneable {

    private static final long serialVersionUID = -5663700178408796225L;

    private List<SQSMessage> records;

with:

public class SQSEvent implements Serializable, Cloneable {

    private static final long serialVersionUID = -5663700178408796225L;

     @JsonProperty("Records")
    private List<SQSMessage> records;

We should not need to support case insensitive properties.

[graemerocher]

Please no lombok 🤢🤮

[msailes]

@sdelamo There is also a mixin for SQSEvent - https://github.com/aws/aws-lambda-java-libs/blob/master/aws-lambda-java-serialization/src/main/java/com/amazonaws/services/lambda/runtime/serialization/events/mixins/SQSEventMixin.java

[andclt]

@graemerocher What would you prefer?

[GoodforGod]

There is a good reason not to use lombok in libraries -> no source code compatibility, your decompiled Java code won't be compatible with the source code and IDEA would light red like Christmas lights, so probably that's better to generate getters\setters via IDEA manually from my point of view, but hell thats so much boiler plate for such library (lombok is ok in libs thats provides DTO from my point of view)

But when we are talking about library which whole purpose is to provide some kind of DTO, thats became debatable, standartization across whole code base (all lombok or all manual) from this stand point is good

I also thing that it's better to replace Lombok @builder with just @Setter & @accessors(chain = true) (if we are talking about Lombok)

As an example
https://github.com/GoodforGod/aws-lambda-java-events/blob/master/src/main/java/io/goodforgod/aws/lambda/events/ConnectEvent.java#L17

[driverpt]

What's the ETA on this ?

[driverpt]

@msailes ?

[msailes]

There is no ETA currently.

[driverpt]

@msailes , can you create a Milestone and group all the pending issues so we can also help?

[driverpt]

Can v4 have Java 11 as baseline ?

[driverpt]

Is there any branch with v4? So we can make contributions

[jeromevdl]

I can see lots of the events implementing Cloneable, what is the reason for this?

[driverpt]

Is there any ETA on this one ?

[sdelamo]

There are several issues for AWS Lambda Events which are problematic:

A) No JSON Schema.
B) No official JSON examples to use in a test compatibility kit.
We have to manually log some events to Cloud Watch and save those JSON examples. Copy/paste sample events from the console console events or search json files in your scattered through your repositories. Obviously, we miss a lot of scenarios.
C) No Java nullability annotations to indicate which fields are required and which are not. The lack of annotations hinders Kotlin interoperability and also custom serialization.
C) Poor or no Javadoc. It is important to document your API via javadocs. For example: what is a rawQueryString or what is inside Map<String, Object> lambda.
D) Remove the usage of Lombok. Generate equal/hashcode, getters, and setters with an IDE and use plain java. Add as much information in the javadocs of the getters/setters and fields so that your API consumer understands what those events represent.
E) Once you support Java 17 only, use records.

[gwwallace]

Any expected release date for v4 ?

[oxygenecore]

If you roll out this library to public, please do so responsibly. There is completely no justification of Lombok scrambling bytecode and all our stacktraces. Also, if this is future-proof is up to debate.
Java already solved the non-existent "too much to write" problem for pojos with records.

Not having schemas is the real problem though, as @sdelamo has pointed out. Is it upper case? lower case? required? optional? who knows?

[Sam-Bate-ITV]

please can v4 support JPMS by including a module-info.java in each jar. Using modular jars with jlink is great. It's a real shame that so few Java devs are embracing it.

[patrickjamesbarry]

2024 - any closer to an eta? If looking for elimination of boiler plate pojo getter/setters you could use java's new Record classes. Much preferred over lombok