+1, it was broken anyway as mentionned on IRC yesterday Thought about that sorting by descendant (ascendant depending how you see it) for specialized beans only which should reduce the cost a lot and be deterministic so a big +1, thank you so much to drive this Mark!
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> 2017-12-19 9:01 GMT+01:00 Mark Struberg <[email protected]>: > Hi folks! > > Currently refactoring the WebBeansUtil#configureProducerMethodSpecial > izations. > > This method is not easy to follow and could be seriously simplified. > > I already moved all the condition checks to a common place, unifying the > checks from ProducerMethodBuilder and the ondes in WebBeansUtil. > > The next step is to simplify the condition checks itself. > It looks that the original approach have been a red/black tree like > algorithm to avoid n^2. > But by always creating a fresh sorted list of all producer method beans > inside this loop, we got the issue anyway. > > My current try is to sort all the beans just once and then disable all the > producer methods who got overwritten. > This means that the sorting has to be reversed, with the subclasses first, > then the parent classes later. > > It's quite some change, but it gladly only affects specialized producer > methods. > Still we should critically review the refactoring. > > txs and LieGrue, > strub > >
