Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am wondering what will be the best approach for word case and word delimiter in JSON
considering that later on the JSON file will be converted to a Java Pojo and i would like this Java Pojo to be in ProperCase
I am debating between:
"sectionSuspensionTiresSteering": [{
"SectionSuspensionTiresSteering": [{
"section_suspension_tires_steering": [{
"section Suspension Tires Steering": [{
I don't really think that JSON has a naming convention, so you can "choose" sort of speak. As I have a Java background, I prefer using camelCase (your first option). I would avoid using blank spaces in the JSON keys, it is allowed but causes problems because most of the existing framework aren't able to deal with it.
So you are free to use the style you want. Regarding the conversion back to Java Pojo, this is just a matter of annotations. When you use for example Jackson, it allows you to annotate your fields in order to convert the JSON file back to a Java Pojo.
Use always the first one:
"sectionSuspensionTiresSteering": [{
Examples of similar files in official guides:
https://spring.io/guides/gs/authenticating-ldap/
As you can see here, the gradle file uses this notation and XMLs files too.
I understand that JSON properties are written in camel case (sectionSuspensionTiresSteering) style.
But it has nothing to do with how the property will be written or coded in java.
For example if you use Gson() to do the conversions between java an JSON you can name the java property whatever you want and annotate the property with #SerializedName("jsonName") passing in the JSON property name.
What I mean is that the two names are not coupled.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have a Stack Overflow question where I'm attempting to use Jython to extract a field value from JSON text:
Jython: Parse JSON object to get value (using Java functions)
A Stack Overflow community member has been kind enough to point me towards some Java documentation:
IBM >> Maximo >> Class JSONObject (Java)
Unfortunately, I've been staring at the Java documentation page for hours now, and to be honest, I have absolutely no idea what I'm looking at.
Where does this documentation show me how to extract a value from JSON text?
In other words, how do interpret this cryptic Java class documentation?
Start here, by passing the JSON string into the parse function.
Then, once you have your JSONObject, you can traverse the tree treating the object as a HashMap.
String jsonInput = "{ 'foo':'bar' }";
JSONObject jsonObject = JSONObject.parse(jsonInput);
String fooValue = jsonObject.get('foo');
Of course, this is the hard way. You might consider a more fluid library like JsonPath, which also has documentation that's more fluid.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
The javase docs state:
toString()
Returns a string representation of the object. In general, the toString method returns a string that "textually represents" this object. The result should be a concise but informative representation that is easy for a person to read. It is recommended that all subclasses override this method.
When handling an object with multiple parameters is it good practice to format the output to display nicely formatted in the console? The default eclipse generated implementation concatenates the variables in a single line which gets troublesome to read, needing to scroll back and forth multiple times and does not group the parameters logically.
I would like to format the output inserting line breaks, but have never actually seen someone doing this before. Will I eventually run into issues with loggers or anything else or is it perfectly fine to format the output of toString()the way I want?
Is it better to implement a additional method toStringPretty()?
Usually it is not discouraged to avoid producing multi-line string from toString().
as java doc said it should be concise and informative but if you find yourself in a situation where lots of field should be formatted and represented in log file, notice that nobody looks for pretty log. the log should be searchable with regex to facilitate the finding what you are looking for.
What i can suggest you is that instead of formatting multi-line for readability in log file, print your elements in a single line Json format which is both easy to read and search, but if you what to show an output on console to the user it is better off to extract the formatting logic outside of the toString()
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I currently ran into a requirement of having the data dynamically imported into MySQL database (But by using java).
I am not sure what is the best practice for this but let me put forward my scenario.
The json can be dynamic and its uncertain of what will be in the json each time I read from an API endpoint
for example:
"table1" : {
"field1" : "value1",
"field2" : "value2",
"field3" : "value3"
}
One time the json will be like this
the other time it might be like
"table2" : {
"field1" : "value1",
"field2" : "value2",
"field3" : "value3",
"field4" : "value4"
}
so my question is should I parse the json and compare it with the fields in table which matches the json name?
or is there any library available in java which will enable me to easily and efficiently handle this.
NOTE: I have to prepare this as a service which will continously scan a given API after certain interval and the respective JSON needs to get imported into the table it belongs, and if the table doesn't exist then it must get automatically created.
Thanks all for your patient reading and support, this is a new kind of requirement which I have never handled.
Thank you in Advance!
You can use google-gson or jackson api to make your code more efficient
In my project i used google-gson API. It worked very well and it was painless.
You can find the project with it's description here.
Below is a simple example from API docs wich supports multi-dimensional arrays, with arbitrarily complex element types:
Collections Examples
Gson gson = new Gson();
Collection<Integer> ints = Lists.immutableList(1,2,3,4,5);
// Serialization
String json = gson.toJson(ints); // ==> json is [1,2,3,4,5]
// Deserialization
Type collectionType = new TypeToken<Collection<Integer>>(){}.getType();
Collection<Integer> ints2 = gson.fromJson(json, collectionType);
// ==> ints2 is same as ints
Hope this helps.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I have recently started using JSON and was wondering if I am missing any other important reasons as to why I would use a JSON object instead of just returning a large string of data.
Here is what I have found so far:
A JSON object is a lot faster to process, easier to handle and parse. A JSON object is easier for a human to read compared to a big string of data output. JSON objects can be mapped easier and works well with object oriented systems.
JSON is just a [large] string of data.
The difference from a one-off/custom "blob'o'test" encoding is that JSON is a well-defined format that supports common ADTs (Arrays, Maps) and is a useful interchange format. Also, one doesn't work with JSON (which is just text) directly; one works with the object-graphs that are serialized to/from JSON - e.g. once you call JSON.parse(jsonText) you're dealing with regular objects.
While XML is another well-defined format, JSON has a better 1-1 mapping with simple object-graphs. This easier mapping eliminates the need for a specific DOM wrapper or other specialized access - who wants to deal with an object model when one can treat an object-graph as first-class data?1
The fact that JSON (which is just text) also looks like normal JavaScript Object Literal Notation (and excluding some odd Unicode issues, is a subset) makes human consumption relatively easy and has greatly helped the adoption.
Refer to the following questions for additional insight on "What?" and "Why?"
What is JSON and why would I use it?
What is the exact use of JSON?
Why use JSON instead a normal html output with AJAX?
Why is it a bad practice to return generated HTML instead of JSON? Or is it?
https://stackoverflow.com/questions/3536893/what-are-the-pros-and-cons-of-xml-and-json
Why is Everyone Choosing JSON Over XML for jQuery?
1 XML is much more than a simple markup format, but comparing XML to JSON in any more detail is outside the scope of the question.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In Java, there's a naming convention for classes, interfaces, packages, methods, variables and constants. I'm just wondering if there is a naming convention for JSF XHTML pages.
Here are a few variants that came up to my mind:
MyPage.xhtml
myPage.xhtml
my-page.xhtml
mypage.xhtml
There's no need to think of xhtml pages as something different from plain html pages. In the end, if a user has to type it out, then it would help to have a simple page name (just like we would name any html page).
To give you an example, even a company like Apple who are so specific about using the correct case for their products, still maintain a URL such as http://www.apple.com/iphone! (iPhone is written as iphone)
To summarize I would say, don't use capital letters in URL, and try not to use special characters either.
Camel-case starting with a lowercase letter is good, I use hyphens to distinguish modules/ subpages/ subelements.
For example:
productList.xhtml
productEdit.xhtml
productEdit-buttons.xhtml
productReport.xhtml
customerAddress.xhtml
customerAddress-map.xhtml
Not a formal convention, but it works well. Being able to modularize or identify fragments or sub-functions is useful.