Hi Andrej, Thanks for your concerns and comments. Yes the duplicated code is not a bug, but nevertheless an overhead, when it is preventable. Also agree that lambdas cannot solve all the problems, but in this case, they lend to a nice solution to reduce the duplication of the code.
As for the performance considerations, yes it is one extra function call, but with modern JVMs equipped with JIT, and method inlining, either the method is optimized away, or the JIT compiler will certainly optimize the call overhead, for large number of iterations. I havenot done extensive research, but of the little I have done, it seems to indicate that, the cost of lambdas is negligible. Here are some of the links I have read through: 1. https://stackoverflow.com/questions/6495030/java-how-expensive-is-a-method-call - The usual goto place for any questions like this and this had additional pointers, but all the people seemed to agree that the compiler/VM would most likely inline the call. 2. https://www.youtube.com/watch?v=C_QbkGU_lqY - A very good session by Brian Goetz, which explains how lambdas are implemented under the hood, and gives some great insights. Basically, the lambdas I have used in my code are captureless, and that boils down to a constant loading in VM, and invokedynamic is used to call the lambdas. Ofcourse, when we are talking about huge number of iterations, the JIT compiler will kick in and might optimize away the call altogether. 3. https://plumbr.io/blog/performance-blog/how-expensive-is-a-method-call-in-java - Another blog which is trying to assess the cost of a method call over large number of iterations, and in the case when JIT kicked in, the additional time taken was just 205 nano seconds for 1023 additional method invocations. So, for large iterations, JIT is likely to mitigate the cost of extra method calls. Let me know your thoughts on this. Thanks, Krishna. -----Original Message----- From: Andrej Golovnin <andrej.golov...@gmail.com> Sent: Friday, April 6, 2018 3:58 PM To: Krishna Addepalli <krishna.addepa...@oracle.com> Cc: Pankaj Bansal <pankaj.b.ban...@oracle.com>; swing-dev@openjdk.java.net Subject: Re: <Swing Dev> [11] [JDK-8201173] Remove duplicated code in AbstractListModel class Hi all, as a long time user of Swing and as a person who maintains a very huge ( > 3M lines of code) Swing-based application I would like vote against this change. Could you please explain me which bug this change tries to solve? The so called duplicate code is not a bug and lambdas are not the holy grail. Just because lambdas exists it does not mean we should change every piece of code to use it. Your change will introduce a performance regression to every application that makes huge use of JLists and fires many events. Best regards, Andrej Golovnin On Fri, Apr 6, 2018 at 11:59 AM, Krishna Addepalli <krishna.addepa...@oracle.com> wrote: > Hi Pankaj, > > > > Thanks for your review. Here is the updated webrev: > http://cr.openjdk.java.net/~kaddepalli/8201173/webrev01/ > > > > Krishna > > From: Pankaj Bansal > Sent: Friday, April 6, 2018 3:04 PM > To: Krishna Addepalli <krishna.addepa...@oracle.com>; > swing-dev@openjdk.java.net > Subject: RE: <Swing Dev> [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi Krishna, > > > > The code changes look fine to me. > > Just one suggestion. I think you don’t need to create custom > UpdateFunction functional Interface here. Java has BiConsumer > functional interface, which does what you are trying to do here. > > > > Regards, > > Pankaj Bansal > > > > From: Krishna Addepalli > Sent: Thursday, April 5, 2018 9:09 PM > To: swing-dev@openjdk.java.net > Subject: <Swing Dev> [11] [JDK-8201173] Remove duplicated code in > AbstractListModel class > > > > Hi All, > > Please review a fix for > > JDK-8201173: https://bugs.openjdk.java.net/browse/JDK-8201173 > > Webrev: http://cr.openjdk.java.net/~kaddepalli/8201173/webrev00/ > > > > There is the duplication of code in fireContentsChanged, > fireIntervalAdded, fireIntervalRemoved functions, barring an int parameter > and a function call. > > Moved the common code into a function called fireUpdates, and defined > a functional interface, so that each function can pass its own lambda > that does the requisite function call. > > > > I have run the tests for JList and JComboBox and observed no new failures. > > > > Thanks, > > Krishna
