The benefit to me is the use of collections. It simplifies programming and integrations with most other third party classes, as they include methods to work with colections.
Unfortunately, the challenge in removing the jni piece of any of the available java api's will require the availability of a native java api. I just don't see BMC releasing such a thing, for these reasons: - there are calls that are hidden/protected within the libraries that are used internally that BMC would consider proprietary (encryption/decryption functions, password retrieval functions, backdoors into your arserver, etc.) - in order for BMC to factor this into BMC products, they would have to rewrite a lot of code: - midtier - flasboards - email engine - DV plugin architecture or they could opt to use the jni api, in which case they would be supporting/maintaining two api's It's not that the above reasons couldn't be addressed, in a sound way, to release a native java api, it's a matter of BMC seeing value in addressing the issues then writing the api. Believe me when I say I would love to see a pure java api to Remedy, but I just don't see it happening. Axton Grams On 12/11/06, Hugo Visser <[EMAIL PROTECTED]> wrote:
** 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:* [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.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___ > __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
