JSONObject consider using LinkedHashMap

[agentgt]

For my library it is preferred to maintain the order found of object fields. The current implementation of JSONObject uses a HashMap instead of a LinkedHashMap and thus order is lost and is not predictable.

[Synt4xErr0r4]

Hey, thanks for the suggestion.
I might add that feature next update. I don't know if using LinkedHashMap over HashMap has significant effects on performance, so I'll have to investigate that first.

[agentgt]

I ported your code into my project. I removed a lot of what I did not need, used sealed classes, pattern matching, add jspecify annotations etc.

https://github.com/jstachio/ezkv/tree/main/ezkv-json5/src/main/java/io/jstach/ezkv/json5/internal

I found kind of some bugs or just missing stuff dealing with top level parsing.

For example nextClean never returns 0 (instead it throws exception) which is kind of needed for top level parsing to make sure the json5 document is valid.

There were a couple of places you did not use syntaxError in JSONParser.

I realize a lot of the API is to mimic the "org.json" parser but with modern Java I really do not think you need the hundreds of ergonomic lambda methods.

Regardless the JSONParser of all the JSON5 java implementations I looked at was the easiest to understand!

Feel free to steal some of my not really unit tests tests (I needed more end to end in case I change parser which is unlikely). I only got like 80% coverage because as some of the floating hex stuff is still in.

EDIT

I might add that feature next update. I don't know if using LinkedHashMap over HashMap has significant effects on performance, so I'll have to investigate that first.

I highly doubt it would ever be a performance issue because:

• JSON5 is more of a configuration format for humans and not a networking interchange format
• There are so many other things that are probably more of a bottleneck and the fastest json parsers do crazy stuff. In fact I think the fastest parsers maintain order for small datasets but don't quote me on that.

I actually was going to put the location information in my newer JSONValue sealed types as config location is useful for humans (e.g. this value came from this line).