[jira] [Comment Edited] (SLING-8706) Injections for java.util.Optional<> should be automatic optional
[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974912#comment-16974912
]
Jörg Hoh edited comment on SLING-8706 at 11/15/19 8:12 AM:
---
While I agree on the reasoning of the linked statement provided by [~sseifert],
I wonder if it's exactly matching the situation here.
Technically nothing prevents you to use Java serialization with a SlingModel,
but I would assume that it is a rather uncommon and unusual approach. When you
serialize SlingModels, then you are rather using the SlingModelExporter, and
that's a very different situation.
My intention is to force a developer to explicitly handle the case of an
optional property being {{null}}. If we extend the SlingModelExporter to handle
the {{@Optional}} there is no difference in observable behavior,
{{!optionalProp.isPresent()}} can still be treated as the property being
\{{null}}.
was (Author: joerghoh):
While I agree on the reasoning of the linked statement provided by [~sseifert],
I wonder if it's exactly matching the situation here.
Technically nothing prevents you to use Java serialization with a SlingModel,
but I would assume that it is a rather uncommon and unusual approach. When you
serialize SlingModels, then you are rather using the SlingModelExporter, and
that's a very different situation.
My intention is to force a developer to explicitly handle the case of an
optional property being {{null}}. If we extend the SlingModelExporter to handle
the {{@Optional}} there is no difference in observable behavior,
{{!optionalProp.isPresent()}} can still be treated as a property being null.
> Injections for java.util.Optional<> should be automatic optional
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
>
> The current approach to support optional injections requires to annotate the
> field with {{@Optional}} plus proper handling within the javacode (null
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the
> case that the value is not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8706) Injections for java.util.Optional<> should be automatic optional
[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974912#comment-16974912
]
Jörg Hoh edited comment on SLING-8706 at 11/15/19 8:11 AM:
---
While I agree on the reasoning of the linked statement provided by [~sseifert],
I wonder if it's exactly matching the situation here.
Technically nothing prevents you to use Java serialization with a SlingModel,
but I would assume that it is a rather uncommon and unusual approach. When you
serialize SlingModels, then you are rather using the SlingModelExporter, and
that's a very different situation.
My intention is to force a developer to explicitly handle the case of an
optional property being {{null}}. If we extend the SlingModelExporter to handle
the {{@Optional}} there is no difference in observable behavior,
{{!optionalProp.isPresent()}} can still be treated as a property being null.
was (Author: joerghoh):
While I agree on the reasoning of the linked statement provided by [~sseifert],
I wonder if it's exactly matching the situation here.
Technically nothing prevents you to use Java serialization with a SlingModel,
but I would assume that it is a rather uncommon and unusual approach. When you
serialize SlingModels, then you are rather using the SlingModelExporter, and
that's a very different situation.
My intention is to force a developer to explicitly handle the case of an
optional property being ```null```. If we extend the SlingModelExporter to
handle the ```@Optional``` there is no difference in observable behavior,
```!optionalProp.isPresent()``` can still be treated as a property being null.
> Injections for java.util.Optional<> should be automatic optional
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
>
> The current approach to support optional injections requires to annotate the
> field with {{@Optional}} plus proper handling within the javacode (null
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the
> case that the value is not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-8706) Injections for java.util.Optional<> should be automatic optional
[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16974320#comment-16974320
]
Evgeny Tugarev edited comment on SLING-8706 at 11/14/19 8:03 PM:
-
Thanks, [~sseifert] this exactly what I meant.
was (Author: etugarev):
Thanks, [~sseifert] this exactly what I meant. I'll check for other tickets :)
> Injections for java.util.Optional<> should be automatic optional
> -
>
> Key: SLING-8706
> URL: https://issues.apache.org/jira/browse/SLING-8706
> Project: Sling
> Issue Type: Improvement
> Components: Sling Models
>Reporter: Jörg Hoh
>Priority: Major
>
> The current approach to support optional injections requires to annotate the
> field with {{@Optional}} plus proper handling within the javacode (null
> checks etc), which can be forgotten.
> So instead of
> {code}
> @Inject @Optional
> String fieldname;
> {code}
> it should also be possible to use this
> {code}
> @Inject
> Optional fieldname;
> {code}
> with the very same semantic. But the developer is forced to deal with the
> case that the value is not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
