The next step is to get it into gwt-incubator. I've verified that you have commit rights there. To stop later name collisions, the package should be named com.google.gwt.gen2.json.
We put benchmarks in the test source directory, so, for instance, you might have: test\com\google\gwt\gen2\json\client\JsonTest.java and test\com\google\gwt\gen2\json\client\JsonBenchmark.java The test suite, if you have one, should live directly under json, and should not include the benchmark code. You will also need a demo in src-demo/com.google.gwt.gen2.demo.json. Please feel free to ping me with any questions! On Sun, Sep 21, 2008 at 2:14 AM, Reinier Zwitserloot <[EMAIL PROTECTED]>wrote: > > See http://code.google.com/p/google-web-toolkit/issues/detail?id=2900 > > On Sep 21, 8:11 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > > 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. > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
