+1000 (having had to dance around the @AdaptField on private fields called "id" in Jenkins 1.602+ more times than I'd care to recall already this year)
On 19 October 2015 at 14:13, James Nord <[email protected]> wrote: > Hi all, > > So we have strived to keep Jenkins backwards compatible and Kohsuke did want > to try and keep backwards compatibility where possible. > > But I have a proposal I would like to table that will break this as the > current situation is not sustainable in my opinion. > > All non-private fields (except public static finals) in the core code shall > be removed (replaced with getters/setters) - and there shall not be any use > of the bytecode-compatibility-transformer and @AdaptField. > > Why? > > the use of fields breaks encapsulation and makes maintaining the code and > enforcing correct locking harder (why we need to remove them) > We are now in the realms where the bytecode compatability transformer is > causing issues (it has been for a while but...) (why we need to stop using > the bct) > > the rewriting now requires to load classes which they themselves may need to > be re-written and is brittle (currently this just blows up but for JDK6+ > classes this will become a much more prevelant issue) > the transformer rewrites classes that do not need re-writing. In order to > do this correctly we need to traverse the entire class hierarchy due to the > format of the bytecode - and this also is brittle (potentially loading > classes whilst loading classes - which will cause further issues). > I can see the above blowing up at some point with some funky circular > reference which is perfectly legal > > > Infact having just fixed JENKINS-30820, we now see a broken jruby runtime > plugin with a ClassCircularityError. > > https://issues.jenkins-ci.org/browse/JENKINS-28781 > https://issues.jenkins-ci.org/browse/JENKINS-30820 > https://issues.jenkins-ci.org/browse/JENKINS-19383 (not fixed just hidden > - still rewrites this class - hence the ticket below) > https://issues.jenkins-ci.org/browse/JENKINS-28799 (not fixed) > https://issues.jenkins-ci.org/browse/JENKINS-31019 > > Post JDK6 the bytecode is now much more complex - to the point that until > jdk 1.8 update 60 (just released) the jvm bytecode verifier was letting > invalid bytecode past the verifier - which has suddenly showed some more > broken transformations prior to JENKINS-28781 landing in 1.633 - and who > knows what JDK9 will bring in terms of new op-codes or requirements. > > /James > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/54f53a29-4ce1-4582-830a-78c0c2274de3%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMz7QCTCZO-8f13oM0RqMjYSoHXr1wmjbGuqEUMOc4WHQw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
