Sometimes, we need to create some thrift objects in unit tests. We can do it by manually create object using Java code, like:
MyObj myObj = new MyObj();
myObj.setName("???");
myObj.setAge(111);
But which is not convenient. I'm looking for a way to create objects with some readable text.
We can convert thrift objects to JSON with TSimpleJSONProtocol, and get very readable JSON string, like:
{ "name": "???", "age": 111 }
But the problem is TSimpleJSONProtocol is write only, thrift can't read it back to construct an instance of MyObj.
Although there is a TJSONProtocol which supports to serialize and deserialize, but the generated JSON is not readable, it uses a very simplified JSON format and most of the field names are missing. Not convenient to construct it in tests.
Is there any way to convert thrift objects to readable string and also can convert it back? If TSimpleJSONProtocol supports converting back, which is just what I'm looking for
The main goal of Thrift is to provide efficient serialization and RPC mechanisms. What you want is something that is - at least partially - contrary to that. Human-readable data structures and machine processing efficiency are to a good extent conflicting goals, and Thrift favors the latter over the former.
You already found out about the TSimpleJson and TJson protocols and about their pros and cons, so there is not much to add. The only thing that is left to say is this: the protocol/transport stack of Thrift is simple enough.
This simplicity makes it possible to add another protocol based on your specific needs without much or overly complicated work. One could probably even write an XML protocol (if anyone really wants such bloatware) in short time.
The only caveat, especially vis-à-vis your specific case, is the fact that Thrift needs the field ID to deserialize the data. So you either need to store them in the data, or you need some other mechanism which is able to retrieve that field ID based on the field and structure names.
Related
I want to create a library which will do the authentication stuff (sending some authentication parameters along the request) and return the json response from an API. The JSON will usually represent an array of dictionaries, something like this:
[
{"a": 1, "b": 2},
{"a": 3, "b": 1}
]
I have done the same thing in Python and there it was no-brainer, I just return a dict which is builtin in Python.
I was wondering what would be the best way in Java? Here are some of the approaches I consider:
Returning a stream which will be handled by user. Specifically, I use java.net.HttpURLConnection and by this approach I will return connection.getInputStream() which will be handled by the user. The drawback of this approach is that the user would need to do great part of the job (reading the stream and converting it to json-like object or whatever). The good part is the users will have flexibility to process it in any way they like, creating custom objects from classes, using third party json libraries or something else. By this approach I don't force them to use some library, because the whole code will use Java builtin functionalities.
Use third party library, like org.json or GSON and return that kind of object. The drawback here is that I'll force the user to use third party library.
I could define classes for each kind of objects, there would be probably 5-6 type of classes. The drawbacks are: I will need more time to implement the solution and will force the user to use my objects.
What bothers me is that Python developers very often use dict, while in Java the developers most often prefer to work with objects of specific user defined classes. So, I can't conclude what would be the most appropriate way.
Any endpoint for an HTTP API has a defined response structure (or at least it should). The methods implemented by your library should return a POJO that represents the response payload. The end user should not need to be aware that the API formats the payload in JSON. If the API one day decides to use XML, that change should be transparent to the users of your library.
Edit: simply returning a dictionary, or map type is bad practice. Doing so forces users of your library to assume the key strings and value type of each property in the response. A POJO provides a clear definition of the response property names and their value types.
I have the following declaration of the static type Object:
Integer typeId;
//Obtaining typeId
Object containerObject = ContainerObjectFactory.create(typeId);
The factory can produce different types of container objects, e.g. Date, Integer, BigDecimal and so forth.
Now, after creating the containerObejct I need to serialize it to an object of type String and store it into a database with hibernate. I'm not going to provide Object-relational mapping because it doesn't relate to the question directly.
Well, what I want to do is to serialize the containerObject depending on it runtime-type and desirialize it later with the type it was serialized. Is it ever possible? Could I use xml-serialization for those sakes?
There are numerous alternatives, and your question is quite broad. You could:
use the native Java serialisation, which is binary, and then Base64 encode it
use an XML serialisation library, such as XStream
use a JSON serialisation library, such as Gson
One key feature you mention is that the object type needs to be embedded in the serialised data. Native Java serialisation embeds the type in the data so this is a good candidate. This is a double-edged sword however, as this makes the data brittle - if at some time in the future you changed the fully qualified class name then you'd no longer be able to deserialise the object.
Gson, on the other hand, doesn't embed the type information, and so you'd have to store both the JSON and the object type in order to deserialise the object.
XML and JSON have advantages that they're a textual format, so even without deserialising it, you can use your human eyes to see what it is. Base64 encoded Java serialisation however, is an unintelligible blob of characters.
There are multiple ways, but you need custom serialization scheme, e.g.:
D|25.01.2015
I|12345
BD|123456.123452436
where the first part of the String represents the type and the second part represents the data. You can even use some binary serialization scheme for this.
I'm working on an Android app. The app gets the data as JSON string (name of universities and student lists) and manipulate the app according to the data.
What will be a better approach?
Create a new Object and parse the JSON string into it, and work with the object, or
Keep the JSON string, and just use JSONObject whenever I need to grab information from the string
Or any other way?
If I'm using the new Object, how can I transfer (or share) the object with other activities in the app?
I know that for string we can use putextra().
Use objects.
I would suggest to use Jackson library,
be cause it is very fast and easy to ingrate.
You can find code examples here :
http://www.mkyong.com/java/how-to-convert-java-object-to-from-json-jackson/
P.S. : Jackson is not the only library for this approach > Jackson Vs. Gson
I almost always parse the JsonObject into a specific object E.g. class University.
One benefit of doing this, is you can put it nicely into collections. E.g. HashMaps, Set or just straight List. When dealing with it as a JsonObject you won't be able to as easily work with it.
You can do things like sort it if you Object inherits Comparable, and can define equals/toString/hashCode.
There are a number of other benefits, but I think you'll find holding that data in a real data structure will give you the most benefit
I would recommend parsing the string (or using a library to do this for you!) and filling an object. This way, your model object can control the data and how it is shared with other objects, and use internal data structures to optimize usage. If you stuck with the JSON string you'd end up parsing it multiple times to pull out data.
However you decide to share the object/string across activities shouldn't affect your decision for how to model the data. You'll likely end up passing it across activities in any case.
I suggest that you use objects too.
You can use Gson library to do any conversion between json string and objects. It is very, very easy to use. http://code.google.com/p/google-gson/
To transfer the data between other activities you can make your object implement the Serializable interface, this way you can use the .putExtra() and pass it forward.
For example, I have a JSON format like this:
{"class":"MySpecialClass", "attri1":"value1", "attri2":"value2"}
I would like to create a Object, which is a MySpecialClass Object, and get two attribute, attri1 and attri2 with the value of value1 and value2.
Here is the requirement:
I have a class file, named, MySpecialClass, and have attri1, and attri2, can I create this object, and assign the value in this?
I DONT'T have the class file MySpecialClass, I would like to generate it on the runtime, is this possible to do so? Thanks.
Your first case is perfectly feasible using any Java/JSON parser.
Your second case is possible, but hard work.
You can construct classes at runtime using bytecode engineering - e.g. using Apache BCEL. Note that the JSON will contail fields only, and not behaviour nor type.
Take a look at https://github.com/google/gson it does what you want
You want a JSON processor, like Jackson. I'm not sure you can easily do your second case this way, for that you may be best looking at a JVM JavaScript implementation unless you want to get into stuff like on the fly bytecode manipulation. There's one in the Java6 runtime.
I am doing a new application where I want to choose which protocol to use in it. I tried the String concatenation and the XML before, but never tried the JSON Object. Well Which one of those three is better in terms of performance? I am aware that XML is way much better than string concatenation. So what to use? XML or JSON? Or maybe a new technology that I am not aware of?
Thanks in advance
I am aware that XML is way much better than string concatenation. Well in this I mean that in String concatenation, I am adding different values and splitters to a string and then looping to find the spliters on the device. like in the example:
String toSend = "test1////test2////test3////test4////test5";
Here the splitter is "////" and I am sending 5 values. Getting these 5 values will be much more slower than XML in case of thousands of values.
It depends. :)
Well, actually I think a properly written code to split a string will be more fast than an XML/JSON parser, however XML/JSON parsers are reliable in terms of returning exactly the same data structure. For instance, how would you handle a case when your data itself includes splitters? If such case is impossible under your business logic, then you may just go with string joining/splitting. Otherwise it is better not to reinvent the wheel and just use XML/JSON (JSON is more lightweight).
It depends on the kind of Objects you will be exchanging.
It also depends on the way you will request and use you objects.
If you want ot provide a REST service that exposes simples Objects will be accessible directly by as Javascript GUI. I would also go for JSON. But no hand-made String concatenation to build JSON. You can use a lib.
But I you plan to exchange more complex data, between various Java based "services". I would probably go for XML. Especially if you can first write the XSD that defines you XML objects. You will be able to generate Java class and let JAXB do the marshalling/unmarshalling boring stuff.
I would choose JSON, it's very portable and lightweight (lighter than XML).