×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Dan Feather skrev den 09-05-2007 16:26:
Terry,
I have found that using the -Djava.endorsed.dirs switch to be
extremely useful. I can put all my jars in the directory of my choice
and then I don't have to specify them on the classpath. I typically call
all my Java using JNI from RPG, so I have not tried it with the RUNJVA
but I don't see why it wouldn't work.
Even though it is tempting, I would _strongly_ recommend against it.
In brief, it doesn't scale.
In a bit more words: The reason is that you basically have one global
pool and if you for instance end up with one application requiring
version 1 of a supportive library and another requiring version 2 of the
same library, you will be unable to do so. Doing the separation at THAT
time will be a lot more painful than doing so when deploying each project.
A reasonable way to do it is to ask Eclipse/WSDCi to export your project
as JAR-files (which is just zipped classfiles with meta information) and
in the jar file manifest list the other jar files that this jar file
needs to be available. You will find that having version numbers in
the file names is a very good idea to allow to have several versions of
the same library - whether it is a date or a 1.28.1 number is irrelevant
in this regard.
The Jakarta projects are usually very well behaved and may be a good
inspiration of how to do it.
When that is said, I would really appreciate hearing your experiences
with calling Java from JNI, since I am trying to get as good an
integration between our legacy system and my Java-stuff.
midrange.com
