[
https://issues.apache.org/jira/browse/SLING-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17142111#comment-17142111
]
Justin Edelson commented on SLING-8706:
---------------------------------------
The question of how HTL interprets methods which return {{Optional}} should
really be orthogonal. Whether or not Sling Models supports *injection* of
{{Optional}} fields has no bearing on the API exposed by a model class. One
could have a Sling Model class *today* used by HTL which had a method which
returned an {{Optional}} value.
I don't see why the lack of serialization support is a problem, for two reasons
-- one, I'm not sure how common is it to use Java serialization for model
classes, second, this is (no pun intended) an _optional_ feature so worst case
a model developer would need to make a choice between using Java serialization
and this method for optional field injection. While yes, {{Optional}} wasn't
intended to be used in this way, I see no documentation that its usage as a
field is *prohibited*.
> 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
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> 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)
