RFR: 7903788: preparation towards json configuration for jextract tool

[Maurizio Cimadamore]

On Fri, 16 Aug 2024 11:49:29 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> * adding json skara code into org.openjdk.jextract.json.parser package. Minor changes done - pretty printing, JSONValue is made sealed and access changes (private final fields).
> * org.openjdk.jextract.json package for JSON interface to the rest of the jextract tool. Main interface is org.openjdk.jextract.json.JSON. parse and toString methods to convert record into JSON String and vice versa.
> * Other classes are public mainly for testing purposes. build.gradle adjusted with the required --add-exports clauses so that jextract module does not have to export the new json packages.

src/main/java/org/openjdk/jextract/json/JSONObjects.java line 362:

> 360:         Type[] typeArgs = pt.getActualTypeArguments();
> 361:         Type nthType = typeArgs.length > n ? typeArgs[n] : Object.class;
> 362:         if (nthType instanceof WildcardType wt) {

This logic is not correct. E.g. if something is `List<? super Integer>` it is not correct to assume that the type argument is `String` (and e.g. create a `Integer[]` as a result). Because `List<? extends Number>` can have `Number` elements which won't go in an `Integer[]`.

In general, I think it might be appropriate to dial down the level of "smartness" and try to provide something that is well-behaved, and good enough for what we need. We don't need to solve the general problem of mapping json to Java, we just need a mapping that is good enough for jextract to use.

So... I think we'd be ok if wildcards won't be accepted by the mapper.

-------------

PR Review Comment: https://git.openjdk.org/jextract/pull/257#discussion_r1719824604