«

(If there's a good JNI resource somewhere that I haven't found, please
point me there in the first instance.)

Which is the definitive spec? Is it the book "Programmer's Guide and
Specification" (Guide) , or the online doc "Specification" v1.5 (Spec)?

In the Spec, it says that only ExceptionOccurred(), ExceptionDescribe(),
and ExceptionClear() can be called when an exception is pending (end of
Chapter 2). But the Guide (11.8.2) lists several other functions, among
them ExceptionCheck(). It's not simply a question of which is right, but
rather what various JVM vendors have regarded as correct (regarding the
Spec or the Guide as normative) at various points in time. I'm intending
my code to be portable across multiple platorms and vendors, so want to
be aware of the worst-case situation I'd reasonably have to deal with.
(Having been coding according to the Spec, the Guide now implies I could
afford to be a lot less cautious).

One apparently exception-*un*safe function is PopLocalFrame(), which
makes it unique amongst the resource cleanup functions. Is this
accurate? Is there a reason for this?

I think the Guide says that it can lead to undefined behaviour if your
LocalFrame Pushes and Pops don't match on function exit. So does the JVM
only cleanout the topmost LocalFrame on function exit, reasoning that
it's the only one left?

To clarify, what are all the functions that might FatalError() due to
inability to allocate LocalRefs? Is it anything that returns a LocalRef
*except* NewLocalRef (which just returns NULL)? What about
PopLocalFrame() with a non-NULL argument?

Can GetArrayElems() be called multiple times on the same thread for the
same array? I'd imagine that as this has to work in multiple threads,
each primitve array would need to keep track of a pin count (or all of
it buffers copies if it doesn't do pinning), do single-threaded access
would not be a problem. There's certainly no way to tell if an array has
already been Got further up the stack. Would the Get/Release calls have
to nest? I'm just making sure that the Spec's silence on the matter
means I can do what I like as long as I Release them afterwards.

When directly accessing primitive arrays, is it safe to use non-volatile
pointers? Could a delayed write *really* happen after the buffer has
been released (and that memory has possibly been used for something
else)?

With those functions that take JNI Version parameter, will the resulting
JNIEnv only have those function table entries for that version, or the
most recent one? (i.e. is the supplied version a request for a minimum,
or more exact)? If the former, does this mean that the JNI version
hierarchy is guaranteed never to fork, so there is no ambiguity over the
"latest version"? (My library may create a JVM or attach to a thread in
a variety of circumstances, and it may not be possible to know what the
most appropriate version to request is; I'm hoping the JNI just Does The
Right Thing and saves me some trouble). The same holds for the JavaVM
interface.

After a successful call to EnsureLocalCapacity(N) does this mean the
topmost LocalFrame has N LocalRefs *available*, or in *total* (i.e. less
those already allocated)?

For RegisterNatives, the Spec says the functions passed in must
"nominally" have sig
ReturnType (*)(JNIEnv*, jobject objectOrClass,...);
Does this actually mean they should use a va_list and the C calling
convention, rather than JNICALL and explicit params (as in "ordinary"
native methods)?

The jni.h file seems to assume that sizeof(void*)==sizeof(void(*)()),
and that structures are aligned at this size, and also that va_lists can
be copied (which may not be the case, or C99 wouldn't need a va_copy
macro). Are these implicit restrictions (and any others) documented
anywhere? Have they arisen in any practical porting concerns?

What a lot of questions. Thanks in advance.

John

On Sun, 2 Oct 2005 01:39:49 +0100, "John Perks and Sarah Mount"
<> wrote or quoted :

>Which is the definitive spec? Is it the book "Programmer's Guide and
>Specification" (Guide) , or the online doc "Specification" v1.5 (Spec)?

Online docs will always be more up to date that any book in terms of
spec detail. On the other hand, the spec might as well be written in
a foreign language. It take great skill to figure out what it means.
It is designed more for implementors than developers. A book will
usually explain what the various tools are for and show some sample
code.

I don't think would have stood a chance getting my first JNI apps
going without Liang's book
http://www.amazon.com/exec/obidos/AS...nadianmindprod

Today you might stand a better chance because there is more sample
code on the web and more people familiar with it you can ask questions
of.

For links to JNI FAQs, The spec, part of Sun/Liang's book etc. see
http://mindprod.com/jgloss/jni.html#LEARNINGMORE

I was surprised to find Sun linking to my site as a JNI resource. That
is even more surprising when you discover how I teased them for its
complexity.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.

From: "Roedy Green" < >
> On Sun, 2 Oct 2005 01:39:49 +0100, "John Perks and Sarah Mount"
> <> wrote or quoted :
> >Which is the definitive spec? Is it the book "Programmer's Guide and
> >Specification" (Guide) , or the online doc "Specification" v1.5
(Spec)?
> I don't think would have stood a chance getting my first JNI apps
> going without Liang's book
> http://www.amazon.com/exec/obidos/AS...nadianmindprod

That's the "Guide" I was referring to (you can download it all from
Sun). Both it and the online spec seem to regard themselves as
definitive, but sometimes they contradict one another (which functions
can be called while an exception is pending) or they're seemingly vague
(exactly which functions can FatalError in event of LocalRef
exhaustion). Whom/Where should I ask about resolving something like
that? Is there anyone here who's actually had to implement JNI itself,
and run up against speccing issues?

(I'm assuming where the Liang book contradicts itself by saying "The
virtual machine exits if it fails to allocate the memory.", then later
syaing it throws an exception (viz PushLocalFrame/EnsureLocalCapacity),
the latter is the case.)

Crucially, these documents differ over what will lead to Undefined
Behaviour (most notably in the area of pending exceptions.) While it may
be safe to assume that Sun's implementation satifies both these sets of
requirements, a different implementation may only work to the online
Spec whithout even knowing there's another "definitive" book out there,
leading to differing notions of what is safe; when I call
DeleteLocalRef() on *their* implementations, I could be engaging in
Undefined Behaviour.

http://java.sun.com/j2se/1.5.0/docs/...n.html#wp17626
"When there is a pending exception, the only JNI functions that are safe
to call are ExceptionOccurred(), ExceptionDescribe(), and
ExceptionClear()." with no mention of ExceptionCheck(), or that
currently ExceptionDescribe clears the exception as well (bug or
feature?).

I am also wondering how to program defensively. You can't just call
ExceptionOccurred(), as that might FatalError() becuause it's out of
LocalRefs. So before doing that, you call EnsureLocalCapacity()... but
you can't do that because an exception might be pending. And so on.

> Today you might stand a better chance because there is more sample
> code on the web and more people familiar with it you can ask questions
> of.

From the response, they don't seem to gather here. Where's the best
place to look? I mailed jni@java (as they suggest somewhere) some time
ago and didn't get so much as an autoreply.

> I was surprised to find Sun linking to my site as a JNI resource. That
> is even more surprising when you discover how I teased them for its
> complexity.

I don't find it complex, just under-specced in places.

Thanks

John

On Wed, 5 Oct 2005 11:25:01 +0100, John Perks and Sarah Mount wrote:
> currently ExceptionDescribe clears the exception as well (bug or
> feature?).

Bug 4067541, "closed, not reproducible" according to Sun. But see also
4973054.

> From the response, they don't seem to gather here. Where's the best
> place to look? I mailed jni@java (as they suggest somewhere) some time
> ago and didn't get so much as an autoreply.

Well, there is the native methods forum at forum.java.sun.com, and in
c.l.j.machine you might come across one or two JVM implementers. You
might also check out the JVM spec.

There is also the (no longer maintained) Java spec report, a site
covering ambiguities in the JLS and (at least so I vaguely remember)
the JVM spec.

I believe that most c.l.j.machine readers also read this group, at any
rate there are a few of us who usually answer most JNI-related
questions. I don't consider myself an expert at JNI per se, just a
compentent C programmer (which is what most JNI problems boil down to
anyway).

> I don't find it complex, just under-specced in places.

I agree.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

"Gordon Beaton" <> wrote in message
news:4343b057$...
> There is also the (no longer maintained) Java spec report, a site
> covering ambiguities in the JLS and (at least so I vaguely remember)
> the JVM spec.

I found that a very interesting way to start learning Java. Shame it's
no longer running.

> I believe that most c.l.j.machine readers also read this group, at any
> rate there are a few of us who usually answer most JNI-related
> questions. I don't consider myself an expert at JNI per se, just a
> compentent C programmer (which is what most JNI problems boil down to
> anyway).

I'll pop next door and give them a try.

Thanks for your help.

John.

On Sun, 2 Oct 2005 01:39:49 +0100, "John Perks and Sarah Mount"
<> wrote or quoted :

>Which is the definitive spec? Is it the book "Programmer's Guide and
>Specification" (Guide) , or the online doc "Specification" v1.5 (Spec)?

see link at http://mindprod.com/jgloss/jni.html
Also misc tips and links.

The spec is not for the fainthearted. You pretty well already have to
know it to make much sense of it. I think you need a textbook. I am
unaware of tutorials.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.