jvmti, reflection, getInterfaces and ctor comments #1
Conversation
Signed-off-by: Dan Heidinga <heidinga@redhat.com>
|
Hi @DanHeidinga, welcome to this OpenJDK project and thanks for contributing! We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user DanHeidinga" as summary for the issue. If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing |
DanHeidinga
changed the title
| @@ -613,12 +622,28 @@ and that `I` is really (somehow) an exotic (`Q`-like) descriptor for | |||
| `int.val`. The `L` descriptor returns `int.ref.class`, while the | |||
| exotic descriptor returns `int.val.class`. | |||
|
|
|||
| [ Which mirror defines the fields for apis like `getFields()`?] | |||
There was a problem hiding this comment.
Discussed on today's call and the conclusion was that there is a single set of metadata shared by both mirrors. So it doesn't matter which is used in reflective getX operations
| * How do we treat the two mirrors generated from a single primitive classfile? | ||
| * Is the `ref` version marked as non-modifable (treating the `val` one as the `true` | ||
| class)? | ||
| * Does the CFLH get called once (for the classfile) or twice (for `val` & `ref`)? |
There was a problem hiding this comment.
From today's call, there is a single set of metadata so 1 CFLH will be called. Redefining either mirror is OK and affects both.
| muster if we were designing the feature without the weight of existing test | ||
| suites. Are there other concerns than the existing test suites? Given the | ||
| other more significant changes in the ecosystem, I'm unclear why this one | ||
| is worth avoiding.] |
There was a problem hiding this comment.
Agreement on today's call was to not hide the injected interfaces and use the preview phase to judge the fallout
|
/covered |
|
Thank you! Please allow for a few business days to verify that your employer has signed the OCA. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated! |
bridgekeeper
bot
removed
oca
|
@DanHeidinga this pull request can not be integrated into git checkout djh/eg_may_5_2021
git fetch https://git.openjdk.org/valhalla-docs main
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge main"
git push |
openjdk
bot
added
the
merge-conflict
|
@DanHeidinga This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! |
|
This is no longer relevant. |
Comments prior to the May 5 2021 EG call
Signed-off-by: Dan Heidinga heidinga@redhat.com
Progress
Error
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/valhalla-docs.git pull/1/head:pull/1$ git checkout pull/1Update a local copy of the PR:
$ git checkout pull/1$ git pull https://git.openjdk.org/valhalla-docs.git pull/1/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1View PR using the GUI difftool:
$ git pr show -t 1Using diff file
Download this PR as a diff file:
https://git.openjdk.org/valhalla-docs/pull/1.diff