Remove public fields of classes that are in a public java API
sebastian.sickelmann at gmx.de
Thu Oct 6 21:50:01 PDT 2011
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 ) 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/mlvm-dev/my-blog(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?)
More information about the jdk8-dev