GnuTLS is an open source SSL/TLS library like OpenSSL and it used in a wide variety of open source projects to implement the SSL, TLS or DTLS protocol. Recently though it has been reported that the library has had an issue patched which would allow an attacker to inject malicious data into the communications established by GnuTLS. This wouldn't typically allow the attacker to query random bits of memory to get access to private keys like the OpenSSL heartbleed issue however it does allow the attacker to inject random data to crash the connection or the app and it seems it may also allow them to inject malicious code which would then be run on the remote machine.
If an attacker is able to inject malicious code then this could potentially allow them any level of access to the remote machine depending on the permissions of the app they are attacking including installing malicious services for future access.
This particular bug appears to be a buffer overrun, again a simple bug in C very similar to the OpenSSL heartbleed bug that can lead to disastrous consequences in security and networking code.
Again I wouldn't blame any developer for making an error like this, they are very easy to make and not easy to prevent or detect but it's another demonstration of why languages like Java with features like memory management were created in the first place.
While its still possible to write insecure code in Java you do skip a whole series of potential flaws just as a result of how Java works. If the underlying JVM in Java and the underlying sockets code don't have buffer overrun bugs that can be exploited then the Java code running on top of them is protected from these types of issues.
The native networking code in the Java Virtual Machine runs at a more basic level than the complex code in GnuTLS and therefore has a much smaller attack space. This basic (native) networking library is then wrapped up and presented as a library to Java programs and libraries that implement TLS at the Java level. Because they implement TLS at the Java level there is no risk of buffer overrun or remote code execution from the much more complex TLS/SSL code since the JVM is constantly checking bounds on arrays and handling the memory allocation and deallocation. The only attack space for buffer overruns of this type is limited to the much more simple basic socket handling libraries.
Libraries like GnuTLS often don't really have a choice about what language they use. Other projects written as non-java native apps need to have libraries like GnuTLS available to allow them to do TLS/SSL sessions and I have no doubt that the GnuTLS developers do their utmost to avoid these bugs but it is interesting that the OpenSSL heartbleed bug is clearly not just a one off and that, likely as a result of increased scrutiny, these very serious bugs are showing up and are often issues arising from the fundamental difficulty in programming in a lower level language like C.