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.
For more options, visit https://groups.google.com/d/optout.
