search

terl / lazysodium-java

A Java implementation of the Libsodium crypto library. For the lazy dev.
https://github.com/terl/lazysodium-java/wiki
Mozilla Public License 2.0
135 stars 47 forks source link

3.6.1 requires JNA classes in public APIs #44

Closed dmitry-timofeev closed 5 years ago

dmitry-timofeev commented 5 years ago

Hi,

3.6.1 changed the method parameter of some public APIs from long to NativeLong from JNA library (e.g., cryptoSignDetached). However, JNA types are not accessible because it has runtime scope in the generated pom.xml. Shan't its scope be changed to compile so that the lazysodium clients don't have to add a dependency on JNA to use lazysodium APIs?

See also https://github.com/exonum/exonum-java-binding/pull/877/commits/5e7356d379e73e592904814294f073a6ccbde557

gurpreet- commented 5 years ago

Hello @dmitry-timofeev,

Yes, so the reason why it's runtime is because Lazysodium for Android also pulls in the JNA Java version which has relatively the same API. I also encountered some errors which prevented me from including it in the compile scope*.

I've taken your suggestion onboard and in version 3.6.2 I have changed it so that JNA is included within the library. Please update to 3.6.2 and see if it works correctly.

Thanks!

* For Gradle users, the scope is implementation.

gurpreet- commented 5 years ago

Just to make a public note here. Changing the scope of JNA from runtime to compile (or for Gradle users, the words api and implementation should be used instead respectfully) introduces a bug.

Specifically it raises a bug that some classes used by JNA cannot be found. This happens because AARs (the packaging format used in Android which is a bit like the JAR packaging format) do not package in dependencies of a library. In Java land packaging a library with its dependencies is called building a "far JAR". So in Android terms, you can't build a "fat AAR"*. This means that some classes will not be found.

So please upgrade to 3.6.3 rather than 3.6.2 👍

* Technically there are libraries that can build fat AARs, but why add yet another dependency and increase the resulting AAR size?

dmitry-timofeev commented 5 years ago

Hi @gurpreet- ,

Thank you! I've tried 3.6.2, but it still has runtime dependency, hence the project fails to compile without explicit JNA dependency.

3.6.3 is not on Bintray at the moment, will check it out once it becomes available :+1:

dmitry-timofeev commented 5 years ago

3.7.0 resolved the issue for us, thanks!