JSONObject.get() returns String including quote characters?

[babygodzilla]

Anyone have an idea why this is happening or how to fix it? I did
JSONObject.get("name") and the string was returned encased in quotes.

Also, how do I add external JAR libraries to my GWT project? I can't
find any clear instruction to do this. I wanted to add Commons Lang to
use the StringUtils.remove() method to remove the quotes and
everything went haywire. I tried modifying the XML file as well as the
shell and compile files to no avail.

Any help would be appreciated. Thank you.

[Reinier Zwitserloot]

JSONObject.get() returns JSONValues. The toString() of all JSONValues
is defined as the JSON representation of that value.

If "name" is mapped to a string, you are probably looking for:

JSONObject.get("name").isString().stringValue()

Any included code into a GWT project MUST have a .gwt.xml file. This
is because GWT isn't really java, it's very java like. A project, for
safety reasons, therefore needs to explicitly state it was written
with GWT in mind (by way of having a .gwt.xml file). You can toss your
own in there if you want to, for future reference. However, in this
case, StringUtils is not needed to de-jsonify.

[babygodzilla]

ah thank you. i will try that and tell you the results. what should be
the content of this .gwt.xml? should i just copy paste from
myapp.gwt.xml and modify as needed?

[Reinier Zwitserloot]

Right, modify as needed. It can pretty much be empty for libraries (no
entry point, of course, Usually just the one standard inherit).

[babygodzilla]

Found another weird JSON behavior... apparently JSONNumber is
represented as a double. what's the correct way to convert this? I am
currently doing this:

String.valueOf((int)jObject.get("id").isNumber().getValue())

seems like a lot of hoopla. is there a more straightforward way? and
the .isString().stringValue() worked to grab a string. thanks!

[Reinier Zwitserloot]

All int numbers are perfectly representable in doubles. (but not the
other way around, obviously). This is a standard JSON limitation.

if you KNOW the input is an integer, you can just go
jsonObject.get("whatever").toString(), or "" +
jsonObject.get("whatever").isNumber().getValue() - though why you are
converting a number back to a string is a bit of a mystery.

[babygodzilla]

The input *is* an integer, at least on the Servlet side. yet when it
arrives at the client it is a double. Did I do something wrong there?

And the reason I had to convert it back to a String is because I
wanted to plug the value into a ListBox, and addItem() only takes
String or String,String.

[Reinier Zwitserloot]

No, as I said, standard JSON limitation. JSON is JavaScript Object
Notation, and javascript has no notion of int, char, short, long,
double, and float. It just has 'numbers', which are according to spec
doubles are better, and in practice, on all browsers, doubles.
Therefore, in JSON, there are also only doubles. HOWEVER, if you pass
an int into JSON, then it gets turned into a double, but, all ints are
perfectly representable in doubles, and therefore, if you then receive
the double, it'll be the exact same int, even without rounding.

[babygodzilla]

I think I see what you are saying. However, the int that gets turned
into a double is now represented in decimal point format. That is, 1
is not 1.0 and 2 is now 2.0. That is what I am trying to fix by
casting the double as an int. Is that the correct way?

[Reinier Zwitserloot]

Yes.

[Nick Bastin]

On Jun 30, 1:39 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Therefore, in JSON, there are also only doubles. HOWEVER, if you pass
> an int into JSON, then it gets turned into a double, but, all ints are
> perfectly representable in doubles, and therefore, if you then receive
> the double, it'll be the exact same int, even without rounding.

Actually, in JSON there are only "numbers", not integers or doubles.
Unfortunately, because the JSON spec doesn't specify any bounds on the
size of "number", there's no guarantee that all your ints will fit
into whatever datatype your parser decides to use. The relevant part
of the spec:

"A number contains an integer component that
may be prefixed with an optional minus sign, which may be followed
by
a fraction part and/or an exponent part."

and the grammar breaks down into:

number = [ minus ] %x30 / (%x31-39 *DIGIT) [ frac ] [ exp ]

Which unfortunately means that your JSON writer is possibly perfectly
capable of encoding integers that are too large to fit into whatever
data type is used to decompose a "number" on the other side (a problem
you are doubly likely to encounter if your client and server are
written in different languages).

The spec states:

"An implementation may set limits on the range of numbers."

But it does not define any limits (even recommended), so you are left
to the mercy of your parsers.

--
Nick

[Reinier Zwitserloot]

Nick, you forgot the first rule of web development.

Throw away the specs, because nobody follows them. Look at the real
world.

Any browser, *ANY* browser that releases javascript support that
cannot safely hold double-precision IEEEs, in particular, 32-bit
integers without losing precision, will not render a great many pages.
This by itself guarantees that you might as well consider 'numbers in
javascript are doubles or better' as canon. The one thing you cannot
do is rely on exact behaviours and exact precisions; e.g. dont go and
rely on 2^52+1 being the same as 2^52 in 'double-math'. As if you
would want to.

On Jun 30, 10:54 pm, Nick Bastin <nick.bas...@gmail.com> wrote:

[Nick Bastin]

On Jul 3, 12:55 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Nick, you forgot the first rule of web development.
>
> Throw away the specs, because nobody follows them. Look at the real
> world.

In the real world, JSON isn't used only on the browser (obviously,
those numbers are coming from *somewhere*).

> Any browser, *ANY* browser that releases javascript support that
> cannot safely hold double-precision IEEEs, in particular, 32-bit
> integers without losing precision, will not render a great many pages.

This may be true, but your comment was that JSON Numbers are Doubles,
which they are not. They *may* be stuffed into some IEEE-754 variant
on the browser side, but there's certainly no guarantee that holds
true on the server side. My original point was that your ints could
easily be larger than 32-bits, and you should not assume that they'll
be correctly parsed on both sides even though the spec allows for
arbitrary precision.

My point is just that your JSON application is an entire system
(involving at *least* 2 parser implementations), and you need to
understand how each piece of the system treats that JSON, since with
the notable exception of a rare few JSON parsers, none are actually
compliant.

--
Nick