Philip Harvey commented on PROTON-191:
After doing an initial sweep, and discussing with Rob Godfrey, the following
discrepancies have been identified, many of which will be addressed in separate
# The pn_condition_* functions all correspond to the functionality within
ErronCondition et al. We need to manually check whether they are logically
# The codec-related pn_data_* functions (plus pn_message_data) will soon have
Proton-J equivalents. Rob Godfrey is working on this.
# Numerous Driver-related proton-c functions have no proton-j equivalent yet.
Gordon Sim is working on the proton-j Driver so we should revisit after that
work is committed. In many cases, there is probably little point wrapping a
proton-c driver in a Java wrapper.
# The pn_error_* functions have no proton-j equivalents. We need to revisit
error handling, error codes etc before addressing this.
# We don't yet know what pn_message_inferred does, so not sure if it needs a
# We need to consider how to do the equivalent of pn_free_* in proton-j across
the board. This isn't just a mechanical function mapping because of the
different memory management approaches of Java and C.
# Java and C programs have quite different norms for setting up SSL (roughly
speaking, setTrustStore/KeyStore and setPemFile respectively), so we need to
think whether there should be an equivalent method for functions such as
# We don't think pn_parser_* or pn_scanner_* need a proton-j equivalent.
# pn_ssl_get_peer_hostname and pn_ssl_set_peer_hostname relate to PROTON-161
which has not yet been implemented in proton-j.
# pn_terminus_capabilities is called by Link.setSource/Target. However, we
need to modify how subsequent mutation of sources and targets is done, possibly
by doing a deep copy before serialising them. Similar issues apply to
# We need have a general logging discussion before we can add a proton-j
equivalent for pn_transport_trace.
> Proton-API reconciliation reporting tool
> Key: PROTON-191
> URL: https://issues.apache.org/jira/browse/PROTON-191
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c, proton-j
> Reporter: Keith Wall
> Assignee: Keith Wall
> Add standalone tool that reconciles the public functions of the Proton-C API
> against the public API of the Proton-J API. Used so we can easily spot
> gaps in one implementation or the other.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira