Compatible Field Resolution (Very first working prototype)

Sebastian Sickelmann sebastian.sickelmann at
Sat Dec 5 18:36:19 UTC 2015


the very first prototype implemented inside the vm (without byte code
instrumentation) is working.

For those who want to try it: the changes for this are based on the
hs-rt[5] repository and the patches can be found here [0] [1].

For making this first step easy for me it uses the following configure
parameters: --with-jvm-interpreter=cpp --with-jvm-variants=zero.

To try it out yourself compile the following two source files [2][3]
(with an arbitrary

public class Example1 {
  public static void main(String[] args) {
    SubjectToChange stc = new SubjectToChange(5);

public class SubjectToChange {
  public int publicField;
  public static int publicStaticField = 42;
  public SubjectToChange(int value) {
    this.publicField = value;

After compiling you should try starting the Example1.
Then change just the class SubjectToChange to the following[4] implementation.

import java.lang.reflect.Accessor;
public class SubjectToChange {
  private int value;
  private static int staticValue = 43;
  public SubjectToChange(int value) {
    this.value = value;
  public static int getStatic() {
    return staticValue;
  public static void setStatic(int newValue) {
    staticValue = newValue;
  public int getPublicField() {
    return value;
  public void setPublicField(int value) {
    this.value = value;

And simple compile only the class SubjectToChange (maybe you use another directory for compilation of the changed version)
You have to use the newly created jdk with the patches from [0] and [1]. There is no change in the javac, but you need the
implementation of the Accessor-Annotation to compile the changed version off SubjectToChange.
I use -source 1.6 -target 1.6 for this one, to later test it also with an older jvm.

If you now run the Example1 with the patches jdk9-vm it prints out 

If you run the Example1 with another jdk9 / or jdk8 jvm you get the following expected error:
java.lang.NoSuchFieldError: publicField

sebastian at Inspi:~/example1$ ~/jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp orig Example1
sebastian at Inspi:~/example1$ ~/jdk8/build/linux-x86_64-normal-server-release/images/j2sdk-image/bin/java -cp change:orig Example1
Exception in thread "main" java.lang.NoSuchFieldError: publicField
	at Example1.main(

sebastian at Inspi:~/example1$ ~/hs-rt2/build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -cp orig Example1
sebastian at Inspi:~/example1$ ~/hs-rt2/build/linux-x86_64-normal-zero-slowdebug/images/jdk/bin/java -cp change:orig Example1

Hope this gives an first idea what could be done with this. In a follow-up post I want to write some more about the implementation.
There are also other ways that should be explored to achieve the same result. Like static postprocessing of jars/modules. 

Brian mentioned that that there maybe some synergies between this idea and Valhalla. I see some common topics with VarHandles, 
do you see another special topic in project Valhalla that has something in common with this idea?

Hope to get some feedback

[1] [2]
[5] On 12/01/2015 02:15 PM,
Sebastian Sickelmann wrote:
> adding valhalla-dev.
> Thanks to Brian pointing me in that direction.
> On 11/29/2015 05:08 PM, Brian Goetz wrote:
>> I think there may be some synergy between this idea and some of the work going on in project Valhalla.  So you should (also) bring those ideas there.  
>> Also, you might consider jlink as a vehicle for doing such transformations.  
>> Sent from my iPhone
>>> On Nov 29, 2015, at 7:11 AM, Sebastian Sickelmann <sebastian.sickelmann at> wrote:
>>> Hi,
>>> 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
>>> questions/topics:
>>> 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
>>> idea.
>>> At least for this last mentioned type of feedback I would prefer to get
>>> some reasons why you think so.
>>> --
>>> Sebastian
>>> [0]
>>> [1]

More information about the discuss mailing list