Project fine-tuning and updating

The Gradle build script has been refactored and optimized to make it easier to use for newcomers Fixed unnecesary publish behavior in build tasks

A @Data annotation would be put in the class and automatically put @Serialize on every field. This saves a lot of boilerplate and makes records be way more manageable

Add support to mark certain getters as needing to be serialized. Combined with #14 this could allow interfaces to be serializable (without the need to register a custom serializer) eg:

sealed interface Value{
  @Serializable
  int getValue();

  @SerFactory
  static Value of(int i){
    if (i == 0) return Zero.INSTANCE;
    if (i % 2 == 0) return new Even(i);
    return new Odd(i);
  }

  class Zero implements Value{
    private Zero(){}
    public int getValue() { return 0; }
    public Zero INSTANCE = new Zero();
  }

  class Odd implements Value{
    private final int value;
    private Odd(int value){ this.value = value; }
    public int getValue() { return this.value; }
  }

  class Even implements Value{
    private final Value base;
    private Even(int value){ this.base = Value.of(value >> 1); }
    public int getValue() { return this.value.getValue() << 1; }
  }
}

eg

class Foo<T>{
  @Serialize public T t;
  public Foo(T t){
    this.t = t;
  }
}

class Bar extends Foo<String>{
  public Foo(String s){
    super(s)
  }
}

A very big part of hyphen is missing, and it is the codegen. We need to create a good and scalable bytecode side of hyphen where is it easy to create byte code while still having access to the low-end stuff in case we need to do anything extreme.

Example:

SuperType: java.util.List<T>
Type java.util.ArrayList<java.lang.Integer>

Because ArrayList<E> implements List<E> (indirectly), T should resolve to java.lang.Integer

Would this be default or would it require an annotation on the class? Could be default on if the base class is abstract / is an interface, but this could conflict with #14, #15 or custom serializers

Without a @SerSubclasses a variable can be any subtype, (it will just get deserialized to the subclass unless we implement #14) but once the annotation is added, equality checks are done on the field.getClass() meaning subclasses will fail to get serialized properly.

This could be solved by using instanceof checks instead (or even use the java 17 preview feature to pattern match, if available). However this means we do need to sort the the classes (*) so that super classes are always checked before sub classes.

(*) This could however form a problem with #14 and #15, but even with custom serializers registered for interfaces, one could provide two interfaces as possible subclasses, and an object might implement both interfaces, which would complicate the sorting process.

Allow something like this

class Foo<T>{
  private final int hash;
  @Serialize
  private final T t; 

  private Foo(int hash, T t){ ... }

  @SerFactory
  public static Foo<T> of(T t){ ... }
}

It could be useful to allow any subclass for a given field.

This would work by first encoding the class name, and then using the serializer for that class. When decoding, the string is read, and a dynamic lookup for the deserializer is done. It might also be beneficial to also store the hashcode into the field too to speedup the lookup.

This could then also be extended to functional interfaces, allowing any static method reference to be selected as a lambda.

None of these seem to work:

public @SerSubclasses({Foo.class, Bar.class, Foo2.class}) Foo<@SerSubclasses({Integer.class, Float.class}) Number>[] numbers;
public Foo<@SerSubclasses({Integer.class, Float.class}) Number> @SerSubclasses({Foo.class, Bar.class, Foo2.class})[] numbers;
public Foo<@SerSubclasses({Integer.class, Float.class}) Number> @SerSubclasses({Foo.class, Bar.class, Foo2.class}) numbers[];