Repository navigation
Not Working At All for java bean serialization. #480
Description
Refer to following example. Bean serialization not working at all.
Version : 20190722
Java Version : JDK 12
`class test {
private int a;
private int b;
public test(int a, int b) {
this.a = a;
this.b = b;
}
public int getA() {
return a;
}
public void setA(int a) {
this.a = a;
}
public int getB() {
return b;
}
public void setB(int b) {
this.b = b;
}
public static void main(String[] args) {
System.out.println(new JSONObject(new test(1, 2)));
}
}`
Output : {}
Activity
[-]Not Working At All for java objects.[/-][+]Not Working At All for java bean serialization.[/+]stleary commentedon Aug 12, 2019
Seems to work for me:
{"a":1,"b":2}
In your test, try using System.out.println(new JSONObject(new test(1,2)).toString());
stleary commentedon Aug 18, 2019
Closed due to not expecting more activity.
KrishnaST commentedon Aug 19, 2019
Not Working.
stleary commentedon Aug 19, 2019
OK I am convinced you are seeing this. Will try to recreate and let you know.
KrishnaST commentedon Aug 19, 2019
The 'opens' directive to expose specific packages for reflective access was missing. adding 'opens' solved the issue. Usually it should throw an error if package is not opened for reflective access.
Thanks.
KrishnaST commentedon Aug 19, 2019
It also fails to serialize JDK internal classes such as Map. Failed to serialize following.
System.out.println(new JSONObject(Map.of(0, "A", 1, "B")).toString()); simply outputs {}.
johnjaylward commentedon Aug 19, 2019
I'm not familiar with this terminology, can you post the relevant configuration sections?
KrishnaST commentedon Aug 20, 2019
The java 9+ module system requires the packages to be declared as 'open' for reflective access. Refer To https://www.baeldung.com/java-9-modularity
johnjaylward commentedon Aug 20, 2019
@KrishnaST so it sounds like you had to set the "open" on your module, not the JSON module.
For the Map, that doesn't use any reflection to process the map. Can you try to create the map in a separate step from the JSONObject constructor?
I'm curious if the Map.Of is causing a problem for some unknown reason. It obviously shouldn't... but I'd just like to confirm if you don't mind.
johnjaylward commentedon Aug 20, 2019
Also, on a side note for the reflection, we specifically test that the methods we are reflecting are public. From the documentation link you sent, the "open" flag should not have caused an issue since that's supposed to only affect private members.
GedMarc commentedon Aug 20, 2019
If the package is not exposed in any way (either through exports or through open),
Whether public or private there will be no access to any reflection.
Exporting a package will grant access to the Public API within that package, inclusive of public getters and setters, however no field access will be allowed. This also incurs a minor performance penalty.
Opening a package places the package into the java.base/ module (in modular mode for automatic named or for strictly named modules) - or into the UNNAMED section if an obsolete jar (no automatic name (reserved name), no module-info), yielding heavy performance losses and should be avoided at all costs.
I also see no progress on my PR, is this another no follow up no pull item? Starting to feel like i'm wasting my time.
johnjaylward commentedon Aug 20, 2019
@GedMarc from your experience, would doing a new release with your package changes fix issues like this one?
GedMarc commentedon Aug 20, 2019
@johnjaylward Yes it will fix everything, No there is a decision that needs to be decided on whether to place the module-info.class file in the JDK9 location of classpath root, or to move it into META-INF/versions/9
(https://www.javaworld.com/article/3184029/java-9s-other-new-enhancements-part-4-multi-release-jar-files.html)
Placing it in the root causes class indexes to do strange things (not break, e.g. jandex less than 2.0.4 will output unreadable classes, so everything less than wildfly 14 affected will just get a lot of logging), but it will last for all future releases.
Placing it into the temporary meta-inf referencing such as /versions will circumvent this - but only for a certain period as it's all being moved across into the modular definitions (services e.g. have already been ported into module-info with the "provides" and "uses" clause)
As for specifying module exports and requires, those will remain but those are not bugs.
GedMarc commentedon Aug 20, 2019
@KrishnaST "The java 9+ module system requires the packages to be declared as 'open' for reflective access"
Try
in your module-info, they do mean that you need to open your package, in case it's a concern
WRT the java.base not being accessible, there is currently no way to "extend" a module class and any exposures or reflections to the java.base must be specified in the command line. This is a good habit to get into early.
stleary commentedon Jan 5, 2020
Closed due to inactivity.