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

Sat Oct 15 06:36:16 PDT 2011

Hi John,

i made some experiments with the actual jdk8 forrests how we maybe
will be able to remove public fields without breaking binary
compatibility. I posted the state of this experiments on jdk8-dev
to get some feedback on this. You can see some part of the thread
below.

Brian Goetz said that you made some exploration on this too in
project ninja and that you already discovered many questions that
must be answered/solved in order to make this "production-ready"
(what ever i think what production-ready means ;-) ).

Can you say something about it?

Kind regards
Sebastian

-------- Original-Nachricht --------
> Datum: Mon, 10 Oct 2011 21:57:33 +0200
> Von: Sebastian Sickelmann <sebastian.sickelmann at gmx.de>
> An: Joe Darcy <joe.darcy at oracle.com>
> CC: jdk8-dev at openjdk.java.net
> Betreff: Re: Remove public fields of classes that are in a public java API

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

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone