Highlevel API

[GoogleCodeExporter]

This milestone will add a highlevel API acess, which can be used instead of raw 
JSON data.
The highlevel API access will be complete object driven, without any primitive 
types.

Original issue reported on code.google.com by Varonth87 on 29 May 2013 at 11:48

[GoogleCodeExporter]

Original comment by Varonth87 on 29 May 2013 at 11:50

• Added labels: Milestone-0.2
• Removed labels: Milestone

[GoogleCodeExporter]

So first version of the high level API is now available.

Original comment by Varonth87 on 30 May 2013 at 2:26

• Changed state: Milestone-RC

[GoogleCodeExporter]

Hello,

You made a great work !

But, I can't undeerstand why you use objects instead of primitive int.

All the boxing (cast) done when you create an object is expensive, it will slow 
the execution.

May be you have an idea I didn't see ? 

Original comment by Giry.Geo...@gmail.com on 31 May 2013 at 9:03

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Since Java5 the object can be used just like primitives due to auto boxing.
http://en.wikipedia.org/wiki/Autoboxing#Autoboxing

On the other hand, having objects instead of primitives directly allows for 
direct use of all the small features the wrapper class of that primitive uses.

It can also be used in a much wider variety of generic template classes.

And accessing the data of an Integer intWrap via int i = intWrap.intValue() 
should be the same as saving one int to another, like a int k = 2:  int i = k;

And if you take a look at the Integer class source code, you will see that it 
just has 1 field. private final int value; And the Constructor will just set 
that field. Space allocation would be done by java for an int anyway.

That is also how the auto boxing should work. I don't work at oracle, but since 
an Integer or any other wrapper class just saves an instance of the primitive, 
it just has to allocate the same space it would need for that primitive. Now 
you have an object pointer, but if you want to use the data as primitive you 
can just get a primitive pointer and let him point to the same data the wrapper 
points to.

TL;DR:
Wrapper classes have minimal to no impact on performance, and creating them is 
not more or if just a really tiny bit more expensive than using primitives.

Original comment by Varonth87 on 31 May 2013 at 11:38

[GoogleCodeExporter]

I agree with you, on the paper they are the same, but the VM optimize primitive 
much better than objects.

Original comment by Giry.Geo...@gmail.com on 31 May 2013 at 12:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Creating will often require the wrapper class anyway, as we often get Strings 
when it is an implicit Integer. So in the case I would have to use 
Integer.parseInt(String s) or new Integer(String s).intValue() anyway.
Why not save it as an Object then instead. If you want to use that as a 
primitive, you can just access it as such once and save that value in a 
primitive.

Yes some of them can actually be directly returned to an int primitive, because 
the JSON data is actually and int value instead of a string. But if I would 
save those as an int then, it would become pretty incosistent.
If I would on the other hand unwrap all the objects into their respective 
primitive, and a user( or even I) needs the primitive wrapped again, for 
example to store them in a collection object, then they would have to undo a 
step I did before, which will impact performance even more (make step to 
unwrap, save primitive, use primitive to undo step and wrap it again).

Original comment by Varonth87 on 31 May 2013 at 12:55

[GoogleCodeExporter]

View this way, it's probably better.

Original comment by Giry.Geo...@gmail.com on 31 May 2013 at 2:26