My sbt plugin is working

Mark Hammons mark.hammons at inaf.cnrs-gif.fr
Mon Nov 11 12:40:34 UTC 2019


After researching scala and the @varargs annotation for it, it seems to me 
that this incompatibility is something that will probably not be able to be 
overcome with pure scala code. It seems that if I define a method like:

@varargs def fn(i: Int*): Unit

The scala compiler will generate two methods:

def fn(i: Array[Int]): Unit = { fn(i: _*) }
def fn(i: Seq[Int]): Unit

which would allow java code to call into the fn method, but java.foreign needs 
an abstract method it can define at runtime. Worse off, with this two method 
approach I do not have the control over annotation that I would need to make 
sure that java.foreign would try to bind to the correct abstract method or at 
least not get confused. 

I have a solution in the works that involves me emitting a stub java interface 
with the vararg methods defined, and which the generated scala trait will 
inherit from.

However, I was curious if it would be feasible for java.foreign to be a little 
more lenient in what it binds to. If I were able to define a method like this 
in scala:
@NativeFunction("(i32*)v")
def fn(i: Array[Int]): Unit

and have java foreign recognize that as a valid binding, that would allow me 
to have a pure scala binding and make java.foreign 100% compatible with scala. 
I'm hopefuly that this is a possibility, though I'd understand if it's not 
something the project panama team wants to do or devote resources to.

Thanks,
Mark

On Sunday, November 10, 2019 6:06:17 PM CET you wrote:
> Hi All,
> 
> I finally got a prototype of my sbt plugin for generating scala (dotty)
> bindings to C using the foreign apis.
> 
> https://github.com/markehammons/sbt-shackle
> 
> Right now the only weakness it has compared to jextract bindings is that
> I cannot currently bind functions with varargs. Sadly, dotc doesn't seem
> capable of encoding dotty varargs parameters in a java compatible way
> yet. Once I have my plugin able to generate scala 2 bindings, I think
> this problem will be solved.
> 
> ~Mark






More information about the panama-dev mailing list