Finally, a JSON validator

This entry was posted on Friday, February 2nd, 2007 at 4:41 pm and is filed under JSON, Projects. You can follow any responses to this entry through the comments RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.

15 Responses to “Finally, a JSON validator”

1. Dave says:
   

   Looks neat, but how about some JavaDocs in the classes? Or is there somewhere else that I’m missing?

   February 2nd, 2007 at 5:49 pm
2. Stringtree says:
   

   Hmm. I don’t normally do JavaDoc, probably because I so rarely read JavaDoc from other software. Any suggestions which bits would most benefit from documentation?

   As an aside, I am currently working on some web pages about how to use these classes, with step-by-step examples, so that may also help.

   Thanks for taking a look.

   February 2nd, 2007 at 7:46 pm
3. chubbard says:
   

   Yea it’s not obvious how this is used. Just a simple blog post would be enough at the time. Right now I’m getting an exception from your library at the moment.

   “Value out of sequence.”

   Also adding collection and Map support would be really great. So I can just serialize any object.

   Javadoc would be great because you can go into more in depth description of how it actually works. But, add some examples to your javadoc too so you get a high level idea of how it works.

   February 5th, 2007 at 9:23 pm
4. Stringtree says:
   

   The best way to see how all these classes can be used is to take a look at the tests (follow the link given in the post to download all the files). Even if you don’t have JUnit or don’t want to run them they are a great resource for finding out how I expect the code to be used.

   I’m not sure what’s generating the “value out of sequence” error - it’s not something that my code generates - i’ll happily take a look at your code/data if you would like.

   As for Collection and Map support, it should be there already. I certainly build Collections of Maps (and vice versa) in my test cases and pass them in to JSONWriter and they do something senseible.

   Can you give some examples of what you would like to do?

   February 7th, 2007 at 10:48 am
5. Clint Pells says:
   

   First, thanks for this. It is very simple, intuitable and effective.
   I have only used the writer but was having two problems and one issue. The first problem was that Enums will casue a stack overflow. Example:
   
public class EnumCheck {
enum Numbers { ONE, TWO, THREE }
public static void main( String[] args ) {
System.out.println( new JSONWriter().write( Numbers.ONE ));
}
}


   My fix was to add
   else if (object instanceof Enum) string(object);
   to the value() method;

   The second was that private fields case an java.lang.IllegalAccessException error that is easily avoided by checking field.isAccessible();

   I also didn’t want the class name in to output. So I ended up with this bean method:

   
private void bean(Object object) {
add("{");
BeanInfo info;
boolean addedSomething = false;
try {
info = Introspector.getBeanInfo(object.getClass());
PropertyDescriptor[] props = info.getPropertyDescriptors();
for (int i = 0; i

   March 1st, 2007 at 5:23 pm
6. Clint Pells says:
   

   Actually:
   private void bean(Object object) {
   add(”{”);
   BeanInfo info;
   boolean addedSomething = false;
   try {
   info = Introspector.getBeanInfo(object.getClass());
   PropertyDescriptor[] props = info.getPropertyDescriptors();
   for (int i = 0; i

   March 1st, 2007 at 5:24 pm
7. Clint Pells says:
   

   Actually!:
   
private void bean(Object object) {
add("{");
BeanInfo info;
boolean addedSomething = false;
try {
info = Introspector.getBeanInfo(object.getClass());
PropertyDescriptor[] props = info.getPropertyDescriptors();
for (int i = 0; i < props.length; ++i) {
PropertyDescriptor prop = props[i];
String name = prop.getName();
Method accessor = prop.getReadMethod();
if ((!”class”.equals(name) ) && accessor != null) {
if ( addedSomething ) { add(’,'); } else { addedSomething = true; }
Object value = accessor.invoke(object, (Object[])null);
add(name, value);

   }

   }
   Field[] ff = object.getClass().getDeclaredFields();
   for (int i = 0; i < ff.length; ++i) {
   Field field = ff[i];
   if ( field.isAccessible() ) {
   if ( addedSomething ) { add(’,'); } else { addedSomething = true; }
   add(field.getName(), field.get(object));
   }
   }

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


   March 1st, 2007 at 5:26 pm
8. Stringtree says:
   

   Thanks for the suggestions, and sorry about the problems with html escaping in your comment

   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..

   March 1st, 2007 at 9:49 pm
9. Stringtree says:
   

   OK Folks. I’ve had a look at the JSONWriter code and added the following fixes based on suggestions from Clint Pells:

   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!

   March 1st, 2007 at 11:38 pm
10. Chris says:
    

    Compliments on a thorough, yet simple implementation. We embarked recently on an internal implementation as well, and I was amazed at how similar the two implementations were when I came across yours.

    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.

    March 23rd, 2007 at 2:11 pm
11. Stringtree says:
    

    Thanks for the comment, Chris.

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

    March 23rd, 2007 at 4:09 pm
12. Stringtree says:
    

    OK, I’ve updated the code to fix the problem Chris reported: JSONWriter and JSONWriterMapTest updated.

    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.

    March 23rd, 2007 at 4:52 pm
13. Bryan says:
    

    You can use java.util.IdentityHashMap.

    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.

    April 6th, 2007 at 5:14 am
14. Mendy says:
    

    Great program! I Use the stand alone JSONReader class

    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

    June 26th, 2007 at 6:59 pm
15. Stringtree says:
    

    I’m puzzled by this. I didn’t think an empty comma was valid JSON.

    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.

    June 29th, 2007 at 10:02 pm