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

[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/