|
Lines 515-520
Link Here
|
| 515 |
plug-in has been removed, the target configuration area should be cleared before |
515 |
plug-in has been removed, the target configuration area should be cleared before |
| 516 |
launching. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=85835">85835</a>)</p> |
516 |
launching. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=85835">85835</a>)</p> |
| 517 |
|
517 |
|
|
|
518 |
<h4>Issues with JNI that use FindClass</h4> |
| 519 |
<p> |
| 520 |
There may be issues when using a JNI implementation that uses FindClass |
| 521 |
in a function where the JNIEnv pointer is not available, such as in a C |
| 522 |
callback (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=125250">125250</a>). The reason is that FindClass, in this case, uses the application |
| 523 |
class loader to find the class. |
| 524 |
If the desired class is in the classpath used for the application classloader |
| 525 |
(e.g. defined by the VM argument -cp <classpath>), as it would typically be in |
| 526 |
a stand-alone application, there is no problem. However, under |
| 527 |
Eclipse, the application classloader does not have access to classes |
| 528 |
contained in plug-ins. Eclipse uses its own class loader to find classes |
| 529 |
contained in plug-ins. |
| 530 |
</p> |
| 531 |
<p> |
| 532 |
The proper plug-in class loader is used by FindClass in JNI functions which are |
| 533 |
passed the JNIEnv pointer, but not when you have to use AttachCurrentThread to get the |
| 534 |
JNIEnv pointer. In this case the application classloader is used. |
| 535 |
</p> |
| 536 |
<p> |
| 537 |
For example, the following will fail because AttachCurrentThread is used to |
| 538 |
get the JNIEnv pointer: |
| 539 |
<pre> |
| 540 |
static JavaVM* jvm; // Global variable |
| 541 |
|
| 542 |
void myCallback(void) { |
| 543 |
JNIEnv* env; |
| 544 |
jvm->AttachCurrentThread((void**)&env, NULL); |
| 545 |
// Fails if some/class is not in the application classloader: |
| 546 |
jclass cls = env->FindClass("some/class"); |
| 547 |
jmethodID methodID = env->GetMethodID(cls, "methodName", |
| 548 |
"(Ljava/lang/String;)V or whatever signature"); |
| 549 |
env->CallVoidMethod(callback, methodID, ...); |
| 550 |
jvm->DetachCurrentThread(); |
| 551 |
} |
| 552 |
} |
| 553 |
</pre> |
| 554 |
<p> |
| 555 |
A solution is to cache the method ID, for example: |
| 556 |
</p> |
| 557 |
<pre> |
| 558 |
static jmethodID mid; // Global variable |
| 559 |
|
| 560 |
JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) { |
| 561 |
... |
| 562 |
// Store the JavaVM pointer |
| 563 |
jvm = vm; |
| 564 |
|
| 565 |
// Find the class and store the method ID |
| 566 |
// Will use the class loader that loaded the JNI library |
| 567 |
jclass cls = env->FindClass(className"some/class"); |
| 568 |
if(!cls) goto ERR; |
| 569 |
|
| 570 |
mid = env->GetMethodID(cls, "methodName", |
| 571 |
"(Ljava/lang/String;)V or whatever signature"); |
| 572 |
if(!mid) goto ERR; |
| 573 |
... |
| 574 |
} |
| 575 |
|
| 576 |
void myCallback(void) { |
| 577 |
JNIEnv* env; |
| 578 |
jvm->AttachCurrentThread((void**)&env, NULL); |
| 579 |
env->CallVoidMethod(callback, mid, ...); |
| 580 |
// Handle error ... |
| 581 |
jvm->DetachCurrentThread(); |
| 582 |
} |
| 583 |
} |
| 584 |
</pre> |
| 585 |
|
| 586 |
|
| 518 |
<h3>3.1.2 <a name="I-Platform-Ant">Platform - Ant</a></h3> |
587 |
<h3>3.1.2 <a name="I-Platform-Ant">Platform - Ant</a></h3> |
| 519 |
<h4>UTF-8 encoded buildfiles with Byte Order Mark</h4> |
588 |
<h4>UTF-8 encoded buildfiles with Byte Order Mark</h4> |
| 520 |
<p>UTF-8 encoded buildfiles with byte order marks will fail to be parsed correctly depending on the XML parser being used for the build. Therefore a valid buildfile will fail to build with an error message similar to: "BUILD FAILED: C:\workspace\bom.xml:1: Document root element is missing.". To succeed in building with these files, ensure to include Xerces jars on the Ant runtime classpath so that the Xerces parser is used to parse the XML. As well the context menu for these files in the Navigator or Package Explorer will not have the run shortcuts for Ant builds. (bug |
589 |
<p>UTF-8 encoded buildfiles with byte order marks will fail to be parsed correctly depending on the XML parser being used for the build. Therefore a valid buildfile will fail to build with an error message similar to: "BUILD FAILED: C:\workspace\bom.xml:1: Document root element is missing.". To succeed in building with these files, ensure to include Xerces jars on the Ant runtime classpath so that the Xerces parser is used to parse the XML. As well the context menu for these files in the Navigator or Package Explorer will not have the run shortcuts for Ant builds. (bug |