Java bindings - ambiguous Signature
Thursday, 2 January 2014 · 5 messages · last reply 11 Jan 2014
AB
Andy Bunce2 Jan 2014 18:42 #
Hi,
In my ongoing attempts to use various Java libraries, without writing any Java myself, I have trying Apache Tika.
(http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the tika jar on the classpath I hoped the following would work:
import module namespace tika = "java:org.apache.tika.Tika";
declare namespace File="java:java.io.File";
let $file :=File:new("xx.pdf")
return tika:parse($file)It generates the error
Signature 'org.apache.tika.Tika.parse' is ambiguous
Which maybe it is from some perspectives :-). I hoped some type information might be available in the $file variable to resolve this, but it appears not.
I was wondering about the possibility of using Java type at the XQuery level e.g.
let $file as java:java.io.File :=File:new("xx.pdf")
Is there any way to avoid writing the couple of line Java class shim for this and similar cases?
Regards
/Andy
AB
Andy Bunce3 Jan 2014 11:25 #
Or maybe better with a pragma e.g.
return tika:parse(
(# basex:java-type java:java.io.File #){$file}
)Quoted text · Andy Bunce · 29 lines
On Thu, Jan 2, 2014 at 5:42 PM, Andy Bunce <bunce.andy at gmail.com> wrote: > Hi, > > In my ongoing attempts to use various Java libraries, without writing any > Java myself, I have trying Apache Tika. > (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the tika > jar on the classpath I hoped the following would work: > > import module namespace tika = "java:org.apache.tika.Tika"; > declare namespace File="java:java.io.File"; > let $file :=File:new("xx.pdf") > return tika:parse($file) > > It generates the error > Signature 'org.apache.tika.Tika.parse' is ambiguous > > Which maybe it is from some perspectives :-). I hoped some type > information might be available in the $file variable to resolve this, but > it appears not. > I was wondering about the possibility of using Java type at the XQuery > level e.g. > let $file as java:java.io.File :=File:new("xx.pdf") > > Is there any way to avoid writing the couple of line Java class shim for > this and similar cases? > > Regards > /Andy >
FG
Florent Georges3 Jan 2014 12:05 #
Yet another solution (probably the one I prefer) would be to write your own Java class, exposing exactly the API you need, taking care of the interface between XQuery and Java, and deferring actual hard work to the library.
Regards,
--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/
Quoted text · Andy Bunce · 45 lines
On 3 January 2014 11:25, Andy Bunce wrote: > Or maybe better with a pragma e.g. > > return tika:parse( > (# basex:java-type java:java.io.File #){$file} > ) > > > On Thu, Jan 2, 2014 at 5:42 PM, Andy Bunce <bunce.andy at gmail.com> wrote: >> >> Hi, >> >> In my ongoing attempts to use various Java libraries, without writing any >> Java myself, I have trying Apache Tika. >> (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the tika >> jar on the classpath I hoped the following would work: >> >> import module namespace tika = "java:org.apache.tika.Tika"; >> declare namespace File="java:java.io.File"; >> let $file :=File:new("xx.pdf") >> return tika:parse($file) >> >> It generates the error >> Signature 'org.apache.tika.Tika.parse' is ambiguous >> >> Which maybe it is from some perspectives :-). I hoped some type >> information might be available in the $file variable to resolve this, but it >> appears not. >> I was wondering about the possibility of using Java type at the XQuery >> level e.g. >> let $file as java:java.io.File :=File:new("xx.pdf") >> >> Is there any way to avoid writing the couple of line Java class shim for >> this and similar cases? >> >> Regards >> /Andy > > > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
AB
Andy Bunce3 Jan 2014 12:49 #
Yes and I have now done that for this case. However when prototyping it is sometimes nice to quickly try things out to see what might work without the burden of firing up a Java IDE, managing the source etc.
Regards
/Andy
On Fri, Jan 3, 2014 at 11:05 AM, Florent Georges <fgeorges at fgeorges.org>wrote:
Quoted text · Florent Georges · 62 lines
> Yet another solution (probably the one I prefer) would be to write > your own Java class, exposing exactly the API you need, taking care of > the interface between XQuery and Java, and deferring actual hard work > to the library. > > Regards, > > -- > Florent Georges > http://fgeorges.org/ > http://h2oconsulting.be/ > > > On 3 January 2014 11:25, Andy Bunce wrote: > > Or maybe better with a pragma e.g. > > > > return tika:parse( > > (# basex:java-type java:java.io.File #){$file} > > ) > > > > > > On Thu, Jan 2, 2014 at 5:42 PM, Andy Bunce <bunce.andy at gmail.com> wrote: > >> > >> Hi, > >> > >> In my ongoing attempts to use various Java libraries, without writing > any > >> Java myself, I have trying Apache Tika. > >> (http://tika.apache.org/1.4/api/org/apache/tika/Tika.html). With the > tika > >> jar on the classpath I hoped the following would work: > >> > >> import module namespace tika = "java:org.apache.tika.Tika"; > >> declare namespace File="java:java.io.File"; > >> let $file :=File:new("xx.pdf") > >> return tika:parse($file) > >> > >> It generates the error > >> Signature 'org.apache.tika.Tika.parse' is ambiguous > >> > >> Which maybe it is from some perspectives :-). I hoped some type > >> information might be available in the $file variable to resolve this, > but it > >> appears not. > >> I was wondering about the possibility of using Java type at the XQuery > >> level e.g. > >> let $file as java:java.io.File :=File:new("xx.pdf") > >> > >> Is there any way to avoid writing the couple of line Java class shim for > >> this and similar cases? > >> > >> Regards > >> /Andy > > > > > > > > _______________________________________________ > > BaseX-Talk mailing list > > BaseX-Talk at mailman.uni-konstanz.de > > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk > > >
CG
Hi Andy,
Quoted text · Andy Bunce · 4 lines
> It generates the error > Signature 'org.apache.tika.Tika.parse' is ambiguous > > Which maybe it is from some perspectives :-).
In the latest snapshot, I have updated the error feedback to:
Several implementations found for 'Q{org.apache.tika.Tika}parse#1'.
But a better solution would be to choose the function that comes closest to the given XQuery arguments. It won’t be possible to find a mapper that meets all requirements (and past versions of BaseX have demonstrated that this is a difficult problem), but Michael Kay has also put lots of thoughts on this [1], and we could check if his distance calculations could also be applied to the BaseX java mapper.
For now, it’s in fact best to go with the additional Java indirection layer.
Christian
[1] http://www.saxonica.com/documentation/extensibility/functions/choosing-overload.html
Quoted text · Andy Bunce · 18 lines
> I hoped some type information > might be available in the $file variable to resolve this, but it appears > not. > I was wondering about the possibility of using Java type at the XQuery > level e.g. > let $file as java:java.io.File :=File:new("xx.pdf") > > Is there any way to avoid writing the couple of line Java class shim for > this and similar cases? > > Regards > /Andy > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >
Written for BaseX 7.7. BaseX may have changed since: please check the current documentation.
⚡Generated with XQuery