[ https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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<String> 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)