Events v4 serialization v2

[andclt]

Issue #, if available:
#282

Description of changes:
Initial implementation of Events V4 and Serialization V2

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[driverpt]

How will translate when GraalVM is applied? Will it still use reflection?

[andclt]

From 1.0-RC8:

The native image generator now has automatic support for services loaded using ServiceLoader. All service implementation classes, listed in the META-INF directory, are available automatically as soon as the service interface is used. This eliminates the need to manually register resources and reflection support for such classes. The automatic registration can be disabled with the -H:-UseServiceLoaderFeature option.

[driverpt]

What is this for ?

[andclt]

In order to serialize Void as not null.

[driverpt]

Can you give me an example ?

[andclt]

Sure, a specific test for it was created https://github.com/aws/aws-lambda-java-libs/blob/c1685c79742aae77609d9dd1beb38f214a0664b1/aws-lambda-java-serialization/src/test/java/com/amazonaws/services/lambda/serialization/JacksonPojoSerializerTest.java

[driverpt]

I'm still trying to understand why you need the Void type. Is there any real-world example?

[AdamBien]

I reviewed the recent changes / diffs. Built-in Java libraries, like e.g. java.time reduce the complexity and make maintenance easier.
Lombok is controversial - essentially, lombok is a code generator, so the coupling is tighter and the dependency more critical.
I prefer JSON-B / JSON-P for json handling - however, Jackson can be also considered as "quasi" standard.

[GoodforGod]

1. Standardization is definitely what was missing and its good that it is coming in v4. Nice that code base become consistent.

2. Lombok in this type of library in my opinion is okay (only Java 11+), cause the whole purpose of library is to provide DTO, lombok allow for easier source code reading for developers and allow devs to maintain library easier, win-win.

3. Ability to instantiate it via new Event(), new Event(constructor ... args), lombok builder, static builders, DTOs are mutable even there is builder.. kinda messed up for DTO library, too many API for the same purpose.

Data annotation with Accessors(chain = true) is more than enough in my opinion.

4. Jackson as a first citizen serializer is not a good way for a DTO library. Cause now lib is incompatible with other serializers at this point (GSON for example). It should be then aws-jackson-events library to point directly that it is jackson focused lib or support all types of serializers by proper field naming where it is possible.

5. Removing joda-time is a way to go, should be done like starting when Java 8 was out, but thats better late than never. In my opinion it is better to serialize time into ZonedDateTime and not Instant with force UTC time conversion, cause that's not what users expects.

6. Keeping clone interface compatability for v4 is not the way to go in my opinion, v4 is a Major version so thats okay if there are breaking changes (devs should expect that), so clone methods should be removed.

7. Some events when created initialize new collections, like new ArrayList() in their contractor or field based immediately on instantiation, collection will prob be fully replaced by serializer so this just generates garbage at this point, can be cleaner up.

Here is some feedback and my thoughts on this topic 🙃