The part about proactively changing non-private fields is too reckless. It presumably breaks a significant number of plugins, and it does so for no good reasons. I say no good reasons because most of these fields need not be adopted ever.
IIUC, the pain that motivated you is the side effect of bytecode compatibility transformer, so what we should be thinking about is how to minimize the use & impact of BCT. For example, Queue.Item.id has known fixed set of subtypes, so we can restrict the rewrite to a much smaller subset. And if we want to discourage the use of BCT, we can do that, too. 2015-10-19 6:13 GMT-07:00 James Nord <[email protected]>: > 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? > > > 1. the use of fields breaks encapsulation and makes maintaining the > code and enforcing correct locking harder (*why we need to remove them* > ) > 2. 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*) > 1. 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) > 2. 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). > 3. 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 > <https://issues.jenkins-ci.org/browse/JENKINS-30820>, we now see a broken > <https://issues.jenkins-ci.org/browse/JENKINS-31019>jruby runtime plugin > with a ClassCircularityError. > > https://issues.jenkins-ci.org/browse/JENKINS-28781 > <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 > <https://groups.google.com/d/msgid/jenkinsci-dev/54f53a29-4ce1-4582-830a-78c0c2274de3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Kohsuke Kawaguchi -- 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/CAN4CQ4zGbxtAZXNJSGnm3wGmj_jwob1ShYL-jcVvJN%2BgT%2BKCFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
