Re: Java 8 access to effectively final variables/method parameters from anonymous classes
Hi, You can file a feature request to Java developers. A compiler flag can forbid this behavior. On Sun, Aug 4, 2019, 14:05 mscoon wrote: > 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 (hidden in the logs if > I recall correctly) - much more cumbersome from the programmer's point of > view compared to getting immediate visual feedback in the IDE or a compiler > error. > > Also with view models you may end up again serializing a view model > unintentionally. Granted this is usually not as bad, but still... > > The IntelliJ option seems to do what I want. Unfortunately we use eclipse > and I wasn't able to find an equivalent option. > > Cheers > Marios > > > > On Sun, Aug 4, 2019 at 1:07 PM Thomas Heigl wrote: > > > > > > > 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 DTOs/View Models for most of our forms. We started out with > > manipulating domain objects directly, but it caused too many headaches > with > > serialization and detaching/re-attaching entities etc. > > Domain objects are only used as Wicket (loadable detachable) models when > > the manipulation is just a single step that can be persisted to the DB > > right away. Your ajax link is a good example. Also single-page forms > where > > the final "Save/Next" button persists the changes to the DB. Whenever we > > have a multi-step process (like a wizard) for creating or editing domain > > objects, we use custom view models. > > > > Thomas > > > > On Sun, Aug 4, 2019 at 11:53 AM mscoon wrote: > > > > > 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 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? > > > > > > We often use serializable domain objects so that keeping state on the > > > object is simple. For example if you have an ajax link that increments > a > > > property of the domain object, you simply increment the property and > rely > > > on the object being serialized for keeping state. > > > > > > Cheers > > > Marios > > > > > >
Re: Java 8 access to effectively final variables/method parameters from anonymous classes
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 (hidden in the logs if I recall correctly) - much more cumbersome from the programmer's point of view compared to getting immediate visual feedback in the IDE or a compiler error. Also with view models you may end up again serializing a view model unintentionally. Granted this is usually not as bad, but still... The IntelliJ option seems to do what I want. Unfortunately we use eclipse and I wasn't able to find an equivalent option. Cheers Marios On Sun, Aug 4, 2019 at 1:07 PM Thomas Heigl wrote: > > > > 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 DTOs/View Models for most of our forms. We started out with > manipulating domain objects directly, but it caused too many headaches with > serialization and detaching/re-attaching entities etc. > Domain objects are only used as Wicket (loadable detachable) models when > the manipulation is just a single step that can be persisted to the DB > right away. Your ajax link is a good example. Also single-page forms where > the final "Save/Next" button persists the changes to the DB. Whenever we > have a multi-step process (like a wizard) for creating or editing domain > objects, we use custom view models. > > Thomas > > On Sun, Aug 4, 2019 at 11:53 AM mscoon wrote: > > > 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 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? > > > > We often use serializable domain objects so that keeping state on the > > object is simple. For example if you have an ajax link that increments a > > property of the domain object, you simply increment the property and rely > > on the object being serialized for keeping state. > > > > Cheers > > Marios > > >
Re: Java 8 access to effectively final variables/method parameters from anonymous classes
> > 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 DTOs/View Models for most of our forms. We started out with manipulating domain objects directly, but it caused too many headaches with serialization and detaching/re-attaching entities etc. Domain objects are only used as Wicket (loadable detachable) models when the manipulation is just a single step that can be persisted to the DB right away. Your ajax link is a good example. Also single-page forms where the final "Save/Next" button persists the changes to the DB. Whenever we have a multi-step process (like a wizard) for creating or editing domain objects, we use custom view models. Thomas On Sun, Aug 4, 2019 at 11:53 AM mscoon wrote: > 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 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? > > We often use serializable domain objects so that keeping state on the > object is simple. For example if you have an ajax link that increments a > property of the domain object, you simply increment the property and rely > on the object being serialized for keeping state. > > Cheers > Marios >
Re: Java 8 access to effectively final variables/method parameters from anonymous classes
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 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? We often use serializable domain objects so that keeping state on the object is simple. For example if you have an ajax link that increments a property of the domain object, you simply increment the property and rely on the object being serialized for keeping state. Cheers Marios
Re: Java 8 access to effectively final variables/method parameters from anonymous classes
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 can only be used with
LoadableDetachableModels that only store the identifier.
If you have some serializable objects that you never want to serialize in
Wicket, you can implement a custom serializer that checks and logs an error
or throws if such objects are serialized (e.g. JPA entities).
-t
On Sun, Aug 4, 2019 at 10:44 AM mscoon wrote:
> 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 variables that they can as final
> and using them in the anonymous classes, which will again result in the
> same serialization oversights I mentioned...
>
> The same applies to checkstyle.
>
> I wonder why this is not a problem for others using wicket. Given wicket's
> serialization, since java 8 that allowed anonymous classes to access
> variables from the enclosing scope even if they are not declared final, I
> find there is a lot of room for unintentionally serializing stuff that you
> didn't want/notice is being serialized... Perhaps we are doing something
> wrong...
>
>
> On Sun, Aug 4, 2019 at 11:35 AM Thomas Heigl wrote:
>
> > 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 similar tools that you can hook into your build process
> > might have similar inspections
> >
> > Best,
> >
> > Thomas
> >
> > On Sun, Aug 4, 2019 at 9:18 AM mscoon wrote:
> >
> > > 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 anonymous class, which
> > > results in the model object being serialized.
> > >
> > > Example:
> > > code inside a hypothetical MyPanel.newLink() method...
> > >
> > > Myclass obj = getModelObject();
> > > return new AjaxLink("link") {
> > > void onClick(AjaxRequestTarget t) {
> > > if (obj.getId() != null) {
> > >// do something
> > > } else {
> > > // do something else
> > > }
> > > }
> > >
> > > In previous java versions you'd have to declare obj as final, and this
> > > would help you notice that it is going to be serialized.
> > >
> > > I understand that it is easy to change the code and avoid obj being
> > > serialized. The problem is not how to fix the code - the problem is
> that
> > > this "problem" often goes unnoticed.
> > >
> > > As far as I have searched, there is no way to disable this behavior
> (not
> > > having to explicitly declare variables as final) in java 8.
> > >
> > > Do you have any suggestions on how to handle this?
> > >
> > > Thank you in advance,
> > > Marios
> > >
> >
>
Re: Java 8 access to effectively final variables/method parameters from anonymous classes
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 variables that they can as final
and using them in the anonymous classes, which will again result in the
same serialization oversights I mentioned...
The same applies to checkstyle.
I wonder why this is not a problem for others using wicket. Given wicket's
serialization, since java 8 that allowed anonymous classes to access
variables from the enclosing scope even if they are not declared final, I
find there is a lot of room for unintentionally serializing stuff that you
didn't want/notice is being serialized... Perhaps we are doing something
wrong...
On Sun, Aug 4, 2019 at 11:35 AM Thomas Heigl wrote:
> 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 similar tools that you can hook into your build process
> might have similar inspections
>
> Best,
>
> Thomas
>
> On Sun, Aug 4, 2019 at 9:18 AM mscoon wrote:
>
> > 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 anonymous class, which
> > results in the model object being serialized.
> >
> > Example:
> > code inside a hypothetical MyPanel.newLink() method...
> >
> > Myclass obj = getModelObject();
> > return new AjaxLink("link") {
> > void onClick(AjaxRequestTarget t) {
> > if (obj.getId() != null) {
> >// do something
> > } else {
> > // do something else
> > }
> > }
> >
> > In previous java versions you'd have to declare obj as final, and this
> > would help you notice that it is going to be serialized.
> >
> > I understand that it is easy to change the code and avoid obj being
> > serialized. The problem is not how to fix the code - the problem is that
> > this "problem" often goes unnoticed.
> >
> > As far as I have searched, there is no way to disable this behavior (not
> > having to explicitly declare variables as final) in java 8.
> >
> > Do you have any suggestions on how to handle this?
> >
> > Thank you in advance,
> > Marios
> >
>
Re: Java 8 access to effectively final variables/method parameters from anonymous classes
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 similar tools that you can hook into your build process
might have similar inspections
Best,
Thomas
On Sun, Aug 4, 2019 at 9:18 AM mscoon wrote:
> 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 anonymous class, which
> results in the model object being serialized.
>
> Example:
> code inside a hypothetical MyPanel.newLink() method...
>
> Myclass obj = getModelObject();
> return new AjaxLink("link") {
> void onClick(AjaxRequestTarget t) {
> if (obj.getId() != null) {
>// do something
> } else {
> // do something else
> }
> }
>
> In previous java versions you'd have to declare obj as final, and this
> would help you notice that it is going to be serialized.
>
> I understand that it is easy to change the code and avoid obj being
> serialized. The problem is not how to fix the code - the problem is that
> this "problem" often goes unnoticed.
>
> As far as I have searched, there is no way to disable this behavior (not
> having to explicitly declare variables as final) in java 8.
>
> Do you have any suggestions on how to handle this?
>
> Thank you in advance,
> Marios
>
