On 11.10.20 23:32, Keegan Witt wrote:
Related to https://issues.apache.org/jira/browse/GROOVY-9777 that was noticed by someone last week, I'm thinking JavaStubGenerator.selectAccessibleConstructorFromSuper should select the closest matching parent constructor related to the number and type of parameters in the child. The code has a variable named bestMatch, but it seems to me (unless I'm misreading) that it functions more like firstMatch. Other than it being a more complicated implementation (I'm still thinking about how I'd do it), was there any reason to avoid this?
So far the rule was, that if the wrong constructor has been chosen, use a cast to force the right one. Yes, that mans adding a cast in Groovy code, you actually do not need - even if it can dramatically reduce the bytecode size for the generated constructor. The stub code on the other hand is no executed code, we need to only select *any valid* constructor and things are fine. So of course you can try to find a better matching constructor, but you don't actually gain anything compared to selecting another correct constructor. bye Jochen
