This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: JNI issues

Martin Kahlert wrote:

> > There are some coding style problems in the patch.
> I assume, i should find out the correct formatting options for vim, first.
> Or do you mean the coding itself?

We try to follow the GNU and GCC formatting/style conventions in libgcj. See

> > Also, before I can apply it I need the appropriate paperwork from you.
> > It will take me a while to dig this up, as the FSF changed their
> > procedures.
> For these ~10 lines of quite trivial code? Are you kidding?

Unfortunately, he's not. The FSF requires copyright assignment for any "large"
code changes. Bug fixes like this are admittedly relatively canonical and should
be covered under the "small change" rule, but GCJ has previously interpreted
this conservatively. Perhaps this could be reconsidered?

Personally, I think the whole "FSF assignment" policy does far more harm than
good - it discourages people from contributing and makes it very difficult for
us to use code from other non-FSF-owned projects even if their license is

> where _Jv_ThreadCurrent() returns NULL and thus the last line results in
> a SegFault.
> Do you think, that the invocation API can be corrected, or do you think, that
> it has to be rewritten from ground? I don't have the overview to decide this.

The basic problem here is that the current thread was not started with the
normal thread startup sequence (ie "new Thread(); thread.start();") so does not
have any Java thread object/data associated with it. We need to implement a
mechanism such that a java.lang.Thread (and other data used by the runtime) can
get "attached" to an already running thread.


  [ bryce ]

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]