Support for java.util.Optional #1102
Comments
|
Gson can't depend on Java 8 types as it supports down to Java 6. |
|
@JakeWharton So? It could always be in a separate module. |
|
It looks like such a module exists: https://github.com/hsiafan/gson-java8-datatype |
|
really would like to see this. Coming from Swift, the use of Optional with JSON is very useful. |
With Multi-Release JARs this would now be possible, at least for JRE >= 9. |
|
I need this. |
|
I need this to parse all the *.typed json files below Is there a way to generate the POJO given a list of json files? Notice that some of the fields can be |
|
@mleonhard @chakpongchung Did you read the thread? What you want is already there, use it: https://github.com/hsiafan/gson-java8-datatype |
|
@kaqqao gson-java8-datatype worked great, but sadly it broke with Java 16 and isn't maintained anymore (the linked repository is archived).
Java 6 as reached end of life 8(!) years ago, and Java 8 (and thus, Optional) exist for 7 years now. I think it's about time to move on. |
|
I agree that keeping that kind of retro-compatibility over including new useful features for this long might be unreasonable. Java 8 has been around for a long time now |
|
What is the value of supporting Java versions past their end of life? |
ChangeIT is by far the biggest class in the code base: $ find javatests -name '*.java'|xargs wc -l|sort -nr|head -3 7087 javatests/com/google/gerrit/acceptance/api/change/ChangeIT.java 4448 javatests/com/google/gerrit/server/query/change/AbstractQueryChangesTest.java 4025 javatests/com/google/gerrit/server/notedb/ChangeNotesTest.java Git history of this class reveals that the majority of recent activity is related to submit requirements feature. This change extracts all submit requirement related tests in own class: SubmitRequirementIT. Given that another class already exists with a similar name: ChangeSubmitRequirementIT, rename it to SubmitRequirementCustomRuleIT to avoid confusion. Note that these classes cannot be merged in one single test class, because of the assumptions made based on existence of custom rule. Another reason to isolate submit requirement related tests in own class is because at the time of this writing, current implementation of submit requirement violates JEP 403: "Strongly Encapsulate JDK Internals", see [1] and related Issue 15504. The problem is related to usage of Optional class in submit requirement entities and missing Optional type adapter in gson library: [2]. To rectify the usage of Optional in submit requirement serialization we would like to isolate the tests in own Bazel rule and add jvm option: "--add-opens java.base/java.util=ALL-UNNAMED" to this rule. Note that we intentionally do not want to add --add-opens module option to the base junit_tests rule definition to prevent that further violations for JEP 403 are inadvertently added to the code base. [1] https://openjdk.java.net/jeps/403 [2] google/gson#1102 Change-Id: Ica24849bc343c47e6bca22291fc9b8bd282d148f
- now there are also class members of type Optional<?> (instead of wrapping them on-the-fly in the getter) - had to add OptionalTypeAdapter because Gson does not!!! support Optional<?> in 2022 (see google/gson#1102)
eamonnmcmanus
added
the
java8
Usually, when I use Gson, I need to add special logic so that a field of
Optional<X>gets serialized asXif it's present, and gets omitted if it's empty; and conversely on deserialization. This seems like the only reasonable way to handleOptional. Would you consider offering this feature (or accepting a PR that implements it)?The text was updated successfully, but these errors were encountered: