> 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.
About what kind of overhead are you talking?
The only overhead that I see is following:
- you spent time to create an issue,
- you spent time to write a patch,
- your college spent time to review your change and to write an email for you,
- you spent time to change your patch after the review,
- I spent time to review your change and to write you an email,
- your patch increases the size of the generated class-file for the
AbstractListModel class from 2920 to 4205 bytes,
- at runtime the LambdaMetafactory will generate 3 objects for the
lambdas in your patch,
- you have added 3 extra function calls and not one:
1. a call to the #fireUpdates-method
2. a call to the #accept-method of the functional interface
3. a call to a synthetical method generated for a lambda.
And now look at your patch and do simple math:
Summary of changes: 60 lines changed: 25 ins; 27 del; 8 mod; 193 unchg
27 - 25 = 2.
Your patch saves exactly 2 lines of code. All of the overhead above
only for 2 lines of code, really?
Even when you would leave the import statement for the Swing classes
unchanged and remove the comment for the #fireUpdates-method, it would
be still not worth to apply your patch to save just 10 lines of really
The code in the AbstractListModel class exists in his current form for
decades and does not have any bug and there is no real need to change
PS: FYI, I know all lambda related articles/papers which were produced
by the Core, HotSpot and Performance teams and how lambdas are