Hi Rob, I believe we're thinking along the same lines.
The ServiceLoader approach does indeed only affect which implementation you get by default. We will also allow the client to explicitly choose their implementation if they wish, and there will be no problem with both implmentations being used in the same proccess (this will be handy for writing interoperability tests). Phil On 7 January 2013 08:37, Rob Godfrey <rob.j.godf...@gmail.com> wrote: > I've not looked at the branch lately (only just back from vacation), but I > would very much hope that there would be nothing preventing having both the > JNI and native-Java libraries in the classpath, and allowing for explicit > creation of the desired implementation of Connection / Messenger / whatever > (which I'd probably suggest be done via a factory rather explicit > construction, but that's just personal taste). I would hope the Service > Loader would only affect the implementation created by *default* from a > factory > > -- Rob > > > > > On 4 January 2013 22:54, Phil Harvey <p...@philharveyonline.com> wrote: > > > The in-progress code on the jni branch does not currently allow this, > > although is no technical barrier to doing it. We just haven't yet decided > > on the nicest api for allowing the application to choose the > implementation > > it wants. > > > > The ability to mix implementations within a jvm will certainly be nice > when > > writing interoperability tests. > > > > Phil > > On Jan 4, 2013 9:16 PM, "Rafael Schloming" <r...@alum.mit.edu> wrote: > > > > > 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/ > > > > > > > > > > > > > > > > > > > >
