Compatible Field Resolution

Sebastian Sickelmann sebastian.sickelmann at
Sun Nov 29 12:11:49 UTC 2015


some time ago I started a discussion on jdk8-dev [0] about a change in
field lookup and resolution to make changes to the visibility of fields
possible without losing binary compatibility. In 2011 unfortunately I
lost track to take my experiments[1] much further.

Now that i get my feet wet again with some openjdk development and
learned (hopefully) enough about debugging the jdk with gdb and the jdk
itself, i started (a few days ago) my experiment again. This time in the
jvm itself based on the cpp-interpreter (zero) of the jdk9/hs-rt repos.
Hope to get a of this other type of proof of concept presentable soon.

In the meantime I would love to get some thought about the following

Q1: Do you think that java(the jvm) would benefit of some way to make
changes to the visibility of fields in a binary compatible way?
Q2: Do you think that this should be handled at runtime/link-time inside
the vm?
Q3: Or do you think that this should be handled as early as possible
(load-time of classes) --> ex. by exchanging all field access to are not
in the same class(/module??) to an indy-call?
Q4: Or do you think that a "static prior runtime solution" should be
created to update "old" jars/modules?
Q5: If the runtime solution is your choice what to you think, should the
runtime behavior(lookup and linking of field) of the byte-codes
get,put,get-static,put-static also be changed for classes that are
compiled for an older jvm and where the jars/modules are signed by an
digital certificate?
Q6: If not Q5. Should it be allowed by some security-related settings?
Q7: What is about reflection functionality. Should this be changed to?
Field-Lookups, set / get value of fields?

Hope to get some discussion started. Feel free to answer to one or more
from the questions / topics above.
If you have more questions that should be handled, you are also welcome
to post those.
Every feedback is welcome, even those you say, all this is a really bad
At least for this last mentioned type of feedback I would prefer to get
some reasons why you think so.



More information about the discuss mailing list