I wrote some code based on the org.json implementation mainly if you map a class property in your json with your java class fqn or a key that corresponds to some java class fqn you can map the object back and forth from java to json and vice versa, nothing too fancy but saved me the effort of mapping a complex object graph back and forth. As for Antlr I am with Christian that JSON is very basic in a way that doesn't really call for adding dependencies
On Thu, Apr 30, 2009 at 11:50 PM, Matt Benson <gudnabr...@yahoo.com> wrote: > > > > --- On Thu, 4/30/09, Christian Grobmeier <grobme...@gmail.com> wrote: > > > From: Christian Grobmeier <grobme...@gmail.com> > > Subject: Re: New Sandbox Component Proposal: Commons JSON > > To: "Commons Developers List" <dev@commons.apache.org> > > Date: Thursday, April 30, 2009, 2:25 PM > > Matt, > > > > > I don't know about folks you (or I) know face-to-face, > > but I know that several ASF committers and members have > > popped up around the ANTLR lists over the years, including, > > off the top of my head, myself, Torsten, O.Ziegermann, H.L. > > Ship, and probably others. I personally am quite > > comfortable with ANTLR 2.x but need to really take the time > > to play with ANTLR 3. The argument _for_ using parser > > generators is that those who use them feel the grammar is > > easier to digest (it's smaller) than the equivalent Java > > code. It's something else again to debug ANTLR > > parsers/treeparsers, but it's far from impossible. Once > > you get used to knowing what to look for it's actually > > fairly easy. I don't say any of this to disparage Yonik's > > work on Noggit (I've not looked at it); I am just airing my > > understanding of the motivations for using grammars and > > parser generators as opposed to hand-writing parsers. > > > > > > what you (and Torsten, he PMed me) are saying will surely > > make digg me > > more into antlr. At the moment I always felt that such a > > simple format > > like json doesn't need such a tool like antlr, but > > maybe I am wrong > > and should rethink. However, Yoniks parser is very fast - > > antlr > > parsers should have same performance and should be memory > > efficient > > too. > > This can be checked, of course, and I will do that (when > > having some > > spare time left :-)). > > > > Cool--note that ANTLR 3 is designed to be much faster than ANTLR 2 IIRC. > > -Matt > > > Thanks! > > > > Christian > > > > > > > > > > -Matt > > > > > >> > 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 :) > > >> > > >> > > >> In maven age I don't feel bad with dependencies, > > but one > > >> json lib did > > >> depend on asm version 1 once, and hibernate > > upgraded to asm > > >> version 2, > > >> and that gave me nightmare. I ended up with > > opening my json > > >> package > > >> and copied all version 1 files into it with own > > package > > >> name. I > > >> recompiled, brought this to my repos and so on. > > This was > > >> hell (cause > > >> my customer didn't want to pay the time). > > >> > > >> For me json is so basic, that we can do everything > > without > > >> any > > >> dependencie. And a basic lib should not have any, > > I think. > > >> > > >> Thanks! > > >> > > >> Christian > > >> > > >> > > --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
