Remove public fields of classes that are in a public java API

[Sebastian Sickelmann]

Thanks Joe,
Thanks Brian,

thanks for encouraging me. I will continue working on this. I wouldn't 
do this just for removing some public fields in exceptions. It opens the 
possibility to do some changes that would not be possible without 
breaking binary compatibility. I am not sure if it has the same impact 
as the defender methods, but this solution (Video from JVM Language 
Summit) showed me the path to it.
I will write to John soon, to see what he had done on "ninja".

Thanks for encouraging me.

-- Sebastian

Am 10.10.2011 20:59, schrieb Joe Darcy:
> Some additional feedback, my initial reaction to seeing the proposed 
> methodology for removing public fields was "wow, it would be cool to 
> be able to remove public fields like that" together with "removing the 
> public fields in exceptions doesn't seem worth the effort."
>
> So I encourage continued development of this capability, but don't 
> think it has a good risk/reward trade-off for the particular scenario 
> under discussion.
>
> -Joe
>
> On 10/7/2011 10:00 AM, Brian Goetz wrote:
>> This is a fine experiment; John Rose has explored many aspects of 
>> this idea already in the context of his "ninja" ("ninja is not java") 
>> project.
>>
>> Perhaps the reason this idea did not connect in its current form is 
>> that it is still in the "wacky idea" stage, and needs experimentation 
>> before being refined into something that might actually be a sensible 
>> platform enhancement.  Trying to figure out how to ultimately mate up 
>> with the JDK implementation seems a premature optimization at this 
>> time; do your experiments, demonstrate some interesting results, and 
>> get people excited, and iterate.  Identify costs and benefits.  Get 
>> some data to deflect the obvious performance brickbats that will come 
>> your way.
>>
>> Ultimately invokedynamic has tremendous potential to help us migrate 
>> across incompatible changes.
>>
>>
>> On 10/7/2011 12:50 AM, Sebastian Sickelmann wrote:
>>> Hello,
>>>
>>> while doing some work on introducing exceptions-chaining for all
>>> exceptions in jdk i discovered that there are exception-classes(and
>>> other) that are part of the public API (in my definition: public 
>>> classes
>>> in java.*, javax.*). The problem here is removing them (making them
>>> default-/protected-/private-visible) breaks binary compatibility, and
>>> all code out there that uses this public field breaks.
>>>
>>> Introducing properties (discussed at coin-dev [1]) may solve the
>>> problem, but i don't like change java(the-language) for these, and it
>>> depends havily on the choose of the property-implementation.
>>>
>>> I think change in runtime-behavior of the jvm can solve this issue 
>>> in an
>>> binary compatible way. I actually i think changing something at
>>> load-time (maybe interpreter-/JITcompile-time) would be best, and i 
>>> want
>>> to dive into it and spend time to explore how this can be done.
>>> Unfortunately i actually haven't the knowledge to do this at jvm level,
>>> so i implemented something that tries to show the concept at
>>> byte-code-manipulation level in PreMain. But i am working on 
>>> building my
>>> knowledge to do this at vm-level.
>>>
>>> But before i invest more time on this, i want to discuss it, if this 
>>> has
>>> a change to get into the jvm/jdk/.../. I am complete open at where and
>>> how this needs to be implemented.
>>> I posted some information on this on
>>> core-libs-dev[2]/mlvm-dev[3]/my-blog[4](it's mainly all the same
>>> information) but didn't get any feedback :-(
>>> Maybe i chose the wrong list? Maybe there is really no interest?
>>>
>>> The concept-demo replaces every public field access
>>> (GET_FIELD,PUT_FIELD) with an invokedynamic call. At bootstrap time it
>>> decides if it is possible to access this field or if it needs to make
>>> some indirection with some access-methods (in the concept-demo these 
>>> are
>>> marked with some annotations).
>>>
>>> Hope to get any reaction this time. All comments are welcome even if
>>> they say: "no i don't like it, because ....". If you think it is not
>>> worth discussed on mailinglist, please send feedback to me 
>>> personally or
>>> comment on my blog. But i hope it is worth for discussion on the
>>> mailing-list(maybe another, any suggestions?)
>>>
>>> Kind regards
>>> Sebastian
>>>
>>> [1]
>>> http://mail.openjdk.java.net/pipermail/coin-dev/2011-October/003358.html 
>>>
>>> [2]
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-September/007676.html 
>>>
>>>
>>> [3]
>>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-September/003902.html 
>>>
>>> [4] 
>>> http://codingwizard.wordpress.com/2011/09/13/remove-flaws-in-java-apis/
>