[
https://issues.apache.org/jira/browse/PROTON-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907128#comment-15907128
]
Rob Godfrey commented on PROTON-1436:
-------------------------------------
Looking back at the history it appears it has been that way (EncoderImpl final,
DecoderImpl non-final) since I originally created those classes almost exactly
five years ago ... I can't think of any rational reason why EncoderImpl is
final and DecoderImpl is not. I would say that it probably not anticipated
that people would be extending these classes and there's a definite non-zero
chance that the API or implementation might be changed between releases (in
truth I think rather than being final it would be better for getTypeFromClass()
to be package-private).
> Make EncoderImpl non-final
> --------------------------
>
> Key: PROTON-1436
> URL: https://issues.apache.org/jira/browse/PROTON-1436
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
> Affects Versions: proton-j-0.18.0
> Environment: NA
> Reporter: Rick Parker
> Priority: Minor
> Fix For: proton-j-0.19.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> org.apache.qpid.proton.codec.EncoderImpl is final.
> org.apache.qpid.proton.codec.DecoderImpl is non-final. I'm working on a
> use case where it would be great to override EncoderImpl.getTypeFromClass()
> to dynamically register described types as they are encountered (and do not
> implement DescribedType), but I cannot currently do so due to the class being
> final. I have to walk the object graph first to register types, or fork the
> code and change EncoderImpl myself.
> Or perhaps there's a reason it is final?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]