On 9/10/2025 9:48 pm, Andrea Del Bene wrote:
I think it might be useful creating a issue (or at least a branch) to
collect some ideas about this topic. I'll try to do something myself in the
next days.
On Thu, Jul 17, 2025 at 11:01 AM Andrea Del Bene <[email protected]>
wrote:
I'm in favor too of expanding Lambda adoption in Wicket. I remember some
of this support was eventually moved to WicketStuff due to the memory
concern, but I think it's better giving users the option to accept the
right trade-off between memory consumption and a cleaner code.
On Wed, Jul 16, 2025 at 1:25 PM Martijn Dashorst <
[email protected]> wrote:
On Tue, Jul 15, 2025 at 3:12 PM Richard Eckart de Castilho <
[email protected]>
wrote:
Does the memory usage matter a lot?
Yes. In (large) applications typically there's a lot of components in
memory.
I'll dig up some statistics from one of our production servers with a lot
of users.
Wrt. the this pointer: yeah, that sometimes comes up. However, most of the
time
I fill in method handles anyway. In those cases where I don't I typically
assign
the component to a variable that I can use inside the lambda instead of
the this.
I had also thought of passing in the component as an argument to the
lambda.
The issue is that each lambda takes a reference which increases the
footprint of Component considerably. For a stateful serverside web
framework we can't ignore this.
Joined the ASF channel ;)
Exactly. I know many of these new-ish language features are nice and
shiny and "mathematically puritan" (if that's important) but we still
have to consider that these apps must run on real computers and so the
extra RAM, GC load and CPU cycles consumed have to be considered.
We had an app that ran for years without any performance or reliability
issues until one day a developer took it on himself to replace many low
level methods that returned an object to return an 'Optional' typed to
the object's type instead. It had payroll report generation code,
iterating over hundreds of thousands of employees with 100 or so fields
per employee record. The extra object (Optional instances) being created
at every one of these previously efficient field level method calls
caused the Garbage Collector to have a hernia and code that ran fine for
years on modest hardware was suddenly throwing regular OOMs and having
the system appear to freeze up.
The OOMs were not the good type of OOM either - they were these bad boys:
"Excessive Garbage Collection Time:
If the JVM spends an inordinate amount of time on garbage collection
(e.g., 98% of CPU time) and recovers very little memory (e.g., less than
2% of the heap), it can throw an OutOfMemoryError: GC overhead limit
exceeded. This indicates that the application is making little progress
and is primarily busy with garbage collection."
As mentioned by others there are also issues with access to variables
with shiny lambda's. Too many times I have thought a shiny lambda would
nicely replace a simple 'for' loop only to discover that the non trivial
code needed at each iteration required access to non "finalisable"
variables in the outer method block and so then we have to invent
intricate ways to provide access... at some point you realize the "nice
and shiny" thing isn't something to be blindly adopted everywhere.
There's a reason Linux is still written, mostly, in 40 year old C. Some
recent efforts to convert some parts to the latest shiny thing, Rust
have ended up with lower performance than their C based originals.
Regards,
Chrisco
Do you think this is something limited to Wicket Bootstrap? Or would you
just
want to explore the concepts in that space before considering them for
Wicket Core?
It just came up in that channel. No particular reason.
For whether or not it belongs to wicket proper? I dunno, but that is
something we should start discussing to get some new life in the project
other than the odd bugfix. The programming model hasn't really changed
since Java 5, so we're due a refresh.
Martijn
--
Andrea Del Bene.
Apache Wicket committer.
