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 jenkinsci-dev+unsubscr...@googlegroups.com. 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.