diff options
author | Reinier Zwitserloot <reinier@zwitserloot.com> | 2014-10-24 00:11:43 +0200 |
---|---|---|
committer | Reinier Zwitserloot <reinier@zwitserloot.com> | 2014-10-24 00:19:20 +0200 |
commit | 5407d0d253baa0cba1e5b7374f9ca45b5c50f622 (patch) | |
tree | 68a9913bb9eb3ff271c864c5c6a850704743036d /test/transform/resource/messages-ecj/GetterOnMethodErrors.java.messages | |
parent | 2ee2dbd8f9993a08e9ad281bfa73e2b6c5d01ee8 (diff) | |
download | lombok-5407d0d253baa0cba1e5b7374f9ca45b5c50f622.tar.gz lombok-5407d0d253baa0cba1e5b7374f9ca45b5c50f622.tar.bz2 lombok-5407d0d253baa0cba1e5b7374f9ca45b5c50f622.zip |
Making SCL work right is more complicated than it first seemed.
Right now the rules are:
* _IF_ a class is being loaded, sourced by a lombok-jar originating class, we FIRST search the lombok jar, and if we can’t find it, farm out the job to the originating equinox-side loader.
* _IF_ the equinox-side loader attempts to load a class, and it does NOT start with lombok, we don’t interfere and would never serve up any content from the lombok-jar (so if we have deps, they do NOT get loaded, by design). If it DOES start with lombok, we load it, and the loading class is SCL, not the equinox-side loader.
* getResource() to load classes did not work (because internally classes end in .SCL.lombok and not .class). This breaks a bunch of things. Fixed by having getResource() be aware that it should try rewriting any request for a .class to .SCL.lombok.
* launchified annotationprocessor, and cleaned up the launchified agent, which now, like all other launchers, just sets up classloader stuff and then calls into the lombok loader side to finish the actual processing, instead of trying to do it itself in a handicapped environment that can’t load much.
Diffstat (limited to 'test/transform/resource/messages-ecj/GetterOnMethodErrors.java.messages')
0 files changed, 0 insertions, 0 deletions