-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow configuring the newLine used on Gson.toJson #776
Comments
Ideally, GsonBuilder should have a setFormattingStyles(String style) method that should determine the entire formatting. But we have never had time to research and find a good format to specify this. Suggestions welcome. Until then, you can use Gson.toJsonTree() and format the output yourself. |
Originally posted by @eamonnmcmanus in #2231 (comment) Hi, just back from vacation. :-) My initial reactions:
public class FormattingStyle {
private final String newline;
private FormattingStyle(String newline) {
this.newline = newline;
}
public static final FormattingStyle DEFAULT = new FormattingStyle("\n");
public FormattingStyle withNewline(String newline) {
return new FormattingStyle(newline);
}
} which would evolve in the expected way if we add other parameters like indent. I don't think it is really necessary to have constants for the kinds of newline style. We can certainly document the two prevailing styles, and perhaps require that the I'll also note, playing Devil's Advocate a bit, that it's pretty easy to do |
Originally posted by @mihnita in #2231 (comment)
That's true, and it is something I did for years (and it annoyed me for years :-). So, there are workarounds, but at the core this makes the people who need Windows EOL feel like second class citizens. When the JSON spec (and ECMAScript spec) does not specify a certain EOL as preferred, they accept all the valid combinations. In fact there is an effort to update the spec to also allow for Anyway... Maybe move this discussion into an issue, so that you can review the direction before I implement something debatable? I would probably go with a more "fluent" Thank you, |
Thanks for those further details! I'm not reading the business about LINE SEPARATOR and PARAGRAPH SEPARATOR the same as you. My understanding is that JavaScript previously did not allow these characters unescaped inside string literals, while JSON always has. So "a For the I wouldn't be averse to having |
Thanks, I'll go ahead with It is your call if it is handy to define some constants (CR / CRLF / LF / OS_DEFAULT / WINDOWS / MACOS / LINUX / ...)
That was my attempt to separate the creation part discussion ( I might need to properly read that LINE SEPARATOR / PARAGRAPH SEPARATOR proposal, maybe do some tests. |
And then how to igore newlines? |
@BruceLin2000, what do you mean by that? Could you please show a small example of want the JSON data to look like? Note that the changes for this feature here introduced by pull request #2231 have not been released yet. |
When will version with this feature be released? |
…#2231) * Add settings for kind of newline to use * Fix amp in javadoc * Fixing link in javadoc * Doc: use JSON instead of Json Co-authored-by: Marcono1234 <[email protected]> * PR Feedback: Objects.requireNonNull Co-authored-by: Marcono1234 <[email protected]> * PR Feedback: $next-version$, don't hardcode Co-authored-by: Marcono1234 <[email protected]> * s/testNewlineLF/testNewlineLf/ Co-authored-by: Marcono1234 <[email protected]> * Implement PR feedback * Round two of review * Restore copyright year, no reason to update * Rename OS named enum values to CR and LF * Add javadoc to NewlineStyle.getValue() * Implement PR feedback, round 2 * Fix typo Co-authored-by: Marcono1234 <[email protected]> * No need for line break Co-authored-by: Marcono1234 <[email protected]> * Shorter, cleaner doc Co-authored-by: Marcono1234 <[email protected]> * Using a FormattingStyle for pretty print * Fix Junit4 and Truth after merge from master * Implement review feedback * Double backslash in message --------- Co-authored-by: Marcono1234 <[email protected]>
Currently (version 2.5) there's no way to use Windows new lines on Gson, being able to configure this would be nice.
Also some old software doesn't like files that don't have a dangling new line at the end of the JSON, being able to configure this would be nice as well.
The text was updated successfully, but these errors were encountered: