Does that mean you won't be able to use both the C and Java implementation simultaneously within a single JVM?
--Rafael On Fri, Jan 4, 2013 at 4:02 PM, Phil Harvey <p...@philharveyonline.com>wrote: > Ditto for Java. From the developer's point of view, they'll simply be > using the Java interfaces in proton-api such as Connection [1]. > > Our current intention is that the choice of whether to use the pure Java > implementations or the proton-c-via-Swig-via-JNI one will be made using a > factory instantiated by a java.util.ServiceLoader. The decision will > therefore depend on your runtime classpath. Client code will not have a > build time dependency on the Swig/JNI layer. > > [1] > > http://svn.apache.org/repos/asf/qpid/proton/trunk/proton-j/proton-api/src/main/java/org/apache/qpid/proton/engine/Connection.java > > > On 4 January 2013 20:40, Darryl L. Pierce <dpie...@redhat.com> wrote: > > > On Fri, Jan 04, 2013 at 03:32:44PM -0500, Rafael Schloming wrote: > > > Given what little I know of loading JNI stuff, that seems to make sense > > for > > > Java. > > > > > > FWIW, the python and ruby bindings don't ever actually expose the name > of > > > the C extension library since in both cases we have the so-called > > > "buttercream frosting layer" that wraps the raw C extension module. I > > would > > > hope we'd have something similar for perl and Java so that these names > > > shouldn't ever be visible to users. > > > > Per does. It uses qpid::proton namespace for the Message and Messenger > > classes. > > > > -- > > Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. > > Delivering value year after year. > > Red Hat ranks #1 in value among software vendors. > > http://www.redhat.com/promo/vendor/ > > > > >
