Community
Participate
Working Groups
We should get all the necessary bridge methods 'for free' when compiling from source - the MethodVerifier15 that we use knows about inherited ITDs and ITDs it is receiving on any types it is verifying - so the logic to calculate when bridge methods are required all gets driven correctly. The problem is binary weaving - we've done nothing to ensure it works in this case. There seem to be a number of cases to consider and I'm not sure one algorithm will fix them all... If an ITD targets a particular class then it should be relatively easy when applying that ITD to the class that you check for any inherited methods and determine whether to create a bridge method representing the inherited methods erasure... The problem though is when you have a subclass below that which overrides the method you are ITDing... it may be that a bridge method needs adding to the subclass. But we may not go and look at that subclass, it may not be targetted for weaving, is it reasonable to walk *down* a hierarchy from the type that has been ITD'd upon? If possible I'd probably try and use the existing munger mechanism and create a munger that could be applied to the subtypes which adds the bridge method....
for M4
two tests for this: GenericsTests.testGenericITDsBridgeMethods2binary() GenericsTests.testGenericITDsBridgeMethods3binary() both currently commented out.
Whoa, there are a lot of cases to consider here. I've implemented the first so at least there is some kind of framework now. First, simplest, case is covariance where due to a variation in return type between methods in an overrides relationship, we need a bridge method. The weaver needs to get involved if: 1. the supermethod was introduced via ITD 2. the submethod was introduced via ITD 3. two classes were connected by DECP I've covered case '2'. After this works the next cases are for parameterized types and type variables used in signatures.
Ok, I've started on this. I've put some code in BcelClassWeaver so that post type munging we take a look at what might need a bridge method - there is quite a bit of room for optimization but I just wanted the basic algorithm to get tested in a dev build so want to get this in. It currently works for covariance but it doesn't cover the case where the overrides relationship is due to differences in parameter types (erasure). Because the methods added during type munging aren't written back to the world, we have to work with the insides of the LazyClassGen - makes me nervous... but, hey, the tests all pass ;) It'll be interesting to note if anyone sees a performance drop when this goes in - we don't have many large Java5 test systems in the suite - if so we need to make the optimizations asap. Basically involve tagging classes when they are affected by ITDs or decps and then any subtypes of those classes will need investigating for bridge methods - so we do a quick walk of the hierarchy for a type rather than going through all its methods every time.
well. I've optimized/tweaked/etc and now committed this stuff ... will close this when build is available !
code available in latest dev build.
