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:* [email protected] *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.org ARSlist:"Where the Answers Are" __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"
