Closed aalucaci closed 11 months ago
The problem is that the packages use reflection API with classes that are not native types (packages shouldn't be using the reflection API to start with as it is inherently unsafe). This was not supported, because it relies on undefined behavior. Just because the class inherits from one of the native types it doesn't necessarily mean that it is safe to drop the class structure for conversion. The glue
example is a bit of a special case, because the class is used just as a tag and doesn't really change the object structure or the semantics of the object, but rJava
has no way of knowing that.
rJava could dispatch on superclasses, but I'll have to check if that causes a fall-out in any rev-deps.
Reproducible example:
> new(J("java.lang.String"), structure("foo", class=c("bar","character")))
Error in FUN(X[[i]], ...) :
Sorry, parameter type `bar' is ambiguous or not supported.
with subclass dispatch enabled:
> new(J("java.lang.String"), structure("foo", class=c("bar","character")))
[1] "Java-Object{foo}"
Hello, I recently had an error while trying to send an email using the package mailR. After some digging I learned that the error was due to the fact that the email subject was created with the glue package, something like this:
The resulting error message: "Sorry, parameter type `glue' is ambiguous or not supported."
To my understanding, the problem actually comes from rJava: https://github.com/s-u/rJava/blob/master/R/reflection.R#L58
stop("Sorry, parameter type", class(a)[1] ,"' is ambiguous or not supported.")
I found similar issues:
Both packages depend on rJava. The latter issue was fixed by adding
as.character()
. My naive guess is that a better idea would be to make the necessary modifications in rJava. In reflection.R,class(x)[1]
is checked. Checkingis.character(x)
instead could help to avoid the errors described above.Thank you in advance for your help, Angela