gnupg-for-java updated for GnuPG 2.x

[Hans-Christoph Steiner]

On 03/18/2014 06:24 AM, Werner Koch wrote:
> On Tue, 18 Mar 2014 03:01, hans at guardianproject.info said:
> 
>>  gnupg-for-java does still require the private gpgme header data.h, but its
>> now included in the gnupg-for-java git until someone finds a way to do the
>> same thing with the public gpgme API.
> 
> Can you please explain that?  data.h is internal to gpgme and should
> never be exposed to anyother library.  If there is a need for certain
> information we need to find a way to do that.


The header is included to get the gpgme_data_t struct for two different
optimizations.  I'm open to better ways to implement these :)

The first case is for adding GnuPGData.size() to improve ByteArrayOutputStream
performance.  Since ByteArrayOutputStreams are used to get data out of
GnuPGData, add a size() method so that the ByteArrayOutputStream can
pre-allocate the memory needed, or at least close to the final number.

https://github.com/guardianproject/gnupg-for-java/commit/1c912a1b333968f6f4314cae2e7516e4703d306e

JNIEXPORT jsize JNICALL
Java_com_freiheit_gnupg_GnuPGData_gpgmeSize(JNIEnv* env, jobject self, jlong data)
{
    return (jsize) (DATA(data))->data.mem.size;
}



The second use allows the use of POSIX FILE streams when creating GnuPGData
for files. Previously, GnuPGData(File f) would load the entire contents of the
file into memory, then pass a memory gpgme_data_t to gpgme.  This is horrible
when working with large files or machines with limited memory.  This patch
uses the gpgme function for creating a gpgme_data_t from a POSIX FILE stream.

https://github.com/guardianproject/gnupg-for-java/commit/7f842086c4956a8ed5d55e242b162325618a64fa

JNIEXPORT void JNICALL
Java_com_freiheit_gnupg_GnuPGData_gpgmeDataRelease(JNIEnv* env, jobject self,
        jlong data)
{
    gpgme_data_t dh = DATA(data);
    if (dh->data.stream != NULL)
        fclose(dh->data.stream);
    gpgme_data_release(dh);
}



> BTW, what do you think of putting the Java bindings into gpgme proper.
> We have the lang/ directory for such bindings.  The advantage is that
> this would allow to access internal data structures.

Its too big a project to include into gpgme like that.  That would hamper the
development process and the build process. But moving the main repo to
gnupg.org could make sense, if you want to adopt it as an official GnuPG Java
binding.  I'd change the package to org.gnupg then too.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 969 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140318/e1dc9eed/attachment.sig>