2.8 collection support for java.util.concurrent.ConcurrentMap

Hi Blair,

Do you mean a port of java.util.concurrent.* collections to Scala, or Scala wrappers around j.u.c.* collections?

--j

On Tue, Jun 9, 2009 at 5:22 PM, Blair Zajac <blair@orcaware.com> wrote:

I just took a look at trunk and didn't see any support for java.util.concurrent.ConcurrentMap and ConcurrentHashMap.  Is there a plan to have it 2.8?

We didn't have it in 2.7 and earlier since we supported JDK 1.4 which didn't include that, but since 2.8 requires JDK 1.5, we can depend upon these classes being present.

Also, if there's any committers reading this, the ScalaDoc in is incorrect:

http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/collection/JavaConversions.scala

This line

   import scala.collections.jcl.Conversions._

should be replaced with

   import scala.collections.JavaConversions._

Regards,
Blair

Hi Jorge,

Scala wrappers around the j.u.c.* collections.

The concurrent Google Collections Library which we're starting to use
also implement the interfaces in j.u.c.* so a wrapper around them
would be nice to have.

http://code.google.com/p/google-collections/

Regards,
Blair

On Jun 9, 2009, at 7:49 PM, Jorge Ortiz wrote:

> Hi Blair,
>
> Do you mean a port of java.util.concurrent.* collections to Scala,
> or Scala wrappers around j.u.c.* collections?
>
> --j
>
> On Tue, Jun 9, 2009 at 5:22 PM, Blair Zajac
> wrote:
> I just took a look at trunk and didn't see any support for
> java.util.concurrent.ConcurrentMap and ConcurrentHashMap. Is there
> a plan to have it 2.8?
>
> We didn't have it in 2.7 and earlier since we supported JDK 1.4
> which didn't include that, but since 2.8 requires JDK 1.5, we can
> depend upon these classes being present.
>
> Also, if there's any committers reading this, the ScalaDoc in is
> incorrect:
>
> http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/col...
>
> This line
>
> import scala.collections.jcl.Conversions._
>
> should be replaced with
>
> import scala.collections.JavaConversions._
>
> Regards,
> Blair
>

I'd be willing to put in work for this, but I don't know if pure Java wrappers would be appropriate for inclusion in the standard library. (You know, that pesky nominal compatibility with .Net thing.) Perhaps in a non-standard library?

--j

On Tue, Jun 9, 2009 at 11:12 PM, Blair Zajac <blair@orcaware.com> wrote:

Hi Jorge,

Scala wrappers around the j.u.c.* collections.

The concurrent Google Collections Library which we're starting to use also implement the interfaces in j.u.c.* so a wrapper around them would be nice to have.

http://code.google.com/p/google-collections/

Regards,
Blair

On Jun 9, 2009, at 7:49 PM, Jorge Ortiz wrote:

Hi Blair,

Do you mean a port of java.util.concurrent.* collections to Scala, or Scala wrappers around j.u.c.* collections?

--j

On Tue, Jun 9, 2009 at 5:22 PM, Blair Zajac <blair@orcaware.com> wrote:
I just took a look at trunk and didn't see any support for java.util.concurrent.ConcurrentMap and ConcurrentHashMap.  Is there a plan to have it 2.8?

We didn't have it in 2.7 and earlier since we supported JDK 1.4 which didn't include that, but since 2.8 requires JDK 1.5, we can depend upon these classes being present.

Also, if there's any committers reading this, the ScalaDoc in is incorrect:

http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/library/scala/collection/JavaConversions.scala

This line

  import scala.collections.jcl.Conversions._

should be replaced with

  import scala.collections.JavaConversions._

Regards,
Blair

On Wed, Jun 10, 2009 at 8:45 AM, Jorge Ortiz wrote:
> I'd be willing to put in work for this, but I don't know if pure Java
> wrappers would be appropriate for inclusion in the standard library. (You
> know, that pesky nominal compatibility with .Net thing.) Perhaps in a
> non-standard library?
>
We'll compromise there. We already have
scala.collection.JavaConversions. I think it would be OK to augment
that with further wrappers, or to have another conversion object side
by side.

Cheers

This brings up a question I had - I've been using Jorge's javautils
for conversions to good effect, and I was wondering if it's even
appropriate to have the Java conversions in the base library? It seems
like classes that exist purely for interaction with external libraries
should perhaps be separate.

Kris

On Wed, Jun 10, 2009 at 2:30 AM, martin odersky wrote:
> On Wed, Jun 10, 2009 at 8:45 AM, Jorge Ortiz wrote:
>> I'd be willing to put in work for this, but I don't know if pure Java
>> wrappers would be appropriate for inclusion in the standard library. (You
>> know, that pesky nominal compatibility with .Net thing.) Perhaps in a
>> non-standard library?
>>
> We'll compromise there. We already have
> scala.collection.JavaConversions. I think it would be OK to augment
> that with further wrappers, or to have another conversion object side
> by side.
>
> Cheers
>
>  -- Martin
>

Miles Sabin wrote some conversions along the same lines as javautils
that are going into 2.8.

--j

On Wednesday, June 10, 2009, Kris Nuttycombe wrote:
> This brings up a question I had - I've been using Jorge's javautils
> for conversions to good effect, and I was wondering if it's even
> appropriate to have the Java conversions in the base library? It seems
> like classes that exist purely for interaction with external libraries
> should perhaps be separate.
>
> Kris
>
> On Wed, Jun 10, 2009 at 2:30 AM, martin odersky wrote:
>> On Wed, Jun 10, 2009 at 8:45 AM, Jorge Ortiz wrote:
>>> I'd be willing to put in work for this, but I don't know if pure Java
>>> wrappers would be appropriate for inclusion in the standard library. (You
>>> know, that pesky nominal compatibility with .Net thing.) Perhaps in a
>>> non-standard library?
>>>
>> We'll compromise there. We already have
>> scala.collection.JavaConversions. I think it would be OK to augment
>> that with further wrappers, or to have another conversion object side
>> by side.
>>
>> Cheers
>>
>>  -- Martin
>>
>