Skip to content
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

Serialization and Deserialization of Type and Class #340

GoogleCodeExporter opened this issue Mar 19, 2015 · 2 comments

Serialization and Deserialization of Type and Class #340

GoogleCodeExporter opened this issue Mar 19, 2015 · 2 comments


Copy link

I have a class like 

Class Function {

public int functionId;
public Type functionId;
public String functionName


public void static main ()
                Function fc= new Function();        

        Type tmp = new Integer(100).getClass();
        Gson gson = new GsonBuilder.create();
        System.out.println(gson.togson(fc) );

I am getting {} ie null for functionType Filed.
What is the issue here ? am I missing something

Original issue reported on by on 1 Jul 2011 at 5:23

Copy link

Please post coding questions like this on our Google Group 
(!forum/google-gson) instead of creating bug 

Not sure if your example is correct. Here are a few suggestions:
new GsonBuilder().create() is same as new Gson()

You are not using Type tmp anywhere. 
In any case, you can get it simply as: Integer.class or int.class

gson.toJson() should print all the fields of Function. Please post complete 
working code on Google group and someone will be able to help you better.

Original comment by inder123 on 1 Jul 2011 at 9:54

  • Changed state: Invalid

Copy link

Serializing types is actually somewhat of a security problem, so we don't want 
to support it by default. A malicious .json file could cause your application 
to load classes that it wouldn't otherwise; depending on your class path 
loading certain classes could DoS your application.

But it's quite straightforward to write a type adapter to support this in your 
own app.

Original comment by limpbizkit on 1 Jul 2011 at 9:56

jalkire added a commit to microsoft/accessibility-insights-for-android-service that referenced this issue Jun 11, 2021
…sSerializer (#108)

#### Details
This PR introduces `ATFAResultsSerializer`, which will be used to serialize ATFA Results. `ATFAResultsSerializer` adds three pieces of custom behavior to the default `gson.toJson` behavior:

1. Custom `FieldNamingStrategy`. Without this, serialization fails because of duplicate field names. By prepending the class name containing the field, the duplicates are rendered unique. 
2. Custom `ExclusionStrategy`. Without this, circular references between ViewHierarchyElement and WindowHierarchyElement as well as WindowHierarchyElement and `AccessibilityHierarchy` cause serialization to fail. We do not expect to need any data from `WindowHierarchyElement` or `AccessibilityHierarchy`, so we solve this be excluding them from serialization. 
3. Custom `TypeAdapter` for `Class`. Gson is [intentionally unable to serialize Types by default](google/gson#340 (comment)). Since we will not be deserializing this JSON in Java, we don't have to worry about the security concern. As such, we just serialize the Class as its name.

This PR simply introduces `ATFAResultsSerializer`; a future PR will put it to use. There is no impact on functionality.

##### Motivation
We need to serialize ATFA Results to return them to the client.

##### Context
Custom behavior 2 from above had two main alternatives. 
1. Serialize one way, from `ViewHierarchyElement` --> `WindowHierarchyElement` --> `AccessibilityHierarchy`, but not the back references up the circle.
2. Serialize all data, but massage the back references such they they don't break gson serialization.

We chose to serialize the smallest subset of data we expect to need, as we can always add more later. If it turns out we need some of the data in `WindowHierarchyElement` or `AccessibilityHierarchy`, we can implement option 1 as necessary. If it turns out we need to access the full graph of references, we can implement option 2 as necessary. 

#### Pull request checklist
<!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox -->

- [n/a] Addresses an existing issue: #0000
- [x] Added/updated relevant unit test(s)
- [x] Ran `./gradlew fastpass` from `AccessibilityInsightsForAndroidService`
- [x] PR title _AND_ final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

1 participant