Attachment 43315 Details for Bug 125250 – readme patch

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

[patch] readme patch

125250_org.eclipse.platform-feature.patch (text/plain), 3.82 KB, created by Thomas Watson

on 2006-06-01 18:06:57 EDT

(hide)

Description:

Filename:

MIME Type:

Creator: Thomas Watson

Created: 2006-06-01 18:06:57 EDT

Size: 3.82 KB

patch

obsolete

>### Eclipse Workspace Patch 1.0
>#P org.eclipse.platform-feature
>Index: rootfiles/readme/readme_eclipse.html
>===================================================================
>RCS file: /cvsroot/eclipse/org.eclipse.platform-feature/rootfiles/readme/readme_eclipse.html,v
>retrieving revision 1.70
>diff -u -r1.70 readme_eclipse.html
>--- rootfiles/readme/readme_eclipse.html	1 Jun 2006 16:10:49 -0000	1.70
>+++ rootfiles/readme/readme_eclipse.html	1 Jun 2006 22:08:59 -0000
>@@ -515,6 +515,75 @@
> plug-in has been removed, the target configuration area should be cleared before
> launching. (bug <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=85835">85835</a>)</p>
> 
>+<h4>Issues with JNI that use FindClass</h4>
>+<p>
>+There may be issues when using a JNI implementation that uses FindClass 
>+in a function where the JNIEnv pointer is not available, such as in a C 
>+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
>+class loader to find the class.
>+If the desired class is in the classpath used for the application classloader
>+(e.g. defined by the VM argument -cp <classpath>), as it would typically be in 
>+a stand-alone application, there is no problem.  However, under
>+Eclipse, the application classloader does not have access to classes 
>+contained in plug-ins.  Eclipse uses its own class loader to find classes 
>+contained in plug-ins.
>+</p>
>+<p>
>+The proper plug-in class loader is used by FindClass in JNI functions which are 
>+passed the JNIEnv pointer, but not when you have to use AttachCurrentThread to get the 
>+JNIEnv pointer.  In this case the application classloader is used.
>+</p>
>+<p>
>+For example, the following will fail because AttachCurrentThread is used to 
>+get the JNIEnv pointer:
>+<pre>
>+static JavaVM* jvm;  // Global variable
>+
>+void myCallback(void) {
>+    JNIEnv* env;
>+    jvm->AttachCurrentThread((void**)&env, NULL);
>+    // Fails if some/class is not in the application classloader:
>+    jclass cls = env->FindClass(&quot;some/class&quot;);
>+    jmethodID methodID = env->GetMethodID(cls, &quot;methodName&quot;,
>+      &quot;(Ljava/lang/String;)V or whatever signature&quot;);
>+    env->CallVoidMethod(callback, methodID, ...);
>+    jvm->DetachCurrentThread();
>+  }
>+}
>+</pre>
>+<p>
>+A solution is to cache the method ID, for example:
>+</p>
>+<pre>
>+static jmethodID mid;  // Global variable
>+
>+JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *vm, void *reserved) {
>+...
>+  // Store the JavaVM pointer
>+    jvm = vm;
>+
>+  // Find the class and store the method ID
>+  // Will use the class loader that loaded the JNI library
>+    jclass cls = env->FindClass(className&quot;some/class&quot;);
>+    if(!cls) goto ERR;
>+
>+    mid = env->GetMethodID(cls, &quot;methodName&quot;,
>+      &quot;(Ljava/lang/String;)V or whatever signature&quot;);
>+    if(!mid) goto ERR;
>+...
>+}
>+
>+void myCallback(void) {
>+    JNIEnv* env;
>+    jvm->AttachCurrentThread((void**)&env, NULL);
>+    env->CallVoidMethod(callback, mid, ...);
>+     // Handle error ...
>+    jvm->DetachCurrentThread();
>+  }
>+}
>+</pre>
>+
>+
> <h3>3.1.2 <a name="I-Platform-Ant">Platform - Ant</a></h3>
> <h4>UTF-8 encoded buildfiles with Byte Order Mark</h4>
> <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

Actions: View | Diff

Attachments on bug 125250: 43315