Hi All,
>>>
So can anybody on the list confirm that this scenario does work (hint:
make sure there are no 7.1 libraries in you PATH)? Maybe Appajee can
step up and shed some light on this.
<<<
As of now 7.1 indeed still has some native code in it. If you will, you
can see the version 7.1 of Java API as - result of an effort in
simplifying the Java API (with collections use, elimination of redundant
wrapper classes and so on) and ground-up implementation of pure Java RPC
client stub. Unfortunately we have not attained 100% of the pure RPC
client stub implementation (& other behaviors that were depended upon
the underlying C layer in the olden JNI layer). Actually, the goal of
7.1 is NOT to attain the complete 'JNI elimination goal' in one shot,
considering what is realistic. So what we ended up at the end of 7.1 is
- mostly 'pure' Java implementation and much simplified API but with
little JNI dependency clinging on. So you can be assured that we are
aware of the "remaining" JNI dependent pieces and we're making strides
to eventual elimination of that. Beyond that, I can't make any comments
on future product deliverables/commitments etc.
As to specific areas where this native code dependency remains as of
7.1, they are as follows:
- Qualification parsing/formatting
- Assignment parsing/formatting
- Alert API
- To leverage RPC version mapping that allows for 7.1 Java API to
talk to older than 7.0. [BTW, 7.1's new Java RPC code is validated for
talking to 7.0/7.1/above]. So, to interact with a specific AR Server,
while it is all seamless to API client code, 7.1 Java API engages its
pure Java RPC implementation (for servers >=7.0) OR the underlying JNI
code (which in turn talks to C API) for talking to servers older than
7.0.
- I can't remember any more on top of my head right now, but
there could be a couple more not-so-critical but unfinished work items.
>>>
. I've disabled JNI loading through the arsys_api.xml file and set the
JRPC mode to true. Calls to Config.getInstance().getJrpcMode() and
Config.getInstance().getJniLoadMode() confirm this at runtime.
<<<
I have not lately played with this stuff. But as long as, you do not
exercise the functionality noted above & configured the mode to be Java
RPC & JNI load mode is set to zero - Java API should proceed without
looking for JNI code as much as possible.
<jrpcMode>true</jrpcMode>
<jniLoadMode>1</jniLoadMode>
Of course, this is unsupported and I would not encourage you to put
production/serious apps based on this kind of configuration tweaking.
Regards
Appajee
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
html___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
