Checking json.org (always the definitive place to look) I see:

array
    []
    [ elements ]
elements
    value
    value , elements
value
    string
    number
    object
    array
    true
    false
    null

i.e. an array may have a single value or a value followed by a comma followed by more values separated by commas.

So an array starting or ending with a comma is not valid, and my JSONReader makes no claims about what it might produce for invalid JSON. Did you try running it through my JSONValidator to see what that says about it?

Is this being generated by software which you can control or change to ensure it produces valid JSON? maybe there should be a null before the comma in this case?

If you don’t have control over the source, then something like

s = s.replace(”[,”, “[null,”));

or

s = s.replace(”[,”, “[”));

should produce valid JSON for processing.

Let me know if you need any more help, or if I have missed your point.

One problem I noticed the below valid json gives back bad results.


{"people":[,{"birthdate": 198940304037,"class": "flexjson.test.mock.Person"}]}


I tried but couldn’t fix it, basically the empty comma is given an empty object literal in its place.


{people=[java.lang.Object@82ba41, java.lang.Object@82ba41]}


I wonder if the an empty comma in other places would have similar affects.

regards

You should also make sure that the same reference can appear more than once, just as long as its not reachable going up or down the object graph.

The bit that took the longest was that the “contains” method from the collections API which I was using overflowed if asked about a Map with cyclic references, so I had to implement my own scan through the collection of called objects comparing with ‘==’.

Does anyone know of a standard API which allows a “contains” check using ‘==’ rather than ‘equals’ ?

Thanks again, Chris.

I’l take a look at that failure case and see if I can generalize the cycle-checking a bit.

One thing I found while testing our implementation was the cyclic StackOverFlow errors you encountered. We employed a similar method of keeping track of objects we’ve visited to catch the cyclic references. One of our test cases was a Collection containing a cyclic reference to another Collection (Maps work also). I tried this test case on your implemenation and found it still induced a StackOverFlow error. We check for cycles at a higher level, before passing the object to the “value” methods and therefore can catch the Collection/Map cyclic references.

Just thought I’d pass along those thoughts.

1. Track object context to prevent stack overflow on cyclic references such as enums. If/when a previously processed bean is encountered, just emit null.

2. Changed field access to prevent exceptions on private fields. The suggested use if isAccessible did not actually solve the problem, as it also prevented access to public fields However, changing getDeclaredFields to just getFields seems to have solved it.

3. Only emit commas in beans when really necessary. This was based on Clint’s code, but tweaked a little.

4. Made emitting the class name in a bean map optional. I noticed that Clint had hard-coded not to emit the classname as a map entry. After thinking about this I could come up with scenarios where it might be desired or not. So it is now switchable with a constructor parameter to both JSONWriter and JSONValidatingWriter.

Subversion is now updated, the links at the top should go to the new versions.

Thanks again for taking the time to try out and comment on my software!

I definately see the value of the addition to the bean method, and I’ll add that.

As for the enum one, I’m not so sure. It appears that the reason enums give a stack overflow is that each enum value exposes itself (and all its fellows) as a public property. When JSONWriter tries to expand it, follows the tree indefinately.

Even if we apply a quick fix to catch enums, there’s nothing to stop any other class from doing the same.

I’ll think about this, but I reckon we might well need to track visited objects and stop if we encounter one we’ve written.

Hmm..

} catch (Exception e) {
e.printStackTrace();
}
add(”}”);
}