Mikhail Fursov wrote:
Alex,
we still have a problem with your solution :(
System.loadLibrary does not accept full paths, but -Dvm.em_dll could be a
full path to a library. IMO the workaround with parsing the path and
adjusting "java.library.path" before loading a library is bad solution.
Any thoughts?
I think there is a mistake in the code which Alex wrote (or it would
simply throw NPE). It should be
class GCv5Magics {
static {
String gcPath = System.getProperty("vm.gc_dll");
- if (gcPath == null) {
+ if (gcPath != null) {
System.load(gcPath);
}
else {
- System.loadLibrary("gc.dll");
+ System.loadLibrary("gc");
}
}
}
because it makes sense to call System.load only when there is a property
specified on the command line and System.loadLibrary in the default
case. The same should be done for EM. Or am I missing something?..
All,
Are there any potential security or compatibility problems to add native C
method to allow to a component to register itself as library in
bootclassloader context?
On 10/20/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
Mikhail Fursov :
> On 10/20/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:
>>
>> Yeap.
>> The following addresse both your issues.
>>
>>
>> class GCv5Magics {
>> static {
>> String gcPath = System.getProperty("vm.gc_dll");
>> if (gcPath == null) {
>> System.load(gcPath);
>> }
>> else {
>> System.loadLibrary("gc.dll");
>> }
>> }
>> }
>>
>>
> I like this approach! :)
You will like it even more with a patch (already posted) ;-)
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
