Java interop with List and immutable Set

You're better off using JavaConverters.  When stuck deep into interop territory, I'll usually offer twin interfaces using the java getter/setter convention:
import collection.JavaConverters._ import java.{util => ju}
class Bippy {  val daList: List[String] = ...  def getDaList: ju.List[String] = daList.asJava}

OR, if you prefer to isolate things (and have a nice java-only interface you can pass around)

trait BippyJava {  self: Bippy =>  def getDaList: ju.List[String] = self.daList.asJava }
class Bippy extends BippyJava {  val daList: List[String] = ...}


On Tuesday, 29 November 2011, Russ P. wrote:

Suppose some Java code calls some Scala code that returns a List or an
immutable Set. Can I get the Java code to understand it? How? I don't
seem to see the required conversions in JavaConversions. Thanks.

--Russ P.

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

Thanks, that was helpful. But why do we have both JavaConversions and
JavaConverters? How would anyone know which one to prefer if you
aren't there to tell them? Should JavaConversions perhaps be
deprecated?

--Russ P.

On Nov 29, 12:28 am, Kevin Wright wrote:
> You're better off using JavaConverters.  When stuck deep into interop
> territory, I'll usually offer twin interfaces using the java getter/setter
> convention:
>
> import collection.JavaConverters._
> import java.{util => ju}
>
> class Bippy {
>   val daList: List[String] = ...
>   def getDaList: ju.List[String] = daList.asJava
>
> }
>
> OR, if you prefer to isolate things (and have a nice java-only interface
> you can pass around)
>
> trait BippyJava {
>   self: Bippy =>
>   def getDaList: ju.List[String] = self.daList.asJava
>
> }
>
> class Bippy extends BippyJava {
>   val daList: List[String] = ...
>
> }
> On Tuesday, 29 November 2011, Russ P. wrote:
> > Suppose some Java code calls some Scala code that returns a List or an
> > immutable Set. Can I get the Java code to understand it? How? I don't
> > seem to see the required conversions in JavaConversions. Thanks.
>
> > --Russ P.
>
> --
> Kevin Wright
> mail: kevin.wri...@scalatechnology.com
> gtalk / msn : kev.lee.wri...@gmail.com
> quora:http://www.quora.com/Kevin-Wright
> google+:http://gplus.to/thecoda
>
> twitter: @thecoda
> vibe / skype: kev.lee.wright
> steam: kev_lee_wright
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side
> of the ledger" ~ Dijkstra

Many would argue "yes, JavaConversions should be deprecated".  JavaConverters is a much more recent addition to the library, inspired in large part by scalaj-collect and prompted by a trac ticket of mine concerning implicit lookup of the conversion functions.
I've seen the occasional codebase where it looks cleaner to hide the fact that you're converting[1] a collection between java and scala, but this is a short-sighted view.  As Martin, Josh, etc. recently stated on another thread, it's always far preferable to define a clear boundary between pure Scala and Java interop code, and to make any conversions explicit at this boundary.

[1] "Converting" is a bit of a misnomer, in most cases what you'll actually get is a thin wrapper that implements the required interface.

On Thursday, 1 December 2011, Russ P. wrote:

Thanks, that was helpful. But why do we have both JavaConversions and
JavaConverters? How would anyone know which one to prefer if you
aren't there to tell them? Should JavaConversions perhaps be
deprecated?

--Russ P.

On Nov 29, 12:28 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> You're better off using JavaConverters.  When stuck deep into interop
> territory, I'll usually offer twin interfaces using the java getter/setter
> convention:
>
> import collection.JavaConverters._
> import java.{util => ju}
>
> class Bippy {
>   val daList: List[String] = ...
>   def getDaList: ju.List[String] = daList.asJava
>
> }
>
> OR, if you prefer to isolate things (and have a nice java-only interface
> you can pass around)
>
> trait BippyJava {
>   self: Bippy =>
>   def getDaList: ju.List[String] = self.daList.asJava
>
> }
>
> class Bippy extends BippyJava {
>   val daList: List[String] = ...
>
> }
> On Tuesday, 29 November 2011, Russ P. wrote:
> > Suppose some Java code calls some Scala code that returns a List or an
> > immutable Set. Can I get the Java code to understand it? How? I don't
> > seem to see the required conversions in JavaConversions. Thanks.
>
> > --Russ P.
>
> --
> Kevin Wright
> mail: kevin.wri...@scalatechnology.com
> gtalk / msn : kev.lee.wri...@gmail.com
> quora:http://www.quora.com/Kevin-Wright
> google+:http://gplus.to/thecoda
> <kev.lee.wri...@gmail.com>
> twitter: @thecoda
> vibe / skype: kev.lee.wright
> steam: kev_lee_wright
>
> "My point today is that, if we wish to count lines of code, we should not
> regard them as "lines produced" but as "lines spent": the current
> conventional wisdom is so foolish as to book that count on the wrong side
> of the ledger" ~ Dijkstra

--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On Thu, Dec 1, 2011 at 9:16 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Many would argue "yes, JavaConversions should be deprecated".  JavaConverters is a much more recent addition to the library, inspired in large part by scalaj-collect and prompted by a trac ticket of mine concerning implicit lookup of the conversion functions.
I've seen the occasional codebase where it looks cleaner to hide the fact that you're converting[1] a collection between java and scala, but this is a short-sighted view.  As Martin, Josh, etc. recently stated on another thread, it's always far preferable to define a clear boundary between pure Scala and Java interop code, and to make any conversions explicit at this boundary.

I (for one) still find many places where JavaConversions is perfectly safe and more appealing than JavaConverters. The respective Scaladoc does a good job as explaining the differences. So -1 to deprecation.
-jason

+1 for -1

On Dec 1, 2011 9:20 AM, "Jason Zaugg" <jzaugg@gmail.com> wrote:

On Thu, Dec 1, 2011 at 9:16 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Many would argue "yes, JavaConversions should be deprecated".  JavaConverters is a much more recent addition to the library, inspired in large part by scalaj-collect and prompted by a trac ticket of mine concerning implicit lookup of the conversion functions.
I've seen the occasional codebase where it looks cleaner to hide the fact that you're converting[1] a collection between java and scala, but this is a short-sighted view.  As Martin, Josh, etc. recently stated on another thread, it's always far preferable to define a clear boundary between pure Scala and Java interop code, and to make any conversions explicit at this boundary.

I (for one) still find many places where JavaConversions is perfectly safe and more appealing than JavaConverters. The respective Scaladoc does a good job as explaining the differences. So -1 to deprecation.
-jason

Is that +1 * -1 ?

On Thu, Dec 1, 2011 at 5:20 PM, Chris Twiner <chris.twiner@gmail.com> wrote:

+1 for -1

On Dec 1, 2011 9:20 AM, "Jason Zaugg" <jzaugg@gmail.com> wrote:

On Thu, Dec 1, 2011 at 9:16 AM, Kevin Wright <kev.lee.wright@gmail.com> wrote:

Many would argue "yes, JavaConversions should be deprecated".  JavaConverters is a much more recent addition to the library, inspired in large part by scalaj-collect and prompted by a trac ticket of mine concerning implicit lookup of the conversion functions.
I've seen the occasional codebase where it looks cleaner to hide the fact that you're converting[1] a collection between java and scala, but this is a short-sighted view.  As Martin, Josh, etc. recently stated on another thread, it's always far preferable to define a clear boundary between pure Scala and Java interop code, and to make any conversions explicit at this boundary.

I (for one) still find many places where JavaConversions is perfectly safe and more appealing than JavaConverters. The respective Scaladoc does a good job as explaining the differences. So -1 to deprecation.
-jason

No, we don't use symbolic method names here, they're confusing!

add(1.multiply(1.minus))

On 2 December 2011 07:55, Naftoli Gugenheim wrote:
> Is that +1 * -1 ?
>
>
> On Thu, Dec 1, 2011 at 5:20 PM, Chris Twiner wrote:
>>
>> +1 for -1
>>
>> On Dec 1, 2011 9:20 AM, "Jason Zaugg" wrote:
>>>
>>> On Thu, Dec 1, 2011 at 9:16 AM, Kevin Wright
>>> wrote:
>>>>
>>>> Many would argue "yes, JavaConversions should be deprecated".
>>>>  JavaConverters is a much more recent addition to the library, inspired in
>>>> large part by scalaj-collect and prompted by a trac ticket of mine
>>>> concerning implicit lookup of the conversion functions.
>>>>
>>>> I've seen the occasional codebase where it looks cleaner to hide the
>>>> fact that you're converting[1] a collection between java and scala, but this
>>>> is a short-sighted view.  As Martin, Josh, etc. recently stated on another
>>>> thread, it's always far preferable to define a clear boundary between pure
>>>> Scala and Java interop code, and to make any conversions explicit at this
>>>> boundary.
>>>
>>>
>>> I (for one) still find many places where JavaConversions is perfectly
>>> safe and more appealing than JavaConverters. The respective Scaladoc does a
>>> good job as explaining the differences. So -1 to deprecation.
>>>
>>> -jason
>
>

On Fri, Dec 2, 2011 at 12:36 PM, Alec Zorab <aleczorab@googlemail.com> wrote:

No, we don't use symbolic method names here, they're confusing!

add(1.multiply(1.minus))

add(One.multiply(One.minus))
 

On 2 December 2011 07:55, Naftoli Gugenheim <naftoligug@gmail.com> wrote:
> Is that +1 * -1 ?
>
>
> On Thu, Dec 1, 2011 at 5:20 PM, Chris Twiner <chris.twiner@gmail.com> wrote:
>>
>> +1 for -1
>>
>> On Dec 1, 2011 9:20 AM, "Jason Zaugg" <jzaugg@gmail.com> wrote:
>>>
>>> On Thu, Dec 1, 2011 at 9:16 AM, Kevin Wright <kev.lee.wright@gmail.com>
>>> wrote:
>>>>
>>>> Many would argue "yes, JavaConversions should be deprecated".
>>>>  JavaConverters is a much more recent addition to the library, inspired in
>>>> large part by scalaj-collect and prompted by a trac ticket of mine
>>>> concerning implicit lookup of the conversion functions.
>>>>
>>>> I've seen the occasional codebase where it looks cleaner to hide the
>>>> fact that you're converting[1] a collection between java and scala, but this
>>>> is a short-sighted view.  As Martin, Josh, etc. recently stated on another
>>>> thread, it's always far preferable to define a clear boundary between pure
>>>> Scala and Java interop code, and to make any conversions explicit at this
>>>> boundary.
>>>
>>>
>>> I (for one) still find many places where JavaConversions is perfectly
>>> safe and more appealing than JavaConverters. The respective Scaladoc does a
>>> good job as explaining the differences. So -1 to deprecation.
>>>
>>> -jason
>
>

--
Viktor Klang

Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts

Twitter: @viktorklang