commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: New Sandbox Component Proposal: Commons JSON
Date Thu, 30 Apr 2009 14:42:44 GMT
Hello,

I am glad we are looking at JSON.

Why do you consider a dependency on Antlr a negative (the runtime is 148k), JSON is a formally
defined language after all. 

I always scratch my head when I hear "there are dependencies!" when any application I create
or use always has dependencies. I wonder how much redundancies and bug fixes would be removed
if, for example, all Apache Java code (or even just the Commons code) went the other way and
did depend on each other. You might argue we would end up in 'jar hell' but that might force
us to better draw boundaries between components and fix bugs :)

Gary

> -----Original Message-----
> From: Christian Grobmeier [mailto:grobmeier@gmail.com]
> Sent: Thursday, April 30, 2009 6:43 AM
> To: Commons Developers List
> Subject: Re: New Sandbox Component Proposal: Commons JSON
> 
> Hi Jörg,
> 
> thanks for asking!
> 
> >> I would like to add:
> >> - no dependencies!
> >> - Creates JSON Strings of Objects and vice versa
> >
> > ... and a bit more on the mapping this mechanism.
> 
> Basically you have a JSONValue which can be JSONString, JSONNumber
> etc. If you call toJSON at this object, you'll get a JSON string. This
> is done by recursion. Same goes to map a json string into a JSONValue.
> Here I am using my own parser, but Noggit should replace it.
> 
> Then there is a simple annotation based serializer in which you can
> put an object and get an JSONString in return. This is basically done
> by checking the type of the object. If object, then it must be a json
> object, fields are the same and lists become json arrays. Some if
> else, nothing special.
> 
> Mapping from an json string into an annotated object has been started,
> but not finished. We have to think about an elegant solution. Of
> course, this should be noggit based too :-)
> 
> > Well, there are quite some solutions in the wild ;-)
> 
> Most have tons of depencies. Some use Google Collection, the next use
> antlr (!) and other heavy weight dependencies. The case of JSON is
> very simple, but in most cases totally overenineered.
> 
> I collected some thoughts about current libs in the past, while
> working on projects with JSON:
> 
> We have used json-lib.sourceforge.net in 2006/2007; problem here are tons
> of features which you can't necessarly control. At the end we didn't
> use 10% of the features, broke up the code and made a fork ourself,
> to delete some stuff which really made us insane. Interface here is
> changing quite often.
> 
> The org.json implementation has some of the problems too- json-lib is
> based on this.
> 
> org.json.me seem to be similar to what i want, but does not seem to be
> developed. And it has some programmatic stuff inside which i don't
> like. Just a matter of taste.
> 
> JSON Tools seem to have a dependency to antlr, which i didn't want. It
> also has not been developed for a while and is GPLed.
> 
> org.json.simple is GPLed too (and i didn't find it was such simple)
> 
> Stringtree does some parsing, but don't have a object representation.
> 
> JSOn-Taglib is a taglib which was out of the evaluation cause we
> didn't use webtier.
> 
> JSon Serialization gives you a class to serialize json. No objects at
> all, but asl2 and worth considering for the use of the parser. Java 5
> 
> JSonMarshaller is Java 5 and quite early but promisiing. You can
> easily serialize pojos with annotations to json and vv. It cannot work
> on Enums and it has some evil bugs inside, which we suffered from in
> 2008.
> 
> 
> Basically I would like to enjoy some very simple lib, without any
> depenncies and with good speed.
> Noggit promises the speed, and the rest can be cleaned up. Finally its
> ASL license.
> 
> Best,
> Christian
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message