[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[commit-cp] [bugs #7084] Runtime.nativeLoad() needs a ClassLoader parame
From: |
Michael Koch |
Subject: |
[commit-cp] [bugs #7084] Runtime.nativeLoad() needs a ClassLoader parameter |
Date: |
Wed, 12 Jan 2005 06:43:37 +0000 |
User-agent: |
Mozilla/5.0 (compatible; Konqueror/3.3; Linux; X11; i686; de) (KHTML, like Gecko) |
This is an automated notification sent by Savannah.
It relates to:
bugs #7084, project classpath
==============================================================================
LATEST MODIFICATIONS of bugs #7084:
==============================================================================
Posted by: Michael Koch <mkoch>
Posted on: 2005-01-12 06:43 (GMT)
_______________________________________________________
Category: None -> classpath
Status: None -> Fixed
Open/Closed: Open -> Closed
_______________________________________________________
Follow-up Comment:
This is now implemented. As Archie was part of the discussion when it was
added I think he agrees then I can close this bug report.
==============================================================================
OVERVIEW of bugs #7084:
==============================================================================
URL:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=7084>
Summary: Runtime.nativeLoad() needs a ClassLoader parameter
Project: classpath
Submitted by: archie172
Submitted on: Mon 05.01.2004 um 02:14
Category: classpath
Severity: 5 - Average
Status: Fixed
Privacy: Public
Assigned to: None
Open/Closed: Closed
Platform Version: None
_______________________________________________________
JDK 1.2 semantics specify that all native libraries are
associated with a single ClassLoader (see JNI spec for
details). Therefore Runtime.nativeLoad() needs an additional
ClassLoader parameter so the VM knows which one to associated
the newly loaded native library with.
Without such a parameter, the VM must "guess" but can guess
wrong, and then a JNI method will not resolve because the
native library is associated with the wrong class loader.
(yes, this actually happened to me which is why I'm reporting
the bug).
I've attached a patch to fix this, but it assumes that
the call to Runtime.load[Library]() is via System.load[Library](), which is
usually but not always
the case. Covering both cases would involve inspecting
the stack.
What we want is to identify the method that is calling
either Runtime.load*() or System.load*() and associate
the native library with the ClassLoader that loaded the
class containing that method.
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Mit 12.01.2005 um 06:43 By: Michael Koch <mkoch>
This is now implemented. As Archie was part of the discussion when it was
added I think he agrees then I can close this bug report.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Mon 05.01.2004 um 02:14 Name: load.patch Size: 2,56KB By: archie172
Patch to (mostly) fix this bug.
<http://savannah.gnu.org/bugs/download.php?item_id=7084&item_file_id=923>
==============================================================================
This item URL is:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=7084>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [commit-cp] [bugs #7084] Runtime.nativeLoad() needs a ClassLoader parameter,
Michael Koch <=