Initial code for a few Unix 'libc' API(s)

[lgoldstein]

Added some code for 'libc' API(s) - just to get us started. I only added jUnit tests for get/setenv since I cannot test the others (especially the reboot). I can tell you that reboot works since I am using it in another project I wrote and which serves as the trigger for this API.

[twall]

We can start using the newer Arrays.asList("s1", "s2", ...) convention.

[lgoldstein]

Agreed, but I did not write this code. Furthermore, if we really want to make a worthy change it should be along the following lines:

public class MyStructure extends Structure {
     public field1;
     public field2;
     ... etc...

     // No harm in it being 'public' since it is un-modifiable
     public static final List<String> FIELDS = Collections.unmodifiableList(Arrays.asList("field1", "field2", ...etc...));

     @Override
      protected List<String> getFieldOrder() {     
            return FIELDS;
      }
}

The rationale is that the field order is invariant, so there is not need to create a new List every time getFieldOrder is called

[twall]

Fair enough.

On Dec 7, 2015, at 12:34 AM, Lyor Goldstein notifications@github.com wrote:

In contrib/platform/src/com/sun/jna/platform/unix/X11.java:

         protected List getFieldOrder() {

•            return Arrays.asList(new String[] { "red", "redMask", "green", "greenMask", "blue", "blueMask", "alpha", "alphaMask" }); 
  

•            return Arrays.asList(new String[] { "red", "redMask", "green", "greenMask", "blue", "blueMask", "alpha", "alphaMask" });
  

Agreed, but I did not write this code. Furthermore, if we really want to make a worthy change it should be along the following lines:

public class MyStructure extends Structure
{

public
field1;

public
field2;

... etc...

// No harm in it being 'public' since it is un-modifiable

public static final List FIELDS = Collections.unmodifiableList(Arrays.asList("field1", "field2", ...etc...
));

@OverRide

protected List getFieldOrder
() {

return FIELDS
;
}
}

The rationale is that the field order is invariant, so there is not need to create a new List every time getFieldOrder is called

—
Reply to this email directly or view it on GitHub.

[twall]

There's a POSIX on JNA out there somewhere (maybe more than one). Might be worth a look just to see if there's anything valuable inside.

[lgoldstein]

There seems to be quite a lot of valuable code in it (e.g., https://github.com/jenkinsci/jna-posix), but someone has to take the time and effort to port it into JNA (while taking care of the license issues - if any). I know this may sound a bit harsh but I am driven by pure interest - if there is an API I need that is not exposed via JNA I will try to add it (and maybe a few related ones while I am at it). However, I do not see the value of exposing ALL the POSIX APIs - especially ones for which there is pure Java code (e.g., mkdir, read/write from file I/O, etc...). The idea is NOT to write C code in Java but rather to expose the APIs that do something that cannot be done using pure Java easily.

[twall]

I didn't mean value in additional mappings so much as strategies for dealing with idiosyncrasies of different platforms (libc.so vs msvcrt.dll, for instance).

On Dec 7, 2015, at 12:41 AM, Lyor Goldstein notifications@github.com wrote:

There seems to be quite a lot of valuable code in it (e.g., https://github.com/jenkinsci/jna-posix), but someone has to take the time and effort to port it into JNA (while taking care of the license issues - if any). I know this may sound a bit harsh but I am driven by pure interest - if there is an API I need that is not exposed via JNA I will try to add it (and maybe a few related ones while I am at it). However, I do not see the value of exposing ALL the POSIX APIs - especially ones for which there is pure Java code (e.g., mkdir, read/write from file I/O, etc...). The idea is NOT to write C code in Java but rather to expose the APIs that do something that cannot be done using pure Java easily.

—
Reply to this email directly or view it on GitHub.

[lgoldstein]

I agree with you, but unfortunately these idiosyncrasies are not my are of expertise...

[lgoldstein]

Can I merge this pull request then ?

[twall]

Should probably avoid implementing Library except on the final interface class that's going to be defining an INSTANCE variable.

[lgoldstein]

Will do