It seems we are having a problem here. The interface is now parametrized by two type variables, where one is used exclusively for converting StatementGroups. I can see why you did this -- you want JSONObject in most cases and JSONArray in this one case. But what makes us think that StatementGroups need a "special" type and all other methods can use the same type? There is really no reason. If any other object would be serialized as an array in our JSON, then we would need JSONArray in these cases as well. In other words: if we would change the details of how we export objects to JSON, then it would no longer be possible to use this interface. This is not good.

Of course, json.org should have a common superclass of things that can be serialized in JSON. Instead, it uses java.lang.Object as its only superclass. This seems to be a design issue that should be fixed, since it ties formatting details to class names. Maybe the underlying reason is that JSONArray cannot be serialized (unless it is nested in a JSON object)? Is this the case? If yes, then we should not have a public method that returns such an array. All our public methods should return a common type that can be treated in a similar fashion. If this does not work for StatementGroups here, we could make the current implementation into an internal helper method and throw an UnsupportedOperationException on the public method (that is supposed to return a JSONObject, which it cannot).

I wonder if we should use a more modern JSON library. This one seems to have quite a few issues in its class model (I just came across another one reviewing Fredo's code: they return unspecified generic objects that you have to typecast to use, although they could really know a much more specific type).