Hi Axton, Yes I know. My point is that I do not see much use in switching one JNI wrapped API by another JNI wrapped API. The issues that are present with the JNI stuff are not going away when switching to JOARSE. My other point is that RTL and JOARSE do not support all Remedy platforms and that there's no or limited community support.
The "only" benifit for using JOARSE could be the simplified API. If I have some spare time I'll take a better look at JOARSE to see if the dependency on the JNI part can be abstracted out so that the Remedy API can be used underneath. As far as I can tell the only JNI class involved is the Server class. Hugo On 12/11/06, Axton <[EMAIL PROTECTED]> wrote:
** RTL is a C++ wrapper for the BMC provided libraries. JOARSE is a JNI wrapper for RTL In essence, RTL and JOARSE are based on the supported libraries, they simply implement a layer of abstraction that makes programming with them much easier. Axton Grams On 12/11/06, Hugo Visser <[EMAIL PROTECTED]> wrote: > > ** Dan, > > Personally I'm reluctant to use another library that uses JNI. Although > the Remedy supplied API is a bit weird and maybe even buggy on certain > areas, it is supported and also runs on all of the supported platforms. We > have customers on about every supported platform so I really care about that > one. That's why I'd rather "wrap" the Remedy supported API (with the JNI > part), and not build (or reuse) something else that has essentially the same > kind of deployment problems (JNI libraries and related libraries). > > I agree that the non-JNI route will be hard or even impossible, since it > involves reverse enginering of the RPC protocol calls and that is probaly > not allowed, if you get it done in the first place at all :) > > So don't get me wrong, I think it's great that there are alternatives > such as RTL and JOARSE, I'm sure those libraries help many people in doing > their jobs effectively. I was just thinking up loud considering the > alternatives to the Remedy Java API, and maybe a bit daydreaming about a > pure Java version of it :) > > Hugo > > On 12/8/06, Dan Hardy <[EMAIL PROTECTED] > wrote: > > > > ** > > > > > > > > Rather than start any new projects, please consider adding to these > > existing projects: > > > > > > > > C++ (uses STL for collections, exceptions, and provides encapsulation > > of memory management. Compiles on Windows, Linux, Solaris.) > > > > > > > > http://www.sourceforge.net/projects/rtl > > > > Why you should use this: http://rtl.sourceforge.net/doc (check out > > the code comparison) > > > > > > > > Java (uses proper collections, and is reasonably OO – could use an > > upgrade to Java 5 features. Works on at least Windows and Linux – can't > > recall if I provided Solaris binaries) > > > > http://www.sourceforge.net/projects/joarse > > > > > > > > COM (automation compatible, uses proper COM collections and error > > handling, and is also usable from .NET – only 168 kb) > > > > http://www.sourceforge.net/projects/coarse > > > > > > > > As far as I know, these are all very stable. The latter two projects > > build on the first (they were initially examples of how trivial it is to > > build APIs for other languages once you have RTL). > > > > > > > > Dan > > > > > > > > > > ------------------------------ > > > > *From:* Action Request System discussion list(ARSList) [mailto: > > [EMAIL PROTECTED] *On Behalf Of *Hugo Visser > > * Sent:* Friday, December 08, 2006 3:18 AM > > *To:* arslist@ARSLIST.ORG > > *Subject:* Re: Java Extended API for J2SE5.0 ? > > > > > > > > ** John, > > > > No JNI that would be great :) In the past I've investigated doing a > > "light" api in pure Java, but the whole RPC stuff seemed the biggest hurdle. > > One could ofcourse build a wrapper around the existing API using collections > > and annotations (which I have done just to keep things compatible) but then > > you'll still be stuck with the jni stuff. I think it would be nice to start > > some kind of opensource project of some kind for making working with Remedy > > easier. Maybe an API layer or an alternative API. > > > > Hugo > > > > On 12/8/06, *John Baker* < [EMAIL PROTECTED]> wrote: > > > > Julio, > > > > I feel your chances of getting that from the Remedy Java API are > > around nil. > > The API isn't even OO, let alone equipped with Collections (which was > > a year > > 2000 feature) - hence, while a nice Java API would be welcome, it's > > never > > going to happen until the Remedy Java API is taken seriously (I > > include > > removing JNI in this statement). > > > > However. I had heard of an open source Remedy Java API, if you fancy > > contriburing towards an alternative.1 > > > > > > John > > > > Java System Solutions : http://www.javasystemsolutions.com > > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where the Answers Are" > > > > > > __20060125_______________________This posting was submitted with HTML > > in it___ > > > > __20060125_______________________This posting was submitted with HTML > > in it___ > > > __20060125_______________________This posting was submitted with HTML in > it___ > __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
