Thomas,
Thanks for the info.
The domain objects not being serializable is certainly a valid option.
To return to my original point, even this does not completely solve the
issue with unintended serialization. Sure, you are going to get a
serialization exception but this is a runtime error
>
> Would you mind to elaborate on this a bit? What do you do in your forms?
> How do you handle state there? Do you use view models that are
> serializable? Do you keep state in local variables and propagate it to the
> domain object in every request after it is reloaded?
Sure.
We use
Hi,
If you don't mind me following up on your comment...
> Personally, I rarely encounter serialization issues. None of our domain
> objects implement Serializable. They can only be used with
> LoadableDetachableModels that only store the identifier.
>
>>
>>
Would you mind to elaborate on this
The IntelliJ inspection has configuration options. If you enable only the
last option "Report variables which are implicitly final", it might help
with your problem:
[image: image.png]
Personally, I rarely encounter serialization issues. None of our domain
objects implement Serializable. They
Thank you for your answer Thomas.
"Local variable or parameter can be final" inspection actually does
something different. It will warn that a parameter can be made final when
its value does not change, even if it not used in an anonymous class. This
will result in programmers declaring all
Hi Sven,
I came to the same conclusion trying to refactor WicketMessageResolver.
I have previously used different fragments and panels to solve this issue
but it is annoying because you end up with lots of additional code and HTML
that only differs in the message key.
My solution now was to
Hi Marios,
I don't think there is a way to disable this behaviour but you have other
options:
- If you use IntelliJ, you can configure the "Local variable or parameter
can be final" inspection to raise an error instead of a warning (for
variables that are implicitly final)
- Checkstyle or
Hi all,
Java 8 introduced the ability to access effectively final variables/method
parameters from anonymous classes without having to add explicitly the
"final" keyword.
This has resulted in a lot of cases where the programmer does not notice
that they are referencing a model object from an