You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@pivot.apache.org by Bill van Melle <bi...@gmail.com> on 2010/11/20 04:05:04 UTC
How to debug JSONSerializer errors?
I'm trying to consume a variety of JSON-emitting web services in a more
structured/typesafe way than just getting back json and doing JSON.get to
extract relevant parts. So I've declared classes that describe the
structure of the expected values, and doing
query.setSerializer(new JSONSerializer(foo.class));
where foo is the class corresponding to the top level of the json.
I've already done this exercise in C#, where you pretty much have to declare
such classes, so I'm pretty confident I have the right structures. But I've
only gotten this to work in Pivot on the most trivial example (a web call
that returns an object with two name/value pairs, and I declare the object
accordingly). On more complicated cases, I get errors. Here are two of
them:
java.lang.IllegalArgumentException: Cannot convert array to class
[Lcom.fxpal.myunity.UCamera;.
org.apache.pivot.serialization.SerializationException: Cannot convert
number to null.
Yes, that first error literally has those nonsensical bracket, L, and
semicolon (there is a class, com.fxpal.myunity.UCamera, within the structure
of that one).
How on earth do I debug this? Both web calls return perfectly ordinary
JSON, which Pivot is happy to parse as generic json if I don't specify a
serializer.
Bonus question: some of the services I want to consume return a JSON array
of some object type. How do I create a JSONSerializer for that?
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
I just checked in an update to JSONSerializer that improves support for deserializing typed lists and maps. The following approaches are now supported:
- Parameterized property of Java bean class; e.g. public ArrayList<Foo> getFooList() {...}
- TypeLiteral
- Subclass of concrete generic sequence or dictionary; e.g. public class FooList extends ArrayList<Foo> {...}
- Direct implementation or subclass of Sequence<T> or Dictionary<String, V>; e.g. public class FooSequence implements Sequence<Foo> {...}
From a user standpoint, there isn't any real distinction between the latter two, but the implementation is slightly different - the first case gets the item/value type from a generic base class, whereas the second gets it from the Sequence interface itself.
You can see examples of each approach in org.apache.pivot.json.test.BindTest. Let me know if you have any questions.
G
On Nov 24, 2010, at 9:58 PM, Greg Brown wrote:
> Turns out this doesn't work, presumably due to type erasure. I think I'll need to walk up the type hierarchy to find the parameterized Sequence type and get the actual type arguments from that.
>
> On Nov 24, 2010, at 8:17 PM, Greg Brown wrote:
>
>> I see the problem now. When you create a subclass of a generic, it is no longer considered a parameterized type, so the code that obtains the raw type and type parameters from the generic isn't executed. Instead, the actual class type is instantiated, and the item type is set to Object.class. This is wrong - the item type should be obtained by using reflection to get the return value of get(int). The same applies to Dictionary types (get(String) should be used to get the value type).
>>
>> I'll try to fix this later tonight or tomorrow.
>>
>> On Nov 24, 2010, at 7:26 PM, Bill van Melle wrote:
>>
>>> Good, the TypeLiteral works okay now. Any idea why the other way doesn't work (using a class that extends ArrayList<Foo>)? Perhaps the element type is hard to find when it's in a parent class.
>>>
>>>
>>
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
I just checked in an update to JSONSerializer that improves support for deserializing typed lists and maps. The following approaches are now supported:
- Parameterized property of Java bean class; e.g. public ArrayList<Foo> getFooList() {...}
- TypeLiteral
- Subclass of concrete generic sequence or dictionary; e.g. public class FooList extends ArrayList<Foo> {...}
- Direct implementation or subclass of Sequence<T> or Dictionary<String, V>; e.g. public class FooSequence implements Sequence<Foo> {...}
From a user standpoint, there isn't any real distinction between the latter two, but the implementation is slightly different - the first case gets the item/value type from a generic base class, whereas the second gets it from the Sequence interface itself.
You can see examples of each approach in org.apache.pivot.json.test.BindTest. Let me know if you have any questions.
G
On Nov 24, 2010, at 9:58 PM, Greg Brown wrote:
> Turns out this doesn't work, presumably due to type erasure. I think I'll need to walk up the type hierarchy to find the parameterized Sequence type and get the actual type arguments from that.
>
> On Nov 24, 2010, at 8:17 PM, Greg Brown wrote:
>
>> I see the problem now. When you create a subclass of a generic, it is no longer considered a parameterized type, so the code that obtains the raw type and type parameters from the generic isn't executed. Instead, the actual class type is instantiated, and the item type is set to Object.class. This is wrong - the item type should be obtained by using reflection to get the return value of get(int). The same applies to Dictionary types (get(String) should be used to get the value type).
>>
>> I'll try to fix this later tonight or tomorrow.
>>
>> On Nov 24, 2010, at 7:26 PM, Bill van Melle wrote:
>>
>>> Good, the TypeLiteral works okay now. Any idea why the other way doesn't work (using a class that extends ArrayList<Foo>)? Perhaps the element type is hard to find when it's in a parent class.
>>>
>>>
>>
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
On the contrary, I appreciate your help. You have identified several valid issues in some key functional areas. And yes, the lack of non-reified generics can be challenging. :-)
Thanks!
On Nov 24, 2010, at 11:58 PM, Bill van Melle wrote:
> Well, I've certainly made your life difficult, haven't I. I'm sort of surprised you get as much of this right as you do in the face of type erasure. .NET's generics sure have an advantage there.
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
Well, I've certainly made your life difficult, haven't I. I'm sort of
surprised you get as much of this right as you do in the face of type
erasure. .NET's generics sure have an advantage there.
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
Turns out this doesn't work, presumably due to type erasure. I think I'll need to walk up the type hierarchy to find the parameterized Sequence type and get the actual type arguments from that.
On Nov 24, 2010, at 8:17 PM, Greg Brown wrote:
> I see the problem now. When you create a subclass of a generic, it is no longer considered a parameterized type, so the code that obtains the raw type and type parameters from the generic isn't executed. Instead, the actual class type is instantiated, and the item type is set to Object.class. This is wrong - the item type should be obtained by using reflection to get the return value of get(int). The same applies to Dictionary types (get(String) should be used to get the value type).
>
> I'll try to fix this later tonight or tomorrow.
>
> On Nov 24, 2010, at 7:26 PM, Bill van Melle wrote:
>
>> Good, the TypeLiteral works okay now. Any idea why the other way doesn't work (using a class that extends ArrayList<Foo>)? Perhaps the element type is hard to find when it's in a parent class.
>>
>>
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
I see the problem now. When you create a subclass of a generic, it is no longer considered a parameterized type, so the code that obtains the raw type and type parameters from the generic isn't executed. Instead, the actual class type is instantiated, and the item type is set to Object.class. This is wrong - the item type should be obtained by using reflection to get the return value of get(int). The same applies to Dictionary types (get(String) should be used to get the value type).
I'll try to fix this later tonight or tomorrow.
On Nov 24, 2010, at 7:26 PM, Bill van Melle wrote:
> Good, the TypeLiteral works okay now. Any idea why the other way doesn't work (using a class that extends ArrayList<Foo>)? Perhaps the element type is hard to find when it's in a parent class.
>
>
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
Good, the TypeLiteral works okay now. Any idea why the other way doesn't
work (using a class that extends ArrayList<Foo>)? Perhaps the element type
is hard to find when it's in a parent class.
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
Refactoring omission - thanks for catching it. I have checked in a fix.
G
On Nov 23, 2010, at 9:31 PM, Bill van Melle wrote:
> Hmm, change your unit test so that some values are strings rather than ints, and I think you'll see the error.
>
> Looking at the sources, it seems to me that the line where it breaks (in the backtrace I posted earlier) is buggy. I'm not sure why it needs to be testing the variable 'type' at this point, but if so it's surely testing the wrong one. The class has a type field, but you're also passing a type parameter in various recursive calls. If the test in readString needs to be made at all, it should be testing the type that its caller knows about, not the type field in the JSONSerializer class.
>
>
>
> On Tue, Nov 23, 2010 at 5:30 PM, Greg Brown <gk...@mac.com> wrote:
> I just updated the JSONSerializer unit tests to include a test for typed lists, and I didn't run into any problems. See:
>
> http://svn.apache.org/repos/asf/pivot/trunk/core/test/org/apache/pivot/json/test/
>
> I'm using TypeLiteral in this test - I didn't try creating a subclass of ArrayList (though that should work too). Maybe there is some other issue at play here?
>
>
> On Nov 23, 2010, at 8:03 PM, Greg Brown wrote:
>
>> Hm. It definitely works if you define a bean that has a property of type ArrayList<Foo>. I'll see if I can reproduce the issue with just a straight ArrayList<Foo>.
>>
>> On Nov 23, 2010, at 7:41 PM, Bill van Melle wrote:
>>
>>> OK, this is fixed. When JSONSerializer encounters a key that references a non-existent bean property, that value will be ignored.
>>>
>>> Thanks! I updated my build, and it seems to work correctly when encountering unknown properties.
>>>
>>> However, I still have no way to read a typed json list. As I reported earlier in the thread, the TypeLiteral kludge doesn't work, breaking in the serialization code. I also tried your other suggestion of defining a trivial class that extend ArrayList<Foo>. That one doesn't break until I try to read the contents of the list. The serializer does indeed return a ListOfFoo (the trivial class I defined), but the elements of the list are not of type Foo, but rather of type HashMap, presumably the same untyped string/value pairs I'd get were I to just ask for untyped json in the first place.
>>
>
>
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
Hmm, change your unit test so that some values are strings rather than ints,
and I think you'll see the error.
Looking at the sources, it seems to me that the line where it breaks (in the
backtrace I posted earlier) is buggy. I'm not sure why it needs to be
testing the variable 'type' at this point, but if so it's surely testing the
wrong one. The class has a type field, but you're also passing a type
parameter in various recursive calls. If the test in readString needs to be
made at all, it should be testing the type that its caller knows about, not
the type field in the JSONSerializer class.
On Tue, Nov 23, 2010 at 5:30 PM, Greg Brown <gk...@mac.com> wrote:
> I just updated the JSONSerializer unit tests to include a test for typed
> lists, and I didn't run into any problems. See:
>
>
> http://svn.apache.org/repos/asf/pivot/trunk/core/test/org/apache/pivot/json/test/
>
> I'm using TypeLiteral in this test - I didn't try creating a subclass of
> ArrayList (though that should work too). Maybe there is some other issue at
> play here?
>
>
> On Nov 23, 2010, at 8:03 PM, Greg Brown wrote:
>
> Hm. It definitely works if you define a bean that has a property of type
> ArrayList<Foo>. I'll see if I can reproduce the issue with just a straight
> ArrayList<Foo>.
>
> On Nov 23, 2010, at 7:41 PM, Bill van Melle wrote:
>
> OK, this is fixed. When JSONSerializer encounters a key that references a
>> non-existent bean property, that value will be ignored.
>>
>
> Thanks! I updated my build, and it seems to work correctly when
> encountering unknown properties.
>
> However, I still have no way to read a typed json list. As I reported
> earlier in the thread, the TypeLiteral kludge doesn't work, breaking in
> the serialization code. I also tried your other suggestion of defining a
> trivial class that extend ArrayList<Foo>. That one doesn't break until I
> try to read the contents of the list. The serializer does indeed return a
> ListOfFoo (the trivial class I defined), but the elements of the list are
> not of type Foo, but rather of type HashMap, presumably the same untyped
> string/value pairs I'd get were I to just ask for untyped json in the first
> place.
>
>
>
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
I just updated the JSONSerializer unit tests to include a test for typed lists, and I didn't run into any problems. See:
http://svn.apache.org/repos/asf/pivot/trunk/core/test/org/apache/pivot/json/test/
I'm using TypeLiteral in this test - I didn't try creating a subclass of ArrayList (though that should work too). Maybe there is some other issue at play here?
On Nov 23, 2010, at 8:03 PM, Greg Brown wrote:
> Hm. It definitely works if you define a bean that has a property of type ArrayList<Foo>. I'll see if I can reproduce the issue with just a straight ArrayList<Foo>.
>
> On Nov 23, 2010, at 7:41 PM, Bill van Melle wrote:
>
>> OK, this is fixed. When JSONSerializer encounters a key that references a non-existent bean property, that value will be ignored.
>>
>> Thanks! I updated my build, and it seems to work correctly when encountering unknown properties.
>>
>> However, I still have no way to read a typed json list. As I reported earlier in the thread, the TypeLiteral kludge doesn't work, breaking in the serialization code. I also tried your other suggestion of defining a trivial class that extend ArrayList<Foo>. That one doesn't break until I try to read the contents of the list. The serializer does indeed return a ListOfFoo (the trivial class I defined), but the elements of the list are not of type Foo, but rather of type HashMap, presumably the same untyped string/value pairs I'd get were I to just ask for untyped json in the first place.
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
Hm. It definitely works if you define a bean that has a property of type ArrayList<Foo>. I'll see if I can reproduce the issue with just a straight ArrayList<Foo>.
On Nov 23, 2010, at 7:41 PM, Bill van Melle wrote:
> OK, this is fixed. When JSONSerializer encounters a key that references a non-existent bean property, that value will be ignored.
>
> Thanks! I updated my build, and it seems to work correctly when encountering unknown properties.
>
> However, I still have no way to read a typed json list. As I reported earlier in the thread, the TypeLiteral kludge doesn't work, breaking in the serialization code. I also tried your other suggestion of defining a trivial class that extend ArrayList<Foo>. That one doesn't break until I try to read the contents of the list. The serializer does indeed return a ListOfFoo (the trivial class I defined), but the elements of the list are not of type Foo, but rather of type HashMap, presumably the same untyped string/value pairs I'd get were I to just ask for untyped json in the first place.
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
>
> OK, this is fixed. When JSONSerializer encounters a key that references a
> non-existent bean property, that value will be ignored.
>
Thanks! I updated my build, and it seems to work correctly when
encountering unknown properties.
However, I still have no way to read a typed json list. As I reported
earlier in the thread, the TypeLiteral kludge doesn't work, breaking in the
serialization code. I also tried your other suggestion of defining a
trivial class that extend ArrayList<Foo>. That one doesn't break until I
try to read the contents of the list. The serializer does indeed return a
ListOfFoo (the trivial class I defined), but the elements of the list are
not of type Foo, but rather of type HashMap, presumably the same untyped
string/value pairs I'd get were I to just ask for untyped json in the first
place.
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
OK, this is fixed. When JSONSerializer encounters a key that references a non-existent bean property, that value will be ignored.
On Nov 23, 2010, at 1:42 AM, Bill van Melle wrote:
> Yes, you understand correctly.
>
> On Mon, Nov 22, 2010 at 6:44 PM, Greg Brown <gk...@mac.com> wrote:
> So, is the issue that your JSON data contains a key that doesn't exist in the bean class, and a SerializationException is thrown when processing this key? For example, if I have the following JSON:
>
> { foo: "bar" }
>
> and the "foo" property does not exist in the bean, you get the exception? If so, it seems reasonable to discard "foo" in this case. Let me know if my description of the problem is not correct.
>
> G
>
>
>
> On Nov 22, 2010, at 9:21 PM, Bill van Melle wrote:
>
>> And my experience with the preceding now enables me to answer my original question -- you debug serializer errors by attaching the Pivot source, set exception breakpoints on the exceptions that are raised, and poke around on the stack to get some idea of where in the input the deserialization fell over.
>>
>> Doing this, I discovered that JSONSerializer is intolerant of unknown fields. Other serializers I've used are perfectly happy to encounter a field that isn't declared in the user object, and simply throw away the corresponding value. I think it would be great if Pivot did the same. Yes, I can declare all the fields that the server is known to return today, even if I have no use for them, but I'll be in trouble if new fields (that the implementors assume I can just ignore) get added later.
>>
>> Anyway, I found at least two kinds of cryptic errors that occur when an unknown field is encountered: SerializationException -- "Cannot convert <some primitive json type> to null." (several places in the Pivot code), and NullPointerException if the value is an array.
>
>
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
Yes, you understand correctly.
On Mon, Nov 22, 2010 at 6:44 PM, Greg Brown <gk...@mac.com> wrote:
> So, is the issue that your JSON data contains a key that doesn't exist in
> the bean class, and a SerializationException is thrown when processing this
> key? For example, if I have the following JSON:
>
> { foo: "bar" }
>
> and the "foo" property does not exist in the bean, you get the exception?
> If so, it seems reasonable to discard "foo" in this case. Let me know if my
> description of the problem is not correct.
>
> G
>
>
>
> On Nov 22, 2010, at 9:21 PM, Bill van Melle wrote:
>
> And my experience with the preceding now enables me to answer my original
> question -- you debug serializer errors by attaching the Pivot source, set
> exception breakpoints on the exceptions that are raised, and poke around on
> the stack to get some idea of where in the input the deserialization fell
> over.
>
> Doing this, I discovered that JSONSerializer is intolerant of unknown
> fields. Other serializers I've used are perfectly happy to encounter a
> field that isn't declared in the user object, and simply throw away the
> corresponding value. I think it would be great if Pivot did the same. Yes,
> I can declare all the fields that the server is known to return today, even
> if I have no use for them, but I'll be in trouble if new fields (that the
> implementors assume I can just ignore) get added later.
>
> Anyway, I found at least two kinds of cryptic errors that occur when an
> unknown field is encountered: SerializationException -- "Cannot convert
> <some primitive json type> to null." (several places in the Pivot code), and
> NullPointerException if the value is an array.
>
>
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
So, is the issue that your JSON data contains a key that doesn't exist in the bean class, and a SerializationException is thrown when processing this key? For example, if I have the following JSON:
{ foo: "bar" }
and the "foo" property does not exist in the bean, you get the exception? If so, it seems reasonable to discard "foo" in this case. Let me know if my description of the problem is not correct.
G
On Nov 22, 2010, at 9:21 PM, Bill van Melle wrote:
> And my experience with the preceding now enables me to answer my original question -- you debug serializer errors by attaching the Pivot source, set exception breakpoints on the exceptions that are raised, and poke around on the stack to get some idea of where in the input the deserialization fell over.
>
> Doing this, I discovered that JSONSerializer is intolerant of unknown fields. Other serializers I've used are perfectly happy to encounter a field that isn't declared in the user object, and simply throw away the corresponding value. I think it would be great if Pivot did the same. Yes, I can declare all the fields that the server is known to return today, even if I have no use for them, but I'll be in trouble if new fields (that the implementors assume I can just ignore) get added later.
>
> Anyway, I found at least two kinds of cryptic errors that occur when an unknown field is encountered: SerializationException -- "Cannot convert <some primitive json type> to null." (several places in the Pivot code), and NullPointerException if the value is an array.
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
And my experience with the preceding now enables me to answer my original
question -- you debug serializer errors by attaching the Pivot source, set
exception breakpoints on the exceptions that are raised, and poke around on
the stack to get some idea of where in the input the deserialization fell
over.
Doing this, I discovered that JSONSerializer is intolerant of unknown
fields. Other serializers I've used are perfectly happy to encounter a
field that isn't declared in the user object, and simply throw away the
corresponding value. I think it would be great if Pivot did the same. Yes,
I can declare all the fields that the server is known to return today, even
if I have no use for them, but I'll be in trouble if new fields (that the
implementors assume I can just ignore) get added later.
Anyway, I found at least two kinds of cryptic errors that occur when an
unknown field is encountered: SerializationException -- "Cannot convert
<some primitive json type> to null." (several places in the Pivot code), and
NullPointerException if the value is an array.
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
Not much luck yet. Am I doing this right?
Type type = (new TypeLiteral<ArrayList<Foo>>() {}).getType();
getQuery.setSerializer(new JSONSerializer(type));
getQuery.execute(new TaskAdapter<Object>(new TaskListener<Object>() {
@Override
public void taskExecuted(Task<Object> task) {
ArrayList<Foo> result = (ArrayList<Foo>) task.getResult();
showResult(result);
}
@Override
public void executeFailed(Task<Object> task) {
String fault = task.getFault().toString();
showFault(fault);
}
}));
This fails with org.apache.pivot.web.QueryException: 500
org.apache.pivot.serialization.SerializationException: Cannot convert string
to org.apache.pivot.collections.ArrayList<com.fxpal.myunity.Foo>.
If I break on that inner exception, I'm at
JSONSerializer.readString(Reader) line: 389
JSONSerializer.readMapValue(Reader, Type) line: 695
JSONSerializer.readValue(Reader, Type) line: 304
JSONSerializer.readListValue(Reader, Type) line: 600
JSONSerializer.readValue(Reader, Type) line: 302
JSONSerializer.readObject(Reader) line: 272
JSONSerializer.readObject(InputStream) line: 231
GetQuery(Query<V>).execute(Query$Method, Object) line: 474
where it's failing the (type instanceof Class<?>) test. Variables window
shows that type.rawType is Class<T>
(org.apache.pivot.collections.ArrayList).
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
FYI, another thing you can do is create a class that extends ArrayList<Foo> and pass that as the type argument. I'll admit that both approaches are kind of clumsy, but either one should work.
G
On Nov 22, 2010, at 7:36 PM, Greg Brown wrote:
> Ah, OK. You can use the org.apache.pivot.util.TypeLiteral class for this. This class was actually ported from Google Guice.
>
> On Nov 22, 2010, at 7:20 PM, Bill van Melle wrote:
>
>> Not sure exactly what you are trying to do.
>>
>> I'm trying to fill in the blank in
>>
>> query.setSerializer(???);
>>
>> for the case where my web call returns an array of a type that I have declared, i.e., it sends back something of the form
>>
>> [{...instance1...}, {...instance2...}, ...]
>>
>> Java doesn't let me say
>>
>> query.setSerializer(new JSONSerializer(ArrayList<Foo>.class));
>>
>
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
Ah, OK. You can use the org.apache.pivot.util.TypeLiteral class for this. This class was actually ported from Google Guice.
On Nov 22, 2010, at 7:20 PM, Bill van Melle wrote:
> Not sure exactly what you are trying to do.
>
> I'm trying to fill in the blank in
>
> query.setSerializer(???);
>
> for the case where my web call returns an array of a type that I have declared, i.e., it sends back something of the form
>
> [{...instance1...}, {...instance2...}, ...]
>
> Java doesn't let me say
>
> query.setSerializer(new JSONSerializer(ArrayList<Foo>.class));
>
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
>
> Not sure exactly what you are trying to do.
>
I'm trying to fill in the blank in
query.setSerializer(???);
for the case where my web call returns an array of a type that I have
declared, i.e., it sends back something of the form
[{...instance1...}, {...instance2...}, ...]
Java doesn't let me say
query.setSerializer(new JSONSerializer(ArrayList<Foo>.class));
Re: How to debug JSONSerializer errors?
Posted by Greg Brown <gk...@mac.com>.
Not sure exactly what you are trying to do. JSONSerializer allows you to deserialize a JSON array into a typed ArrayList (for example, ArrayList<Foo>). You don't need to use an array for this purpose.
FWIW, deserializing an array will be more performance-intensive than an array list, since the length of the array won't be known until it is completely read. Internally, we'd need to use an array list to build the list, then call toArray() on it to copy its contents into an array. Doesn't seem worth the effort.
On Nov 22, 2010, at 6:24 PM, Bill van Melle wrote:
> More about my bonus question -- this would be a good reason for the JSON deserializer to be able to create Java arrays, not just ArrayLists. That's because I can say Foo[].class, but I can't say ArrayList<Foo>.class. And unfortunately, if I try Foo[].class, Pivot reports this runtime error:
>
> java.lang.RuntimeException: java.lang.InstantiationException: [Lcom.fxpal.myunity.Foo;
>
> which is consistent with the earlier errors.
>
> I notice that GSon claims to be able to deserialize to a Java array. They also have a kludgy workaround for specifying the "class" of an ArrayList<>. The kludge doesn't work in Pivot, though (at least not in the most naive way, of including their library and using their syntax).
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
More about my bonus question -- this would be a good reason for the JSON
deserializer to be able to create Java arrays, not just ArrayLists. That's
because I can say Foo[].class, but I can't say ArrayList<Foo>.class. And
unfortunately, if I try Foo[].class, Pivot reports this runtime error:
java.lang.RuntimeException: java.lang.InstantiationException:
[Lcom.fxpal.myunity.Foo;
which is consistent with the earlier errors.
I notice that GSon <http://code.google.com/p/google-gson/>claims to be able
to deserialize to a Java array. They also have a kludgy
workaround<http://google-gson.googlecode.com/svn/tags/1.1.1/docs/javadocs/com/google/gson/reflect/TypeToken.html>for
specifying the "class" of an ArrayList<>. The kludge doesn't work in
Pivot, though (at least not in the most naive way, of including their
library and using their syntax).
Re: How to debug JSONSerializer errors?
Posted by Bill van Melle <bi...@gmail.com>.
Okay, I found one of them. I had declared classes with actual arrays in
them. When I change
foo[] SomeField;
into
ArrayList<foo> SomeField;
the first error goes away. I suppose it would be nice if the serializer was
willing to store json arrays into java arrays, but I can live with
ArrayLists. And, of course, it would be good to have a better error message
for that case :).