Java 1.4 support

[Gili]

Hi,

Out of curiosity, why does JNA still target Java 1.4? I ask because most other conservative projects have moved on to 1.5 (released over 8 years ago!) or even 1.6 by now. Aside from the performance and API benefits of moving to Java 1.5 I wanted to point out that using Java 1.4 causes Android to issue the following compile-time warnings:

warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.sun.jna.Native$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.

There are a bunch of such warnings for different classes. Any thoughts to upgrading JNA to a newer Java version?

Thanks,
Gili

[Gili]

A quick follow-up. It looks like Android only officially supports Java6 (not earlier, nor later): http://developer.android.com/sdk/index.html

I've personally run into problems with the Android SDK using Java7: http://stackoverflow.com/questions/8538891/bad-class-file-magic-when-using-dx-bat and with maven-android-plugin using Java5: http://code.google.com/p/maven-android-plugin/issues/detail?id=225

In any case, this complicates matters even worse for JNA and Android support. Still waiting to hear from the community. What's your situation? Do your product(s) depend on Java 1.4?

Gili

[Scott Palmer]

On 2012-07-12, at 3:50 PM, Gili wrote:

> A quick follow-up. It looks like Android only officially supports Java6 (not earlier, nor later): http://developer.android.com/sdk/index.html
>
> I've personally run into problems with the Android SDK using Java7: http://stackoverflow.com/questions/8538891/bad-class-file-magic-when-using-dx-bat and with maven-android-plugin using Java5: http://code.google.com/p/maven-android-plugin/issues/detail?id=225
>
> In any case, this complicates matters even worse for JNA and Android support. Still waiting to hear from the community. What's your situation? Do your product(s) depend on Java 1.4?

We just officially switched to requiring Java 7 for our latest product. We've been Java 6 minimum for many years. 1.4 is ancient history as far as I'm concerned.

Scott

[Timothy Wall]

I think it can generally be moved to 1.6. The wince target is a 1.3-1.4 (J2ME) variant, but it's already got some special build tweaks to omit stuff it doesn't like.

The main benefits (other than class file format) of 1.5+ would be applicability of generics to some pointer, structure, and library usage.

[Matthew Ahrens]

On Thu, Jul 12, 2012 at 2:32 PM, Timothy Wall <twal...@java.net> wrote:

I think it can generally be moved to 1.6.  The wince target is a 1.3-1.4 (J2ME) variant, but it's already got some special build tweaks to omit stuff it doesn't like.

The main benefits (other than class file format) of 1.5+ would be applicability of generics to some pointer, structure, and library usage.

That would be great!  We are using JNA quite a bit at Delphix, with libzfs and various other Solaris / Illumos libraries.  We'd appreciate the additional type safety and expressiveness that could come with use of generics.

--matt

[maxb...@googlemail.com]

Hi, how is this meant? Does binary compatibility with Java 1.4 still needed?
I've noticed that the method Function#isVarArgs is using reflection to call Method#isVarArgs. This is very slow compared to calling the method directly (if Java 1.5 is fully supported).

But even if Java 1.4 still has to be supported, there are ways to improve on performance and memory consumption. I tested buffering the reference to the Method#isVarArgs method into a static variable:
https://github.com/Boereck/jna/commit/0abab9938b11669d72516fdbc9302a5132646a6f

In my test runs I got huge memory savings and a considerable performance gain.

[maxb...@googlemail.com]

Additionally the static valueOf methods of the primitive types could be used in Function#invoke(Object[] args, Class returnType, boolean allowObjects) instead of using the constructors. The value cache can save a lot of memory.