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

[Brian Goetz]

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/