Merge: jwrapper supports static properties, primitive arrays and generic parameters
authorJean Privat <jean@pryen.org>
Thu, 30 Jul 2015 00:04:27 +0000 (20:04 -0400)
committerJean Privat <jean@pryen.org>
Thu, 30 Jul 2015 00:04:27 +0000 (20:04 -0400)
commit2bfe88749dc76ddde87ff5b10ab1dc5dfb0fb042
treec7063bd23c84c7fca168200a337d26b6f0c22278
parent7dfb1958f475d1adc258d03b05ea144a8f93e7a7
parent4c75a01daf6a9a3a18fec173a5d2ec43544c929c
Merge: jwrapper supports static properties, primitive arrays and generic parameters

This PR continues the work of #1578 and #1589. It improves jwrapper to support more features of the Java language: static functions and attributes, primitives arrays and generic parameters. The resulting generated wrapper of large Java namespaces is now usable with semi-global compilation!

Main changes:

* Wrap static functions and attributes as top-level methods.

* Generate a primitive array wrapper for each target class. By default, only wrap 1 dimension arrays, it's enough in most cases (see stats at the bottom).

* Resolve generic parameters and use the closest bound (only the first bound).

* Add JNI services to each classes.

* Jwrapper is now good enough to wrap the `java` and `org` namespace of the Java library
  and to use them in semi-global compilation. See the new example `java_api` to see it in action.

  The _full_ Java generated by this tool and by the FFI pass the basic semantic check of javac,
  but it still raise errors and warnings on illegal access of internal, protected or obsolete entities.
  This may need manual tweaking of the tool to block these cases, that information is not made available by the output of javap.

  Compiling `java_api` in separate compilation takes about 20 minutes and crashes at the compilation of the generated C code. More investigation is required to find the problem, but I suspect the C file of 132 mo generated by the FFI to manipulate the JNI.

What's to do next:
* Class hierarchy!
* Negative filtering of the target classes in a Jar archive.
* Filtering of methods to avoid obsolete ones? Or simply remove them manually after generation?
* vararg support.
* Revamp the `java` module and low-level types.

## Some stats on the Android lib example

Disabled functions before this PR:
* java_api.nit: 1448 / 12805
* android_api.nit: 1075 / 22084

Disabled functions now:
* java_api.nit: 5 / 14248 # From a multi-dimensional array
* java_api.nit: 29 / 14248 # From a vararg
* android_api.nit: 1 / 23138 # From a multi-dimensional array
* android_api.nit: 21 / 23138 # From a vararg

All the unknown multi-dimensional array: (these could be added by hand to the library)
* int[][]
* java.lang.String[][]
* java.lang.annotation.Annotation[][]

Pull-Request: #1599
Reviewed-by: Jean Privat <jean@pryen.org>
Reviewed-by: Lucas Bajolet <r4pass@hotmail.com>