fluidsonic/fluid-json

A JSON library written in pure Kotlin

fluid-json's Issues

Release first version

Check whether UTF-8 is properly handled

Split up into multiple libraries

• separate tests
• properly define auto-closing of streams
• clean up API
• decide on final library naming
• double-check Gradle project configurations
• double-check test setup
• double-check Travis CI setup
• set up Maven Central publishing

Pass KClass which triggered a decoder codec to its decode method

allow skipping encoding of default values (null, zero, empty string, empty list, etc.)

Improve performance by operating on InputStream/OutputStream

Add own parser testing & maximize coverage

Unify exception messages to start uppercase

Annotation-based preprocessor for automatic codec creation

• implementation
• unit tests
• documentation

Add extended set of standard codecs (e.g. for java.time)

Add stream-based parser and serializer (like MongoDB Java Driver)

• Decide whether to treat map keys as values or whether to add special token type and readKey() method
• Parse double directly without temporary string.
• Add tests for character indexes in exception messages.
• Add tests for keypaths in exception messages.
• Should we wrap IOException, InterruptedException (all Exceptions?) in JSONException?
• Serialize numbers without temporary string.
• Improve performance by using Input/OutputStream directly.
• Support Appendable.
• Support Readable.
• Support reading & writing Byte and Short.
• Support reading & writing Char.
• Allow peeking whether next number has decimal point or exponent in JSONReader.
• Properly close readers & writers in tests.
• Add overloads for readString and writeString which operate on CharArray and alike.
• Add options (e.g. handling of unserializable values, max nesting, max number length, max string length)
• Add dedicated tests for TextInput.

Wrap (some) other throwables in JSONException

If it makes sense. An for what throwables?

Check that multiple upper bounds of generic type parameters are checked by decoder codecs

Ensure that codecs operate solely on value boundaries

Add performance testing

Add codecs for direct object <-> JSON conversion (like MongoDB Java Driver)

• Add checks to make sure that no coder messes up the node hierarchy.
• Properly plan en-/decoding of map keys.
• Add encoding/decoding functionality for map keys.
• Add extended standard codecs, e.g. for java.time.*

Parser/Serializer not always non-recursive when expected

Resolution of Int -> AnyJSONCodec can't work for decoding.

InstantJSONCodec should use number, not string

Finalize all public API

Add standard decoders for array types

Add serializer testing

add @JSON.Codec to add manual codecs to generated provider

Add abstract base classes for codecs to simplify setup

Properly support Java 9 … 11

• Java 9
• Java 10
• Java 11

Add KDoc to all public API

Add Travis CI

Add documentation

Polymorphism support

sealed class Shape
class Circle(val radius: Double) : Shape
class Rectangle(val width: Double) : Shape

There are 2 types of polymorphism:

1. Polymorphism by field value, aka discriminator
   1.1 Discriminator embedded in object

[ { "type": "CIRCLE", "radius": 10.0 }, { "type": "RECTANGLE", "width": 20.0 } ]

1.2 Discriminator external

[ { "type": "CIRCLE", "data": { "radius": 10.0 } }, { "type": "RECTANGLE", "data": { "width": 20.0 } } ]

2. Polymorphism by filed name, aka union, or anyOf from Swagger

[ { "radius": 10.0 }, { "width": 20.0 } ]

Because only Circle class has radius field, first object from list will be deserialized in Circle class.

Also should be possible to do nested deserialization(multi level).

Please add support for all this cases.

Add pretty serialization

Add function to parse StringStream

Add a codec for enums

Add low-level support for BigDecimal / BigInteger

Add proper README

Add support for Validation

Usually on deserialization we want to collect all validation errors and return them in response to the client.
In order to catch all error the validation should be done before object creation.

If it will be done after object creation, in init block, than validation will be separated in 2 phases, first one will be validation regarding non-nullable field, because we cannot create objects if they have non-nullable properties.
The second one will be to do structural validation: min/max values, length, regexp pattern, etc.

Example
class Data(val name: String, val age: Int, val email: String)
when we send a json {"email": "[email protected]", "name": "A"} we should return a response where to indicate that age can not be null and name size must be greater than 2, at once to send all the errors.

Also, structural validation will be great to do based on annotations and not in init block, something like JSR 303.
This will be useful for documentation generation, it is far easier to generate based on annotations.

How I see the flow:

1. Read annotations and generate validation rules. Can be done by 3rd party library. As result Map<Class, List>
2. Parse json as a map
3. Apply validation rules. Validation rules can be passed as parameter in configuration.
4. Create object

fix codec generation for properties whose type references a generic type of the value class

@JSON
class ClientCommand<out Result : Any>(
    val resultClass: KClass<out Result>
)

@JSON
class ClientCommandRequest<out Result : Any>(
    val command: ClientCommand<Result>
)

Add Codecov