Compatible Field Resolution

[Alex Buckley]

The translation issue is interesting to know.

The terminology is important because "visibility" (i.e. what a class 
loader allows its defined classes to "see" in other class loaders) is 
solely a run time concept, whereas "accessibility" is both compile time 
and run time. (As is "readability", the module dependency model which 
now underpins accessibility.)

Alex

On 11/30/2015 12:23 PM, Sebastian Sickelmann wrote:
> 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
>>>