Compatible Field Resolution

[Sebastian Sickelmann]

Thanks for clarification. This is an interesting translation error. In most german text about accessibility the german word for visibility is used. Even for other programming languages with strong encapsulation.

Thanks for mentioning MethodHandles which I forget to list in my questions below and the language model API which I would have missed completly. 

--
Sebastian

Am 30.11.2015 8:42 nachm. schrieb Alex Buckley <alex.buckley at oracle.com>:
>
> You mean accessibility, not visibility. The difference is significant; 
> see "Project Jigsaw: Under The Hood" from JavaOne for more. 
>
> You are right that the model of accessibility used by the Java language 
> and the JVM is also used by the Core Reflection API (including 
> j.l.r.Proxy), the MethodHandle API, and the Language Model API. 
>
> Alex 
>
> On 11/29/2015 4:11 AM, Sebastian Sickelmann 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] http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-October/000199.html 
> > [1] 
> > https://github.com/picpromusic/incubator/tree/master/jdk/compatibleFieldAccess 
> >