It was a lot more work than I originally thought, but its done, and it
does include the ability to create JSON and not just read it.

I created a little real world scenario type of deal in both the old
way and the new way. To my big surprise, the new API is easier to
write for AND produces smaller js files!

JS filesize: 13828 in old, vs. 12180 in new. java file size: 2386
characters for old vs. 1688 for new.

I was afraid the compiled size of the new API would be bigger than the
old one, but you end up saving 1.5kb!

I don't have committer access, I did sign the CLA. Where do I go from
here?




The files I have, other than the boilerplate stuff:
 - actual source to be included in gwt-user.jar: JSON.java,
JSONWriter.java.
 - extras: JSONTest.java (junit tests) and JSONPerformanceA/
JSONPerformanceB.java (both EntryPoints and used to come up with the
above numbers).

The files live in the same package as the existing JSON library
(com.google.gwt.json.client), and the names don't overlap, so you can
stuff the new API into the old one without breaking existing code
using the old API. If you only use one of the two APIs, the other one
gets eliminated during compilation. (I confirmed this).

NB: I checked the 'safe' javascript json parser from json.org and they
use the same strategy of first extensively verifying the input then
just eval()ing it. I've nicked some of their extra safety code
including a bunch of characters, including in the higher unicode
ranges, that potentially get parsed as quotes or newlines or other
potentially dubious characters.

NB2: Part of the idea of this API is that a server-side version is
released in tandem with this client side version. This should probably
become a separate jar, I guess? Any ideas on how to distribute that?

NB3: I didn't test speed, but this version should be similarly fast.
The main speed boost of the old library: Lazy java-ification of the
values, is preserved in the new API. The new API re-walks the tree on
every lookup whereas the old one doesn't, but the new one uses a lot
more JSO overlay, so I doubt there's a significant difference either
way. The parsing bit is slower, but that's because of the safety
measures.


--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to