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.
