You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Grobmeier <gr...@gmail.com> on 2009/04/30 13:10:18 UTC
New Sandbox Component Proposal: Commons JSON
Dear Commons-Folks,
Yonik Seeley and I propose the creation of a new Sandbox component
within Apache Commons. We would like to name it Commons JSON since it
should deal with everything around JSON.
Yonik did already implement a JSON-Parser in Apache Labs name Noggit:
http://svn.apache.org/repos/asf/labs/noggit/
I have implemented some other JSON-Lib at Google Code:
http://code.google.com/p/jjson
We would like to join forces since my JSON lib isn't very good at
parsing and Noggit lacks of some classes I created. Here is the
original proposal from Noggit which also fits to JJSON:
There is a need for an "industrial strength" JSON parser for Java with
the following features:
- Streaming API (StAX/pull-parser like) for both easy and efficient parsing
- Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt
- Can adhere strictly to the standard (not a superset like existing
parsers), preferably by default
- Memory efficiency
- incremental parsing (Reader-based) in order to handle huge messages
- a single byte of state needed per nested object or array
- does not read large objects (including primitives) completely into
memory unless asked
- can eliminate most copying, allowing the user to provide the output
buffer for values
- no built in size limits for primitives (less than 2GB)
- can even handle keys of any size in a map
- can handle primitives of *any* size (does not attempt to parse
numerics into a certain language primitives unless asked)
- Fast!
I would like to add:
- no dependencies!
- Creates JSON Strings of Objects and vice versa
- Annotations for creating objects from a JSON string.
We believe that a JSON lib will become attention quickly and hope to
get more developers attracted soon.
Please let us know what you think about it!
Best,
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
Posted by Yonik Seeley <yo...@lucidimagination.com>.
On Thu, Apr 30, 2009 at 9:08 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Christian Grobmeier wrote at Donnerstag, 30. April 2009 13:10:
>> - Streaming API (StAX/pull-parser like) for both easy and efficient
>> parsing
>
> Shall this solution actually act as StAX XMLReader/XMLWriter or do you use
> this API simply as inspiration?
Simply an inspiration - the underlying implementation should be as
fast and flexible as possible w/o being held back by existing APIs
(which can always be layered on top if desired).
>> - a single byte of state needed per nested object or array
>
> Can you elaborate on this one?
It's just how much state the parser uses keep track of things like
nested arrays or JSON objects. Noggit currently uses 1 byte for each
nested object/array.
Consider the amount of extra memory some parsers may use parsing something like
{{{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}}}
Nice to know the max overhead from a denial-of-service point of view too.
[...]
>> We believe that a JSON lib will become attention quickly and hope to
>> get more developers attracted soon.
>> Please let us know what you think about it!
>
> Well, there are quite some solutions in the wild ;-)
Most are.... not so great. Jackson is the exception (but
unfortunately it didn't exist when I wrote Noggit).
-Yonik
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
Posted by Christian Grobmeier <gr...@gmail.com>.
> Why do you consider a dependency on Antlr a negative (the runtime is 148k), JSON is a formally defined language after all.
I don't know a person face to face who actually can handle antlr. Its
a cool tool, but if you need to create a patch for your json lib, it
can be hell. Plain java is understood by every java developer (well,
most ;-)).
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: New Sandbox Component Proposal: Commons JSON
Posted by Gary Gregory <GG...@seagullsoftware.com>.
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
Re: New Sandbox Component Proposal: Commons JSON
Posted by Christian Grobmeier <gr...@gmail.com>.
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
Re: New Sandbox Component Proposal: Commons JSON
Posted by Jörg Schaible <jo...@gmx.de>.
Hi Christian,
Christian Grobmeier wrote at Donnerstag, 30. April 2009 13:10:
> Dear Commons-Folks,
>
> Yonik Seeley and I propose the creation of a new Sandbox component
> within Apache Commons. We would like to name it Commons JSON since it
> should deal with everything around JSON.
>
> Yonik did already implement a JSON-Parser in Apache Labs name Noggit:
> http://svn.apache.org/repos/asf/labs/noggit/
>
> I have implemented some other JSON-Lib at Google Code:
> http://code.google.com/p/jjson
>
> We would like to join forces since my JSON lib isn't very good at
> parsing and Noggit lacks of some classes I created. Here is the
> original proposal from Noggit which also fits to JJSON:
>
> There is a need for an "industrial strength" JSON parser for Java with
> the following features:
>
> - Streaming API (StAX/pull-parser like) for both easy and efficient
> parsing
Shall this solution actually act as StAX XMLReader/XMLWriter or do you use
this API simply as inspiration? If you intend to do the former, I'd like to
know how you differentiate yourself from Jettison at Codehaus.
> - Conforms to the JSON standard:
> http://www.ietf.org/rfc/rfc4627.txt
> - Can adhere strictly to the standard
> (not a superset like existing parsers), preferably by default
> - Memory efficiency
> - incremental parsing (Reader-based) in order to handle huge messages
> - a single byte of state needed per nested object or array
Can you elaborate on this one?
> - does not read large objects (including primitives) completely into
> memory unless asked
> - can eliminate most copying, allowing the user to provide the output
> buffer for values
> - no built in size limits for primitives (less than 2GB)
> - can even handle keys of any size in a map
> - can handle primitives of *any* size (does not attempt to parse
> numerics into a certain language primitives unless asked)
> - Fast!
>
> I would like to add:
> - no dependencies!
> - Creates JSON Strings of Objects and vice versa
... and a bit more on the mapping this mechanism.
> - Annotations for creating objects from a JSON string.
>
> We believe that a JSON lib will become attention quickly and hope to
> get more developers attracted soon.
> Please let us know what you think about it!
Well, there are quite some solutions in the wild ;-)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
Posted by Christian Grobmeier <gr...@gmail.com>.
>>> As a commons committer, you can start things in the sandbox without a
>>> formal
>>> vote. You should probably execute a grant for the stuff done outside the
>>> ASF. Does Yonik have sandbox karma? If not, just ask. Happy hacking!
Great to hear! Just wanted to ask before bringing stuff in! I will
tell Yonik that he needs to request karma.
>> Didn't we resolve that a grant for stuff outside the ASF by someone
>> who has signed a CLA is fine?
>
> Whence "probably" - I would not personally complain as long as the non-ASF
> stuff is the original work of one person, is "clean" from IP standpoint and
> is not "large". The last is a judegement call.
I was the only person working on the google-code and I have signed the
CLA (of course).
If this is considered OK, I will go ahead. I don't think the codebase
is large - roundabout 10 classes or so.
See: http://code.google.com/p/jjson/source/browse/#svn/trunk/src/main/java/de/grobmeier/jjson
However, since I wrote the code alone I can sign any formal sheets at
any time, if necessary.
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
Posted by Phil Steitz <ph...@gmail.com>.
Henri Yandell wrote:
> On Fri, May 15, 2009 at 6:44 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> Christian Grobmeier wrote:
>>
>>> Dear Commons-Folks,
>>>
>>> Yonik Seeley and I propose the creation of a new Sandbox component
>>> within Apache Commons. We would like to name it Commons JSON since it
>>> should deal with everything around JSON.
>>>
>>> Yonik did already implement a JSON-Parser in Apache Labs name Noggit:
>>> http://svn.apache.org/repos/asf/labs/noggit/
>>>
>>> I have implemented some other JSON-Lib at Google Code:
>>> http://code.google.com/p/jjson
>>>
>>> We would like to join forces since my JSON lib isn't very good at
>>> parsing and Noggit lacks of some classes I created. Here is the
>>> original proposal from Noggit which also fits to JJSON:
>>>
>>> There is a need for an "industrial strength" JSON parser for Java with
>>> the following features:
>>>
>>> - Streaming API (StAX/pull-parser like) for both easy and efficient
>>> parsing
>>> - Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt
>>> - Can adhere strictly to the standard (not a superset like existing
>>> parsers), preferably by default
>>> - Memory efficiency
>>> - incremental parsing (Reader-based) in order to handle huge messages
>>> - a single byte of state needed per nested object or array
>>> - does not read large objects (including primitives) completely into
>>> memory unless asked
>>> - can eliminate most copying, allowing the user to provide the output
>>> buffer for values
>>> - no built in size limits for primitives (less than 2GB)
>>> - can even handle keys of any size in a map
>>> - can handle primitives of *any* size (does not attempt to parse
>>> numerics into a certain language primitives unless asked)
>>> - Fast!
>>>
>>> I would like to add:
>>> - no dependencies!
>>> - Creates JSON Strings of Objects and vice versa
>>> - Annotations for creating objects from a JSON string.
>>>
>>> We believe that a JSON lib will become attention quickly and hope to
>>> get more developers attracted soon.
>>> Please let us know what you think about it!
>>>
>>>
>> Sounds great!
>>
>> As a commons committer, you can start things in the sandbox without a formal
>> vote. You should probably execute a grant for the stuff done outside the
>> ASF. Does Yonik have sandbox karma? If not, just ask. Happy hacking!
>>
>
> Didn't we resolve that a grant for stuff outside the ASF by someone
> who has signed a CLA is fine?
>
Whence "probably" - I would not personally complain as long as the
non-ASF stuff is the original work of one person, is "clean" from IP
standpoint and is not "large". The last is a judegement call.
Phil
> Hen
>
> ---------------------------------------------------------------------
> 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
Re: New Sandbox Component Proposal: Commons JSON
Posted by Henri Yandell <fl...@gmail.com>.
On Fri, May 15, 2009 at 6:44 PM, Phil Steitz <ph...@gmail.com> wrote:
> Christian Grobmeier wrote:
>>
>> Dear Commons-Folks,
>>
>> Yonik Seeley and I propose the creation of a new Sandbox component
>> within Apache Commons. We would like to name it Commons JSON since it
>> should deal with everything around JSON.
>>
>> Yonik did already implement a JSON-Parser in Apache Labs name Noggit:
>> http://svn.apache.org/repos/asf/labs/noggit/
>>
>> I have implemented some other JSON-Lib at Google Code:
>> http://code.google.com/p/jjson
>>
>> We would like to join forces since my JSON lib isn't very good at
>> parsing and Noggit lacks of some classes I created. Here is the
>> original proposal from Noggit which also fits to JJSON:
>>
>> There is a need for an "industrial strength" JSON parser for Java with
>> the following features:
>>
>> - Streaming API (StAX/pull-parser like) for both easy and efficient
>> parsing
>> - Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt
>> - Can adhere strictly to the standard (not a superset like existing
>> parsers), preferably by default
>> - Memory efficiency
>> - incremental parsing (Reader-based) in order to handle huge messages
>> - a single byte of state needed per nested object or array
>> - does not read large objects (including primitives) completely into
>> memory unless asked
>> - can eliminate most copying, allowing the user to provide the output
>> buffer for values
>> - no built in size limits for primitives (less than 2GB)
>> - can even handle keys of any size in a map
>> - can handle primitives of *any* size (does not attempt to parse
>> numerics into a certain language primitives unless asked)
>> - Fast!
>>
>> I would like to add:
>> - no dependencies!
>> - Creates JSON Strings of Objects and vice versa
>> - Annotations for creating objects from a JSON string.
>>
>> We believe that a JSON lib will become attention quickly and hope to
>> get more developers attracted soon.
>> Please let us know what you think about it!
>>
>
> Sounds great!
>
> As a commons committer, you can start things in the sandbox without a formal
> vote. You should probably execute a grant for the stuff done outside the
> ASF. Does Yonik have sandbox karma? If not, just ask. Happy hacking!
Didn't we resolve that a grant for stuff outside the ASF by someone
who has signed a CLA is fine?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: New Sandbox Component Proposal: Commons JSON
Posted by Phil Steitz <ph...@gmail.com>.
Christian Grobmeier wrote:
> Dear Commons-Folks,
>
> Yonik Seeley and I propose the creation of a new Sandbox component
> within Apache Commons. We would like to name it Commons JSON since it
> should deal with everything around JSON.
>
> Yonik did already implement a JSON-Parser in Apache Labs name Noggit:
> http://svn.apache.org/repos/asf/labs/noggit/
>
> I have implemented some other JSON-Lib at Google Code:
> http://code.google.com/p/jjson
>
> We would like to join forces since my JSON lib isn't very good at
> parsing and Noggit lacks of some classes I created. Here is the
> original proposal from Noggit which also fits to JJSON:
>
> There is a need for an "industrial strength" JSON parser for Java with
> the following features:
>
> - Streaming API (StAX/pull-parser like) for both easy and efficient parsing
> - Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt
> - Can adhere strictly to the standard (not a superset like existing
> parsers), preferably by default
> - Memory efficiency
> - incremental parsing (Reader-based) in order to handle huge messages
> - a single byte of state needed per nested object or array
> - does not read large objects (including primitives) completely into
> memory unless asked
> - can eliminate most copying, allowing the user to provide the output
> buffer for values
> - no built in size limits for primitives (less than 2GB)
> - can even handle keys of any size in a map
> - can handle primitives of *any* size (does not attempt to parse
> numerics into a certain language primitives unless asked)
> - Fast!
>
> I would like to add:
> - no dependencies!
> - Creates JSON Strings of Objects and vice versa
> - Annotations for creating objects from a JSON string.
>
> We believe that a JSON lib will become attention quickly and hope to
> get more developers attracted soon.
> Please let us know what you think about it!
>
Sounds great!
As a commons committer, you can start things in the sandbox without a
formal vote. You should probably execute a grant for the stuff done
outside the ASF. Does Yonik have sandbox karma? If not, just ask.
Happy hacking!
Phil
> 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