New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow functions from an interface #426
Comments
Allowing a static function on an interface seems reasonable on its face. The SQL/JRT standard does literally say
and does not mention interfaces. Likewise, the PL/Java documentation has historically said "A Java function is declared with the name of a class and a static method on that class". It could be fair to wonder whether the SQL committee really wrote You might try having a static function on an interface, without the The unhelpfulness of the error message is a bit disappointing. It is reported using the overload of It might be worth checking what message is produced running |
Used
Note also that that Hello source only has public interface Hello {
@Function(onNullInput = Function.OnNullInput.RETURNS_NULL)
public static String hello(String toWhom) {
return "Hello, " + toWhom + "!";
}
} but results in 2 separate diagnostics. |
I am further disappointed then that even the standalone compiler is not displaying any of the information from the The duplication of the message probably just reflects the passes of operation within But improving the message handling seems like a secondary priority. I am especially interested in whether you can compile If that works, then all that is needed is to relax this compile-time check to allow an interface also. If it does not work, then attention would also be needed to the runtime code. |
I'll try to remember to try that tomorrow. I would expect it to work though (there is no difference in bytecode for such a call, it's always an |
I'm thinking more about possible subtleties in the PL/Java code that looks it up and constructs the method handle for it. Not that I necessarily expect it won't work, but it's never been advertised or tested and there is room for complications. |
Looks like it works, at least for the simple |
Good to know. |
The SQL/JRT standard has always just said class, but there is no technical obstacle to using static methods on an interface, so relax the annotation-processing-time check that was preventing that. Addresses #426.
Would you have time to try a build from the feature/REL1_6_STABLE/issue426 branch? The Appveyor tests appear failed, but I think that's just because Appveyor fell over. |
Will do, although I currently don't know when that would be. |
PR #446, #443, #442, #441, #445, #444. Addresses issues: Bug #416 crash with SQL_ASCII database and bad vmoptions Doc #419 better document the use of --add-modules in vmoptions Bug #425 install_jar from http URLs, add test to CI Feature #426 allow functions declared on an interface as well as a class Track PG #434 postgres/postgres@b9b21ac broke unpackaged ALTER UPDATE Track JDK #435 check and reject Java 20 builds with JDK-8309515 bug
Believed resolved in 1.6.5. |
It is not an uncommon practice to use an interface as a container for public static methods.
However, adding
@Function
to a public static method in an interface results in a compilation failure:This is a rather unhelpful message to being with: Which method are you talking about? Who is telling me this?
But as far as I can tell, PL/Java has no need to instantiate such an outer class at all, so there seems to be no real reason why it can't be an interface; that should not affect the ability to invoke a contained static method.
The text was updated successfully, but these errors were encountered: