[Rd] conflict between rJava and data.table

[Simon Urbanek]

On Mar 1, 2013, at 8:03 AM, Matthew Dowle wrote:

> 
> 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.
> 

For packages there is really no issue - if something breaks in XTConnect then the authors are probably importing the wrong function in their namespace (I still didn't see a reproducible example, though). The only difference is for interactive use so not having conflicting J() [if possible] would be actually useful there, since J() in rJava is primarily intended for interactive use.

Cheers,
Simon


> 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
> 
> 
>