Dear devel-listers, I found a conflct between rJava and data.table. Actually me questions is where to report it? Should I rather send it directly to the package maintainers or post it on some bug tracker. The problem is that data.table has a function called "J" and rJava uses the same quite intensively. I used the xlsx R package which depends on rJava to write .xls files and ran into an error. write.xls from this package uses the functions and returns an error depending on the sequence the packages were loaded. Error in .jnew("org/apache/poi/xssf/usermodel/XSSFWorkbook") : java.lang.AbstractMethodError: java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; data.table::J rJava::J I can work around this by loading and unloading packages, but I feel this should be addressed because loading these two packages that both deal with tables of data does not seem that unlikely to me. best matt
On Feb 28, 2013, at 5:09 PM, Bunny wrote:> Dear devel-listers, > > I found a conflct between rJava and data.table. Actually me questions is where to report it? > Should I rather send it directly to the package maintainers or post it on some bug tracker. > The problem is that data.table has a function called "J" and rJava uses the same quite intensively. > I used the xlsx R package which depends on rJava to write .xls files and ran into an error. > > write.xls from this package uses the functions and returns an error depending on the sequence the packages > were loaded. > > > Error in .jnew("org/apache/poi/xssf/usermodel/XSSFWorkbook") : > java.lang.AbstractMethodError: java.lang.ClassLoader.loadClass(Ljava/lang/String;)Ljava/lang/Class; > > > data.table::J > rJava::J > > I can work around this by loading and unloading packages, but I feel this should be addressed because > loading these two packages that both deal with tables of data does not seem that unlikely to me. >Can you elaborate on the details as of where this will be a problem? Packages should not be affected since they should be importing the namespaces from the packages they use, so the only problem would be in a package that uses both data.table and rJava -- and this is easily resolved in the namespace of such package. So there is no technical reason why you can't have multiple definitions of J - that's what namespaces are for. The error you report is entirely unrelated to J -- at lest in isolation. If you have a reproducible example, please share it. Cheers, Simon> best > > matt > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > >
Hi, On Thu, Feb 28, 2013 at 5:09 PM, Bunny <bunny at lautloscrew.com> wrote:> Dear devel-listers, > > I found a conflct between rJava and data.table. Actually me questions is where to report it? > Should I rather send it directly to the package maintainers or post it on some bug tracker. > The problem is that data.table has a function called "J" and rJava uses the same quite intensively.[snip] The development version of data.table no longer exports J from, but once could still use J inside data.tabe[ ... ] calls. I reckon using that would solve your problem. I'm not sure what version of data.table you can get by installing from R-forge, but you can either check out from subversion or download the latest source tar-ball from R-forge and install from source ... HTH, -steve -- Steve Lianoglou Graduate Student: Computational Systems Biology | Memorial Sloan-Kettering Cancer Center | Weill Medical College of Cornell University Contact Info: http://cbio.mskcc.org/~lianos/contact
Simon Urbanek wrote :> Can you elaborate on the details as of where this will be a problem? > Packages > should not be affected since they should be importing the namespaces > from the > packages they use, so the only problem would be in a package that > uses both > data.table and rJava -- and this is easily resolved in the namespace > of such > package. So there is no technical reason why you can't have multiple > definitions of J - that's what namespaces are for.Right. It's users using J() in their own code, iiuc. rJava's manual says "J is the high-level access to Java." When they use J() on its own they probably want the rJava one, but if data.table is higher they get that one. They don't want to have to write out rJava::J(...). It is not just rJava but package XLConnect, too. If there's a better way would be interested but I didn't mind removing J from data.table. Bunny/Matt, To add to Steve's reply here's some background. This is well documented in NEWS and Googling "data.table J rJava" and similar returns useful links to NEWS and datatable-help (so you shouldn't have needed to post to r-devel). From 1.8.2 (Jul 2012) : o The J() alias is now deprecated outside DT[...], but will still work inside DT[...], as in DT[J(...)]. J() is conflicting with function J() in package XLConnect (#1747) and rJava (#2045). For data.table to change is easier, with some efficiency advantages too. The next version of data.table will issue a warning from J() when used outside DT[...]. The version after will remove it. Only then will the conflict with rJava and XLConnect be resolved. Please use data.table() directly instead of J(), outside DT[...]. From 1.8.4 (Nov 2012) : o J() now issues a warning (when used *outside* DT[...]) that using it outside DT[...] is deprecated. See item below in v1.8.2. Use data.table() directly instead of J(), outside DT[...]. Or, define an alias yourself. J() will continue to work *inside* DT[...] as documented. From 1.8.7 (soon to be on CRAN) : o The J() alias is now removed *outside* DT[...], but will still work inside DT[...]; i.e., DT[J(...)] is fine. As warned in v1.8.2 (see below in this file) and deprecated with warning() in v1.8.6. This resolves the conflict with function J() in package XLConnect (#1747) and rJava (#2045). Please use data.table() directly instead of J(), outside DT[...]. Matthew