Add metadata to getMacroProps function

[JamzTheMan]

Fixes #872

Also changed json to build from LinkedHashMap instead of HashMap so json output now matches the insert order of the objects for a cleaner output that can be controlled.

---

This change is 

[cwisniew]

Fixes #872

Also changed json to build from LinkedHashMap instead of HashMap so json output now matches the insert order of the objects for a cleaner output that can be controlled.

This change is 

After the JSON update in progress there is no guarantee this will continue to be the case. GSON is less featured than the current json library and there is no way to control this (plus you shouldnt rely on ordering of fields in json objects)

[cwisniew]

Reviewed 1 of 1 files at r1.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @Phergus)

[JamzTheMan]

I swore I ran spotlessApply... ug...

Also, not sure why IntelliJ is saving in a different format when I imported the Java Google code specs...

[JamzTheMan]

Fixes #872
Also changed json to build from LinkedHashMap instead of HashMap so json output now matches the insert order of the objects for a cleaner output that can be controlled.
This change is 

After the JSON update in progress there is no guarantee this will continue to be the case. GSON is less featured than the current json library and there is no way to control this (plus you shouldnt rely on ordering of fields in json objects)

If it sticks it sticks, if not, no big deal. There's no "reliance" needed, it's simply makes for a nicer output in chat using json.ident. 😄
It would be nice if GSON followed the Collections list order but I wouldn't worry about it in the least.

[Merudo]

If GSON is less featured than our JSON, why not keep the current library?

We can use our existing functions to convert the output of json.path into JSON elements if need be.

By converting to GSON, we may be doing a needless downgrade. Unless there is some performance gain from using GSON?

[cwisniew]

If GSON is less featured than our JSON, why not keep the current library?

We can use our existing functions to convert the output of json.path into JSON elements if need be.

By converting to GSON, we may be performing a needless downgrade. Unless there is some performance gain from using GSON?

At the moment the json.path functions are converting JSON objects to strings, then parsing the strings to GSONs representation which is quite bad performance wise. Then making the change to convert that back to the JSON representation we are using isn't straight forward. So moving to GSON is the easiest way to fix the problems.

[cwisniew]

Reviewed 1 of 1 files at r2.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @Phergus)

[Merudo]

At the moment the json.path functions are converting JSON objects to strings, then parsing the strings to GSONs representation which is quite bad performance wise. Then making the change to convert that back to the JSON representation we are using isn't straight forward. So moving to GSON is the easiest way to fix the problems.

I was planning on converting GSON to strings, then parsing the strings to JSON objects. Easy enough considering we already have these parsing functions.

But, staying with GSON all the way through will improve the performance.

[JamzTheMan]

I may be wrong but GSON has better class -> JSON serialization as well. So it may have less functionality in some places but more/better in others.

My "not totally researched but from memory" answer so take that as is.