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

[Sebastian Sickelmann]

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/