Fix warnings about using raw types

Eclipse generates this kind of warning:

org/libvirt/jna/virConnectCredential.java:20:
List is a raw type. References to generic type List<E> should be parameterized

Signed-off-by: Claudio Bley <cbley av-test de>
Fix warnings about accessing static methods

java/org/libvirt/Error.java:217:
The static method wrap(int) from the type Error.ErrorDomain should be
accessed in a static way

Signed-off-by: Claudio Bley <cbley av-test de>
Fix typos in Error.java

Signed-off-by: Claudio Bley <cbley av-test de>
test: fix typo in testConnection()

Signed-off-by: Claudio Bley <cbley av-test de>
test: ensure that exceptions are thrown when expected

Signed-off-by: Claudio Bley <cbley av-test de>
Make comments proper javadoc comments for enum constants

Signed-off-by: Claudio Bley <cbley av-test de>
Ignore editor backup files

Signed-off-by: Claudio Bley <cbley av-test de>
Depend on JNA versions 3.4.1 to 4.0.0

Specify a version range for the net.java.dev.jna / jna artifact
in order to accept any version we tested the libvirt Java bindings
against.

Signed-off-by: Claudio Bley <cbley av-test de>
jna: load virt-0 or virt library depending on the platform

On Windows, the libvirt DLL is called libvirt-0.dll. Trying to load
the "virt" library hence fails to find the file. Branch on the platform
and load "virt-0" if we're running on this OS, use "virt" otherwise.

Signed-off-by: Claudio Bley <cbley av-test de>
Fix wrapping of native size_t data type

Libvirt function parameters having type (pointer to) size_t were
wrapped via JNA using int, long or even NativeLong. Alas, none of
these is actually correct as the size of size_t may be the same as the
size of either (unsigned) int, long or even long long on different
platforms.

JNA provides the size of a native size_t to us, so using this
information we define and use class SizeT and class SizeTByReference for
wrapping a native size_t and size_t*, respectively.

Signed-off-by: Claudio Bley <cbley av-test de>
Use virFree in order to release memory acquired from libvirt

When JNA is linked to a different runtime library than libvirt, using
JNA's Native.free will probably lead to crashes as witnessed on
Windows:

 # A fatal error has been detected by the Java Runtime Environment:
 #
 #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000077363290, pid=10180, tid=9908
 #
 # JRE version: 7.0_25-b16
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode windows-amd64 compressed oops)
 # Problematic frame:
 # C  [ntdll.dll+0x53290]  RtlFreeHeap+0xd0

The root cause is that the libvirt DLL uses MSVCRT as its runtime
library, whereas the jnidispatch DLL of JNA uses a different one.

At runtime, when calling org.sun.com.jna.Native.free() the OS function
RtlFreeHeap is called with an invalid Pointer that was actually
allocated by MSVCRT's malloc.

Basically, we cannot simply mix and match memory allocation functions
from different runtime libraries, but have to call virFree for
pointers orignating from libvirt itself.

So, this patch re-adds and uses the virFree method which had been
removed in commit 3220de292990bed71828fba2f3700bc846d440f2.

Signed-off-by: Claudio Bley <cbley av-test de>
tests: remove obsolete test driver

JUnit is used for quite some time now, which supercedes the tests
defined in the old "test" class.

Signed-off-by: Claudio Bley <cbley av-test de>
Make Device.listCapabilities return only valid array elements

The libvirt function virNodeDeviceListCaps might return fewer elements
than requested.  Take this into account and properly decode the UTF-8
strings returned.

Additionally, the given strings are freed before returning the resulting
string array.

Signed-off-by: Claudio Bley <cbley av-test de>
test: ensure the Device.listCapabilities method works

Signed-off-by: Claudio Bley <cbley av-test de>
Start refactoring of error handling

Almost every class contains a processError() method with an identical
definition, just forwarding the call to ErrorHandler.processError(Libvirt).

This function is always called after a libvirt function call (as per its
javadoc comment).

But, actually, there's no use in always calling processError when there was
no error signalled by the libvirt function having been called. This is just
a waste of CPU cycles.

Furthermore, it's more than ugly that the error handling is littered all
over the place in every class.

This patch lays ground for generalizing the error handling in a common
place and removing those functions from the individual classes.

Basically, this copies the processError(int) and processError<T>(T)
methods from the Connect class to the ErrorHandler class as static
methods.

It deprecates the processError(Libvirt) method, which will be removed
eventually in a later patch.

Signed-off-by: Claudio Bley <cbley av-test de>
Remove processError from Device class

Wrap any fallible libvirt function in a call to ErrorHandler.processError(..).

Signed-off-by: Claudio Bley <cbley av-test de>
Remove processError from Domain class

Wrap any fallible libvirt function in a call to ErrorHandler.processError(..).

Also update erroneous javadoc comments stating that methods would return a
value in case an error occurs.  In case of a libvirt error, a
LibvirtException is thrown.

Add processErrorIfZero(long) to ErrorHandler class to handle special
libvirt return codes, such as for virDomainGetMaxMemory. Use it in
Domain.getMaxMemory().

Signed-off-by: Claudio Bley <cbley av-test de>
Remove processError from DomainSnapshot class

Wrap any fallible libvirt function in a call to ErrorHandler.processError(..).

Also correct wrong javadoc comments stating that methods would return
a value in case an error happens.

Signed-off-by: Claudio Bley <cbley av-test de>
Remove processError from Interface class

Wrap any fallible libvirt function in a call to ErrorHandler.processError(..).

Also correct wrong javadoc comments stating that methods would return
a value in case an error occurs.

Signed-off-by: Claudio Bley <cbley av-test de>
Remove processError method from Network class

Wrap any fallible libvirt function in a call to ErrorHandler.processError(..).

Also correct wrong javadoc comments stating that methods would return
a value in case an error occurs.

Signed-off-by: Claudio Bley <cbley av-test de>