Any interest in using a better JSON Java library?

[Matt]

All,

Working on a project where we are migrating from JSON-RPC to jabsorb
and am a bit disappointed in the JSON serializer/deserializer library
in use.

I had hoped that the new version would have improved or ditched the
old implementation but it still seems severely limited compared to
others out there.

I've been using json-lib (http://json-lib.sourceforge.net/) with good
success.

The basic problem I have with the library currently in use by jabsorb
is that it doesn't seem to handle complex objects (Lists of Maps for
instance).

Also, it seems to still lack little niceties like JSONObject
implementing the Map interface, etc. Also, (I'm on a role!) the new
version seems to introduce a checked exception when serializing/
deserializing (which causes more pain than profit in my opinion). In
short it is just not very usable for anything but very simple
situations.

Currently I'm doing a double serialization to get around the
limitations of the currently library which is a bit ugly and of course
more costly in CPU cycles.

Would updating jabsorb to use something like json-lib be a worthwhile
effort?

I note that this bug highlights many of my own problems:

http://issues.jabsorb.org/show_bug.cgi?id=9

However my solution is to simply rip out the current serializer and
replace it with a better one that is already out there.

I note that no work has been done on this bug in almost two years.
I'd be willing to do the work if everyone sees this as a useful
enhancement.

Note jabsorb and json-lib are both Apache 2.0 licensed.

Thanks,

Matt

[Arthur Blake]

I think it's a good idea.  I submitted the original bug 9 you are referring to, and I even wrote JSONMap and JSONList implementations but for some reason that fell off my plate and I never got back to testing and finishing it up.

I'm not familiar with the specific library you mentioned but I think it deserves a good looking over.

Another idea I had was maybe abstract the JSON implementation out of the picture entirely (by making some kind of interface for it) and have the ability to plug in any implementation.  May be easier said than done given that different JSON codecs could potentially have radically different API semantics.

In any event, I agree with you and have the same laments...

Do you think it's possible to do such a transition without breaking all the code out there that already uses and relies on jabsorb?  Or would a clean break with documented upgrade path be needed... ?

[Matt]

Need to look at it in more depth to see how many external API's make
reference to the current serializer if any. If everything goes
through JSONSerializer then I think the upgrade should be invisible to
normal users of jabsorb. The only reason I know about the internals
is because they choked on my complex java objects. :)

I definitely like the idea of making the serializer to use pluggable.
There seems to be some support for this already but seems to be geared
more towards the 'how do I serialize this class' rather than plugging
in a whole new serialization framework. I see no reason why the two
can't be used in tandem however.

I'll crack open the jabsorb source and start playing with it this
weekend.

Matt

On Oct 29, 12:58 pm, Arthur Blake <arthur.bl...@gmail.com> wrote:
> I think it's a good idea.  I submitted the original bug 9 you are referring
> to, and I even wrote JSONMap and JSONList implementations but for some
> reason that fell off my plate and I never got back to testing and finishing
> it up.
>
> I'm not familiar with the specific library you mentioned but I think it
> deserves a good looking over.
>
> Another idea I had was maybe abstract the JSON implementation out of the
> picture entirely (by making some kind of interface for it) and have the
> ability to plug in any implementation.  May be easier said than done given
> that different JSON codecs could potentially have radically different API
> semantics.
>
> In any event, I agree with you and have the same laments...
>
> Do you think it's possible to do such a transition without breaking all the
> code out there that already uses and relies on jabsorb?  Or would a clean
> break with documented upgrade path be needed... ?
>

[Sasha Ovsankin]

I have some code lying around that does more advanced serialization, including collections with templates. I don't mind contributing it to the project. If you guys are interested I can spend a  little bit of time, cut it out and send it over.

The code uses the same JSON library.

Here is an example of using this code:

package codebistro.persist;

import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Arrays;

import codebistro.util.String2String;
import codebistro.persist.Serializer.Context;

import junit.framework.TestCase;

@SuppressWarnings("unused")
public class SerializerTestCase extends TestCase {
    Serializer serializer= new Serializer();

    public void testString2String() {
        String2String s2s= new String2String("a", "A", "bb", "BB", "ccc", "CCC");
        Context ctx= new Context(serializer, String2String.class, null);
        Object serialized= serializer.write(s2s, ctx);
        String2String deSerialized= (String2String) serializer.read(serialized, ctx);
        assertEquals(s2s, deSerialized);
    }

    static class Arr extends ArrayList<Integer> {
        public Arr() {

        }
        public Arr(Collection<Integer> in) {
            super(in);
        }
    }

    public void testCollection() {
        Integer[] arrData1= {1, 2, 3};
        Arr arr1= new Arr(Arrays.asList(arrData1));
        Context ctx= new Context(serializer, Arr.class, null);
        Object serialized= serializer.write(arr1, ctx);
        Arr deSerialized= (Arr) serializer.read(serialized, ctx);
        assertEquals(arr1, deSerialized);
    }
   
    static class Bean {
        public int field1;
        public transient double field2;
       
        private boolean good;
        private float mood;
        private String lifeStatement;
        public boolean isGood() {
            return good;
        }
        public void setGood(boolean good) {
            this.good= good;
        }
        @Transient public float getMood() {
            return mood;
        }
        public void setMood(float mood) {
            this.mood= mood;
        }
        public String getLifeStatement() {
            return lifeStatement;
        }
        public void setLifeStatement(String lifeStatement) {
            this.lifeStatement= lifeStatement;
        }
    }
   
    public void testBean() throws Exception {
        Bean orig= new Bean();
        Method getMood= orig.getClass().getMethod("getMood");
        orig.field1= 25;
        orig.field2= 26;
        orig.setGood(false);
        orig.setLifeStatement("never stop");
        orig.setMood(-1);
        Context ctx= new Context(serializer, Bean.class, null);
        Object serialized= serializer.write(orig, ctx);
        Bean deSerialized= (Bean) serializer.read(serialized, ctx);
        assertEquals(25, deSerialized.field1);
        assertEquals(0D, deSerialized.field2);
        assertEquals(false, deSerialized.isGood());
        assertEquals("never stop", deSerialized.getLifeStatement());
        assertEquals(0F, deSerialized.getMood());
    }
}

[Roman Kuzmik]

ideally would be cool to replace marshaling/unmarshaling with Jackson
(http://jackson.codehaus.org/)
and also make services list available via SMD (http://
groups.google.com/group/json-schema/web/service-mapping-description-
proposal)