'. '

JSON4Brwsr

From APIDesign

Jump to: navigation, search

JSON is the standard API for persisting objects in current browsers. In case Java wants to get Bck2Brwsr it needs to play well with JSON. You may think there has been too many APIs to access JSON from Java created already -- one of them must fit the needs of Bck2Brwsr (and FXBrwsr). Well, it does not. The reason is that for all the previous attempts the assumption was that Java is the base and JSON is built on top of its runtime. In case of the Bck2Brwsr project the situation is up-side-down. JavaScript (and thus also JSON) is naturally supported and Java lives above it.

[edit] net.java.html.json

Can the Java to JSON mapping get more simple than this: http://hudson.apidesign.org/hudson/job/bck2brwsr-net.java.html.json/javadoc/ ?

I doubt. With the help of AnnotationProcessors we remove the need to type boiler plate code. Don't bother with getters and setters, don't bother with fields. Just use the @Property annotation and the rest will be generated for you. When you need to talk to server use @OnReceive annotation and you get the result. Type-safe. Reflection-less. Effective.

As the Twitter example shows, with the Java code may in fact the smaller than the same JavaScript one.

[edit] org.apidesign.html.json

The above ClientAPI is accompanied with associated ProviderAPI and TCK: HTML JSON SPI

Depending on the execution technology (e.g. Bck2Brwsr vs. HotSpot vs. for example Doppio), rendering technology (Knockout.js or Angular.js, Jersey, etc.) and JSON persistence technology (e.g. native JavaScript objects vs. netscape.JSObject vs. Java wrapper like Jackson) one selects the right provider.

As a result we can use the same API and execute it in different contexts (real browser, FXBrwsr or server). Java can once again guarantee its original WORA promise.

[edit] Write Your Own Provider

In case of questions, ask on our mailing list bck2brwsr (at) apidesign.org

Views
Personal tools
buy