Support string type codes for pyjarray creation.

[bsteffensmeier]

I like the way that the python array module uses simple one character type codes for specifying the array type and I would like to have similar support for jarray construction. Currently primitive jarrays must be created using the J*_ID constants defined in the jep module. It would be convenient to use the same type codes as the python array module but I ran into some problems

1) There is no character for boolean 2) The character that makes sense for char is 'u' but that is deprecated 3) I think we would use 'l' for java int and 'q' for java long and I'm not sure what we could do with 'i'. I think 'l' for int would confuse java developers.

Numpy also has support for similar typestrs but since they encode the length of the type that is harder to parse and I feel like it is less intuitive especially since we only support a very small set of types compared to numpy. I settled on the JNI type characters in lowercase(z, b, c, s, i, j, f or d). This perfectly matches the types we support. There still may be some confusion since 'j' is used for long but I would rather defer to an existing "standard" instead of come up with our own system.

I want to continue to support jep.J*_ID from python for backwards compatibility but I want the public API to reflect that we are supporting type codes instead of ints for these so I switched them to the type codes.

jep.JSTRING_ID does not have a type code, I think we should drop that field at some point and encourage developers to just import and use java.lang.String. For for this change I chose to preserve backwards compatibility so I made JSTRING_ID the pyjclass for java.lang.String

Another problem with this change is that the c code has J*_ID constant that no longer match the python constants. These constants cannot be strings because they are used in switch statements. Eventually I think they should be changed to the char/ascii/unicode values for the type code but for this change I left the existing values. Since they are only used internally there is no user facing impact except if there is any case where developers have hardcoded the numerical constant it will still work now.

While testing I notices that passing a primitive class, such as java.lang.Integer.TYPE, into jarray would crash, so I made code to handle that case and return a primitive array. Perhaps JINT_ID should be set to java.lang.Integer.TYPE instead of a type code? I like the type code more.

Below is a summary of the major design decisions in this change. I'd appreciate input to see if others have different opinions on any of these.

1) Should we support types codes?

• Yes 2) Which typecodes?
• JNI specification (z, b, c, s, i, j, f or d). 3) What should we use for the values of the primitive jep.J*_ID constants
• Changed from ints to type codes(String). 4) What about jep.JSTRING_ID?
• JSTRING_ID will be a pyjclass for java.util.String, the same valyue you would get with from java.lang import String 5) What backwards compatibilty features will remain now but be removed in the future.
• Change internal c constants for J*ID for primitive to be the char/ascii/unicode value matching the python char and remove support for passing int values to jep.jarray. This will only affect users who hardcoded the old int values.
• Remove jep.JSTRING_ID, developers who are using it would have to switch to from java.lang import String 6) When should those backwards compatibiltiy features be removed.
• TBD I would be fine with removing them in 4.1 but if they aren't causing trouble they may last longer.

[ndjensen]

I think we should remove JSTRING_ID in 4.0.