On 08/03/2013 02:22, BILL PITTORE wrote:
Moved the string allocation into buildJniFunctionName as Alan
suggested. Built and tested on windows and linux. Updated the webrev:
http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/
bill
I see this updates the method descriptions to take on
On 3/11/2013 9:40 AM, Alan Bateman wrote:
On 08/03/2013 02:22, BILL PITTORE wrote:
Moved the string allocation into buildJniFunctionName as Alan
suggested. Built and tested on windows and linux. Updated the webrev:
http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/
bill
I see this
Hi guys,
I'm really glad to see you are doing this. We've done something similar to
good effect within Google (and we'll probably drop our similar, internal
patch and pick up this patch once it is pushed).
Have you thought about support for having a JNI_OnLoad inside of a main
executable that
On 3/7/2013 1:18 PM, Jeremy Manson wrote:
Hi guys,
I'm really glad to see you are doing this. We've done something
similar to good effect within Google (and we'll probably drop our
similar, internal patch and pick up this patch once it is pushed).
Have you thought about support for having
On 07/03/2013 16:36, BILL PITTORE wrote:
I updated the code based on the feedback. To fix the windows symbol
name issue that Dean brought up I added a platform specific function,
buildJniFunctionName. In windows it will properly convert
_JNI_OnLoad@8 to _JNI_OnLoad_libname@8 as well as handle
On 3/7/2013 3:50 PM, Alan Bateman wrote:
On 07/03/2013 16:36, BILL PITTORE wrote:
I updated the code based on the feedback. To fix the windows symbol
name issue that Dean brought up I added a platform specific function,
buildJniFunctionName. In windows it will properly convert
_JNI_OnLoad@8
On 3/7/2013 10:18 AM, Jeremy Manson wrote:
Hi guys,
I'm really glad to see you are doing this. We've done something
similar to good effect within Google (and we'll probably drop our
similar, internal patch and pick up this patch once it is pushed).
Have you thought about support for having
On Thu, Mar 7, 2013 at 3:26 PM, Dean Long dean.l...@oracle.com wrote:
On 3/7/2013 10:18 AM, Jeremy Manson wrote:
Hi guys,
I'm really glad to see you are doing this. We've done something similar
to good effect within Google (and we'll probably drop our similar, internal
patch and pick up
Moved the string allocation into buildJniFunctionName as Alan suggested.
Built and tested on windows and linux. Updated the webrev:
http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.02/
bill
On 3/7/2013 3:50 PM, Alan Bateman wrote:
On 07/03/2013 16:36, BILL PITTORE wrote:
I updated
On 06/03/2013 04:13, BILL PITTORE wrote:
On 3/5/2013 7:36 PM, Dean Long wrote:
If JNI_ONLOAD_SYMBOLS contains something like _JNI_OnLoad@8 on
Windows, you can't just
turn that into _JNI_OnLoad@8_ + libname. I think it needs to be
_JNI_OnLoad_ + libname + @8
I'll look into that. When I built
On 05/03/2013 23:05, bill.pitt...@oracle.com wrote:
This request is tied to bugid 8005716 that deals with adding support
for statically linked JNI libraries.
The JEP is here: http://openjdk.java.net/jeps/178
The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716
The webrevs are here:
On Mar 5, 2013, at 7:36 PM, Dean Long wrote:
If JNI_ONLOAD_SYMBOLS contains something like _JNI_OnLoad@8 on Windows, you
can't just
turn that into _JNI_OnLoad@8_ + libname. I think it needs to be
_JNI_OnLoad_ + libname + @8
Good catch Dean.
Looks like onLoadSymbols[] is unused in
On Mar 6 2013, at 08:21 , Bob Vandette wrote:
For a traditional
JRE that doesn't even require static library support, we'd have to make sure
to run on a VM that
support JNI_VERSION_1_8. It looks like the JDK maintains their own copy of
jni.h.
In earlier days the jni.h file was copied
On 3/5/2013 8:13 PM, BILL PITTORE wrote:
On 3/5/2013 7:36 PM, Dean Long wrote:
If JNI_ONLOAD_SYMBOLS contains something like _JNI_OnLoad@8 on
Windows, you can't just
turn that into _JNI_OnLoad@8_ + libname. I think it needs to be
_JNI_OnLoad_ + libname + @8
I'll look into that. When I built
Hi Bill;
Some notes from reviewing the JDK side changes.
System.java/Runtime.java:
The example which begins with the name If the filename argument, needs to
better identify that L is an example. (Italics?)
java/lang/ClassLoader.java:
NativeLibrary::fromClass could be final.
If JNI_ONLOAD_SYMBOLS contains something like _JNI_OnLoad@8 on
Windows, you can't just
turn that into _JNI_OnLoad@8_ + libname. I think it needs to be
_JNI_OnLoad_ + libname + @8
Looks like onLoadSymbols[] is unused in
Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib().
Instead
Actually for windows I *did* export the undecorated name. I just didn't
see where I did it in the VS IDE. If you don't export the undecorated
name it doesn't work of course.
bill
On 3/5/2013 11:13 PM, BILL PITTORE wrote:
On 3/5/2013 7:36 PM, Dean Long wrote:
If JNI_ONLOAD_SYMBOLS contains
On 3/6/2013 12:50 PM, Mike Duigou wrote:
Hi Bill;
Some notes from reviewing the JDK side changes.
System.java/Runtime.java:
The example which begins with the name If the filename argument, needs to better
identify that L is an example. (Italics?)
Re-worded that a bit.
This request is tied to bugid 8005716 that deals with adding support for
statically linked JNI libraries.
The JEP is here: http://openjdk.java.net/jeps/178
The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716
The webrevs are here:
On 3/5/2013 7:36 PM, Dean Long wrote:
If JNI_ONLOAD_SYMBOLS contains something like _JNI_OnLoad@8 on
Windows, you can't just
turn that into _JNI_OnLoad@8_ + libname. I think it needs to be
_JNI_OnLoad_ + libname + @8
I'll look into that. When I built for windows and ran our test, the
20 matches
Mail list logo
