rsmogura / picoson Goto Github PK

Add @JsonEntryPoint annotation to expose methods to read and write JSON files as a public methods.

The current public methods jsonRead and jsonWrite should be generated only when this annotation is present on class.

The internal methods #jsonRead and #jsonWrite should be generated as is.

Analyze of properties to be done using javax.lang.model so it will be easier to switch to byte code transformer, as we can pass the actual type and element there.

Move PropertyCollector to generator-core package.

We had good results with replacing Lists by an array. It could be worth to validate performance by replacing the getters in JsonPropertyDescriptor by public final fields (unfortunately Java records were not introduced in JDK 8).

This change would require changes in generator code (mainly for #json(Read|Write) methods)

The POC could focus on readPropertyIndex, writePropertyIndex, jsonPropertyName as those are most used properties.

If the results will bring major performance improvements other classes JsonObjectDescriptor can use this strategy, too.

When property is present in JSON, but not in Java class the error is raised (the code is still in early development phase)

During transformation of existing classes, max locals and stack is computed for methods parsed by ASM ClassReader. This is not needed, as generally methods are not transformed, but only new methods are added. As this involves pseudo interpreter embedded in ASM it's a performance impact.

1. Don't use the automatic computation of stack and locals size.
2. For the newly generated transformed method, calculate those values depending on generated code and hardcode in code.

• The main method should iterate over properties in descriptor and call #jsonWriteProp for every property
• The semantics for #jsonWriteProp should be similar to the read method:
  • returns true if property has been handled, false otherwise;
  • investigate if property should be handled by this class (or extract to separate ticket for class inheritance support);
  • read value of filed and call appropriate method from JsonWritter
• Add JSON writer
• Create write benchamarks

• Boolean
• Byte
• Short
• Integer
• Long
• Float
• Double

In current POC all classes are transformed to add JSON support. It's probably not the most expected behaviour and it comes because the listener added in ATP handles all generated classes.

1. The byte-code class transformer should check if the given class should be transformed by analyzing annotations present on class (and or field), then in visitEnd method methods should be added.
2. This behaviour should be described in the documentation.

Support for reading Lists.

private List<String> list;
private ArrayList<String> list;
private List<String> list = new ArrayList<>();

AC:

• when the type of list can't be determined use ArrayList
• when the type of list can be determined use default constructor to create this type of list;
• consider embedding reader in API.

Allow reading of arrays.

Right now searching for properties by id is plain if-else-if-else-if. This is not the most performant approach (can be seen on benchmarks).

This can be replaced by binary search or tableswitch byte code (to use tableswitch ensure there's no gaps in properties ids, and add it to tests documentation).

The code generating this if-else-if tree is located in PropertyAbstractGenerator.generate method.

Note: we don't use references (method handlers, reflections), as reflection is more slower, and there's no good support for it in Graal

Right now method JsonObjectDescriptor.getProperties returns array of JsonPropertyDescriptor. This is not most secure as even if JsonPropertyDescriptor is immutable the array is not, and when "leaked" the descriptors can be replaced.

The solution could be store descriptors as linked list of references with the next filed (classic linked list).

This is idea has a low priority as the actual descriptors are not intended to be available from code, and if someone already played with reflection, to get descriptors even if the values will be final those always can be changed.

Right now during serialisation property name is passed to JSONWriter.name(). In the background this method adds " and checks the value if it should be escaped.

We could make such checks during class transformation or initialisation of descriptors, and if no escaping is needed, property contains only ASCII characters (probably 99% of cases) we could store cached and safe version of property in additional field.

Then we could extend the JSONWriter with new method jsonProperty which will require quoted property, to be written (no additional checks will be performed) - it would be similar to jsonValue. Additional changes in writeDeferredName would be required if property name has been passed as normal or as jsonProperty.

This could increase performance as no char-by-char checking of property name would be required in the call chain JsonWriter: writeDeferredName -> string.

Cons:

• Memory footprint increase as for every property (99%) it's safe version will be kept in memory (mitigation to only store mark if property is safe).

Memory size increase: 100 classes * 15 properties each * 15 chars lengths ~ 30KB of memory.

Compilation & annotation processing of nested classes causes an error.

The error is because PicosonTransformJavacTaskListener never handled properly flat name of nested class, and in turn reads not existing class file from FileManager

Add a 3rd argument to existing #json methods - the context (can be separate context for read and write).

Add support for detecting cycles using context methods - i.e. add method writeStarted, and internally within the context implementation store the objects on identity set to detect cyclic references.

The context should be a part of API.
There should be default way to create context which should be a part of API
This is only proposition how to solve issues of detecting cyclic references.

Profile Picoson benchmarks to find any performance issues (especially during writing which looks like it's only bit faster)

• The main method should iterate over properties in descriptor and call #jsonWriteProp for every property
• The semantics for #jsonWriteProp should be similar to the read method:
  • returns true if property has been handled, false otherwise;
  • investigate if property should be handled by this class (or extract to separate ticket for class inheritance support);
  • read value of filed and call appropriate method from JsonWritter
• Add JSON writer
• Create write benchamarks

Make reading properties optional.

If property is in JSON but not in class add an ability to skip it, this could be controlled by deserialization context passed as argument to function.

During static initialization of class add a given class and JSON support object to the global static map.

According to JVM class initialization should happen before first use, so it could happen (but it's not clear from specification) in the following situation

Json.read(UserData.class, reader);

Json support class should be a lean class giving basic proxy support for reading and writing classes:

class UserData#JsonSupport extends JsonSupport<UserData> {
  UserData read(JsonReader reader);
  //....
}