Remove Java Native Interface

[jonasnick]

This was discussed in #508. The main reasons are that the existing Java Native Interface (JNI) bindings would need way more work to remain useful to Java developers but the maintainers and regular contributors of libsecp are not very familiar with Java (and evidently are motivated enough to improve the situation). We don't know who relies on these bindings with the exception of ACINQ who have their own fork at https://github.com/ACINQ/secp256k1/tree/jni-embed/src/java (@sstone). Bitcoinj can optionally use the libsecp bindings.

Ideally, there would be a separate repository owned by Java developers with just the bindings. Until this exists, Java developers relying on libsecp can use ACINQs fork or an older commit of libsecp.

[elichai]

Concept ACK. I think https://github.com/rust-bitcoin/rust-secp256k1 is a success. there's no reason Java/Scala can't have their own. the only way it can also be high quality Java/Scala lib is if it's written by active Java developers.

[laanwj]

Concept ACK. I've never understood why java was "special" in this regard to have its bindings included with secp256k1 itself.

[sstone]

This is fine with us (and not entirely unexpected :)). We'll just update (and probably rework a bit) our own bindings.

[real-or-random]

This is fine with us (and not entirely unexpected :)). We'll just update (and probably rework a bit) our own bindings.

That's great to hear. I think the cleanest thing in the long term will be to separate the bindings from the core library entirely, i.e., not include a verbatim copy the C files in the repo. That should not to be too hard as the changes in your current branch do not touch these files.

[real-or-random]

needs rebase

[jonasnick]

rebased

[elichai]

@schildbach does this affect bitcoinj?
@Christewart does this affect bitcoin-s?

[real-or-random]

@schildbach does this affect bitcoinj?
@Christewart does this affect bitcoin-s?

It would be great to get a statement from you guys. We don't want to to leave anybody in the rain.

[schildbach]

I don't know if anyone is using libsecp256k1 via bitcoinj. You could ask on the bitcoinj mailing list to find out.

[Christewart]

We have forked and maintain our own jni which can be found here and used as a dependency for other JVM based projects

[sipa]

Code review ACK 7d9066a, if we're reasonably confident this won't break things for users (or at least, that they can easily migrate to any of the other developed bindings).

[jonasnick]

I posted a deprecation notice on the bitcoinj mailing list with a 1 month window. https://groups.google.com/forum/#!topic/bitcoinj/IghsPGbH4YI

[real-or-random]

This PR should also remove https://github.com/bitcoin-core/secp256k1/blob/master/build-aux/m4/ax_jni_include_dir.m4 .

[real-or-random]

This PR will "resolve" #379, #466, #508, #517, #608.

[real-or-random]

ACK 642cd06 I read the diff

[jonasnick]

The 1 month window is over and no one complained on the bitcoinj mailing list.

[real-or-random]

Code review ACK 7d9066a, if we're reasonably confident this won't break things for users (or at least, that they can easily migrate to any of the other developed bindings).

ACK 642cd06 I read the diff, and I verified that the diff to 7d9066a, which has been ACKed by sipa, is only the additonal removal of ax_jni_include_dir.m4

[real-or-random]

Merged, thanks for all the "external" feedback!

This PR will "resolve" #379, #466, #508, #517, #608.

@sstone @Christewart I encourage you to look at these issues and PRs to see if there's anything that can be reused for your bindings.