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

Java 9 support: use Unsafe-based reflection in Java 9+ #1218

Merged
merged 7 commits into from Jan 3, 2018

Conversation

Projects
None yet
6 participants
@amogilev
Contributor

amogilev commented Jan 1, 2018

Fixes "illegal reflective access" warnings and exceptions, like one in #1216

Java 9 support: use Unsafe-based reflection in Java 9+
fixes "illegal reflective access" warnings and exceptions

@googlebot googlebot added the cla: yes label Jan 1, 2018

@inder123

This comment has been minimized.

Show comment
Hide comment
@inder123

inder123 Jan 2, 2018

Collaborator

Thanks for the PR

Collaborator

inder123 commented Jan 2, 2018

Thanks for the PR

@JakeWharton

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Jan 2, 2018

Member

All of these classes should be in internal. They're not public API.

Member

JakeWharton commented Jan 2, 2018

All of these classes should be in internal. They're not public API.

@amogilev

This comment has been minimized.

Show comment
Hide comment
@amogilev

amogilev Jan 2, 2018

Contributor

@inder123 Thanks for the review, I have changed the code according to your comments.
@JakeWharton Do you mean that the code shall be moved to the package 'com.google.gson.internal.reflect'? Guess it makes sense...

Contributor

amogilev commented Jan 2, 2018

@inder123 Thanks for the review, I have changed the code according to your comments.
@JakeWharton Do you mean that the code shall be moved to the package 'com.google.gson.internal.reflect'? Guess it makes sense...

amogilev added some commits Jan 3, 2018

@inder123

This comment has been minimized.

Show comment
Hide comment
@inder123

inder123 Jan 3, 2018

Collaborator

Thanks for patiently incorporating all the feedback

Collaborator

inder123 commented Jan 3, 2018

Thanks for patiently incorporating all the feedback

amogilev and others added some commits Jan 3, 2018

@googlebot

This comment has been minimized.

Show comment
Hide comment
@googlebot

googlebot Jan 3, 2018

Collaborator

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

Collaborator

googlebot commented Jan 3, 2018

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@googlebot googlebot removed the cla: yes label Jan 3, 2018

@googlebot googlebot added the cla: no label Jan 3, 2018

@inder123 inder123 merged commit 8445689 into google:master Jan 3, 2018

2 of 3 checks passed

cla/google CLAs are signed, but unable to verify author consent
Codacy/PR Quality Review Good work! A positive pull request.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@swankjesse

This comment has been minimized.

Show comment
Hide comment
@swankjesse

swankjesse Jan 3, 2018

Collaborator

I think this might be the wrong solution to the problem. Unfortunately, the right solution to this problem is a lot of work.

Instead of using a bigger, more powerful weapon to read & write platform types, I think Gson should have a new java-platform-typeadapters module.

Wherever Gson’s users are relying on reflection to read+write a platform type like java.util.UUID, we should handwrite a type adapter. That way we avoid getting into an arms race with the JDK maintainers who really don’t want their fields to be reflected upon.

Collaborator

swankjesse commented Jan 3, 2018

I think this might be the wrong solution to the problem. Unfortunately, the right solution to this problem is a lot of work.

Instead of using a bigger, more powerful weapon to read & write platform types, I think Gson should have a new java-platform-typeadapters module.

Wherever Gson’s users are relying on reflection to read+write a platform type like java.util.UUID, we should handwrite a type adapter. That way we avoid getting into an arms race with the JDK maintainers who really don’t want their fields to be reflected upon.

@swankjesse

This comment has been minimized.

Show comment
Hide comment
@swankjesse

swankjesse Jan 3, 2018

Collaborator

... anyone who wants to use Gson with Java 9 to read+write platform types would need this module. And the Gson-using community would have to built the module to cover as many types as is reasonable.

Collaborator

swankjesse commented Jan 3, 2018

... anyone who wants to use Gson with Java 9 to read+write platform types would need this module. And the Gson-using community would have to built the module to cover as many types as is reasonable.

@JakeWharton

This comment has been minimized.

Show comment
Hide comment
@JakeWharton

JakeWharton Jan 3, 2018

Member

Strongly agree #1216 (comment). The module system is the opportunity to enforce something which never should have been allowed!

Member

JakeWharton commented Jan 3, 2018

Strongly agree #1216 (comment). The module system is the opportunity to enforce something which never should have been allowed!

@inder123

This comment has been minimized.

Show comment
Hide comment
@inder123

inder123 Jan 3, 2018

Collaborator

@swankjesse Agree with you. We can start on adding some of these type adapters, and build upon it gradually.

Collaborator

inder123 commented Jan 3, 2018

@swankjesse Agree with you. We can start on adding some of these type adapters, and build upon it gradually.

sebasjm pushed a commit to sebasjm/gson that referenced this pull request Mar 11, 2018

Java 9 support: use Unsafe-based reflection in Java 9+ (google#1218)
* Java 9 support: use Unsafe-based reflection in Java 9+

fixes "illegal reflective access" warnings and exceptions

* fix Codacy warnings

* improve code quality based on PR review

* improve code quality based on PR review

* fix Codacy warning

* improve code quality based on PR review

* inlined createReflectionAccessor method
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment