compiler plugins in the wild

Re: Recommendations for papers on Scala type system needed

Re: Scala to Java Generics Problem?

It still seems to be having an issue with both the concrete type and no type
at all. I have a jar file with a test class and sources that show the
problem. It requires the easymock libraries which are not included but can
be retrieved from 
http://sourceforge.net/project/downloading.php?group_id=82958&filename=easymock-2.5.1.zip

Test Sources:  http://www.nabble.com/file/p25232663/sources.jar sources.jar 

nuttycom wrote:
> 
> Can you give your streams variable a concrete type? This error is
> occurring because the compiler is trying to identify one unknown type
> as another unknown type; I suspect that if you simply omitted the type
> declaration on the streams var and let inference handle this it would
> work.
> 
> Kris
> 
> On Mon, Aug 31, 2009 at 5:31 AM, abruzzo<java.peritus <at> gmail.com> wrote:
>>
>> Thanks for the suggestion. Unfortunately that doesn't seem to copile
>> either.
>>
>> found   : java.lang.Iterable[T forSome { type T <:
>> com.ccadllc.firebird.vms.topology.core.ElementaryStream }]
>> required: java.lang.Iterable[?0] where type ?0 <:
>> com.ccadllc.firebird.vms.topology.core.ElementaryStream
>> --
>> View this message in context:
>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25222039.html
>> Sent from the Scala mailing list archive at Nabble.com.
>>
>>
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25232663.html
Sent from the Scala mailing list archive at Nabble.com.

Re: Scala to Java Generics Problem?

Hi allac,

I investigated this and was able to reproduce the type error:

import org.scalatest.FunSuite
import org.scalatest.mock.EasyMockSugar
import org.easymock.EasyMock.{expect => expectCall, replay, verify, createMock}

class MySuite extends FunSuite {

  test("easymock issue") {

    trait TopologyModel extends GetElementaryStreamsMethod

    val mockTopologyModel = createMock(classOf[TopologyModel])

    var streams: java.lang.Iterable[_ <: ElementaryStream] = new
java.util.ArrayList()

    expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)

    replay(mockTopologyModel)
    val result = mockTopologyModel.getAllElementaryStreams
    assert(result === streams)
    verify(mockTopologyModel)
  }
}

/*
The Java files are:

// In ElementaryStream.java
public class ElementaryStream {}

// In GetElementaryStreamsMethod.java
public interface GetElementaryStreamsMethod {
    Iterable<? extends ElementaryStream> getAllElementaryStreams();
}
*/

If I used the full forSome form:

var streams: java.lang.Iterable[T] forSome { type T <:
ElementaryStream } = new java.util.ArrayList()

I'd get the same error message:

 found   : java.lang.Iterable[_$1] where type _$1 <: ElementaryStream
 required: java.lang.Iterable[?0] where type ?0 <: ElementaryStream
           expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
                                                                               ^

I can't find anything wrong with these types so it may be a compiler
bug. I can submit it if you haven't already.

I did find a workaround, though I don't know why this works when the
previous one does not. But I had added an EasyMockSugar trait to
ScalaTest 1.0 recently. Using that trait you get no compiler error.
(Actually the only thing you'd need to use is the mock method of trait
EasyMockSugar. You can just use that and nothing else from ScalaTest,
but you'd have to grab the snapshot as this only in 1.0). This
compiles and runs fine:

import org.scalatest.FunSuite
import org.scalatest.mock.EasyMockSugar

class MyOtherSuite extends FunSuite with EasyMockSugar {

  test("easymock issue") {

    trait TopologyModel extends GetElementaryStreamsMethod

    val mockTopologyModel = mock[TopologyModel]

    var streams: java.lang.Iterable[_ <: ElementaryStream] = new
java.util.ArrayList()

    expecting {
      call(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
    }

    whenExecuting(mockTopologyModel) {
      val result = mockTopologyModel.getAllElementaryStreams
      assert(result === streams)
    }
  }
}

Bill

On Sun, Aug 30, 2009 at 5:08 AM, alIac<java.peritus <at> gmail.com> wrote:
>
> I'm trying to add an easymock expectation for a java method defined as
> follows:
>
>        Iterable<? extends ElementaryStream> getAllElementaryStreams();
>
> The expectation is set up as follows:
>
>
>        var streams:java.lang.Iterable[_ <: ElementaryStream] =
> Lists.newArrayList()
>
> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>
>
> During compile I get the following:
>
> Error:Error:line (61)error: type mismatch;
> found   : java.lang.Iterable[_$1] where type _$1 <:
> com.foo.vms.topology.core.ElementaryStream
> required: java.lang.Iterable[?0] where type ?0 <:
> com.foo.vms.topology.core.ElementaryStream
> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>
> I can't seem to define the streams var correctly.
> --
> View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25211005.html
> Sent from the Scala mailing list archive at Nabble.com.
>
>

--

-- 
Bill Venners
Artima, Inc.
http://www.artima.com

Re: Scala to Java Generics Problem?

Thanks for the workaround. I'll try it out tomorrow morning. I've already
filed a bug report with sample code on ths. 

Bill Venners-3 wrote:
> 
> Hi allac,
> 
> I investigated this and was able to reproduce the type error:
> 
> import org.scalatest.FunSuite
> import org.scalatest.mock.EasyMockSugar
> import org.easymock.EasyMock.{expect => expectCall, replay, verify,
> createMock}
> 
> class MySuite extends FunSuite {
> 
>   test("easymock issue") {
> 
>     trait TopologyModel extends GetElementaryStreamsMethod
> 
>     val mockTopologyModel = createMock(classOf[TopologyModel])
> 
>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
> java.util.ArrayList()
> 
>    
> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
> 
>     replay(mockTopologyModel)
>     val result = mockTopologyModel.getAllElementaryStreams
>     assert(result === streams)
>     verify(mockTopologyModel)
>   }
> }
> 
> /*
> The Java files are:
> 
> // In ElementaryStream.java
> public class ElementaryStream {}
> 
> // In GetElementaryStreamsMethod.java
> public interface GetElementaryStreamsMethod {
>     Iterable<? extends ElementaryStream> getAllElementaryStreams();
> }
> */
> 
> If I used the full forSome form:
> 
> var streams: java.lang.Iterable[T] forSome { type T <:
> ElementaryStream } = new java.util.ArrayList()
> 
> I'd get the same error message:
> 
>  found   : java.lang.Iterable[_$1] where type _$1 <: ElementaryStream
>  required: java.lang.Iterable[?0] where type ?0 <: ElementaryStream
>           
> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>                                                                               
> ^
> 
> I can't find anything wrong with these types so it may be a compiler
> bug. I can submit it if you haven't already.
> 
> I did find a workaround, though I don't know why this works when the
> previous one does not. But I had added an EasyMockSugar trait to
> ScalaTest 1.0 recently. Using that trait you get no compiler error.
> (Actually the only thing you'd need to use is the mock method of trait
> EasyMockSugar. You can just use that and nothing else from ScalaTest,
> but you'd have to grab the snapshot as this only in 1.0). This
> compiles and runs fine:
> 
> import org.scalatest.FunSuite
> import org.scalatest.mock.EasyMockSugar
> 
> class MyOtherSuite extends FunSuite with EasyMockSugar {
> 
>   test("easymock issue") {
> 
>     trait TopologyModel extends GetElementaryStreamsMethod
> 
>     val mockTopologyModel = mock[TopologyModel]
> 
>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
> java.util.ArrayList()
> 
>     expecting {
>      
> call(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>     }
> 
>     whenExecuting(mockTopologyModel) {
>       val result = mockTopologyModel.getAllElementaryStreams
>       assert(result === streams)
>     }
>   }
> }
> 
> Bill
> 
> On Sun, Aug 30, 2009 at 5:08 AM, alIac<java.peritus <at> gmail.com> wrote:
>>
>> I'm trying to add an easymock expectation for a java method defined as
>> follows:
>>
>>        Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>
>> The expectation is set up as follows:
>>
>>
>>        var streams:java.lang.Iterable[_ <: ElementaryStream] =
>> Lists.newArrayList()
>>
>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>
>>
>> During compile I get the following:
>>
>> Error:Error:line (61)error: type mismatch;
>> found   : java.lang.Iterable[_$1] where type _$1 <:
>> com.foo.vms.topology.core.ElementaryStream
>> required: java.lang.Iterable[?0] where type ?0 <:
>> com.foo.vms.topology.core.ElementaryStream
>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>
>> I can't seem to define the streams var correctly.
>> --
>> View this message in context:
>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25211005.html
>> Sent from the Scala mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Bill Venners
> Artima, Inc.
> http://www.artima.com
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233168.html
Sent from the Scala mailing list archive at Nabble.com.

Re: Scala to Java Generics Problem?

Hi Bill,

I'm really interested in understanding why this works by using your EasyMock
trait. It is still calling EasyMock.expect right? If anyone else also has a
clue on this,...

Moreover, this issue already popped up in a different form, though when
trying to return java.util.Enumeration values (un-genericized ones, see my
previous post for a link). So I suspect that there is a potential issue
(bug?) with the Java-Scala integration.

Eric.

Bill Venners-3 wrote:
> 
> Hi allac,
> 
> I investigated this and was able to reproduce the type error:
> 
> import org.scalatest.FunSuite
> import org.scalatest.mock.EasyMockSugar
> import org.easymock.EasyMock.{expect => expectCall, replay, verify,
> createMock}
> 
> class MySuite extends FunSuite {
> 
>   test("easymock issue") {
> 
>     trait TopologyModel extends GetElementaryStreamsMethod
> 
>     val mockTopologyModel = createMock(classOf[TopologyModel])
> 
>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
> java.util.ArrayList()
> 
>    
> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
> 
>     replay(mockTopologyModel)
>     val result = mockTopologyModel.getAllElementaryStreams
>     assert(result === streams)
>     verify(mockTopologyModel)
>   }
> }
> 
> /*
> The Java files are:
> 
> // In ElementaryStream.java
> public class ElementaryStream {}
> 
> // In GetElementaryStreamsMethod.java
> public interface GetElementaryStreamsMethod {
>     Iterable<? extends ElementaryStream> getAllElementaryStreams();
> }
> */
> 
> If I used the full forSome form:
> 
> var streams: java.lang.Iterable[T] forSome { type T <:
> ElementaryStream } = new java.util.ArrayList()
> 
> I'd get the same error message:
> 
>  found   : java.lang.Iterable[_$1] where type _$1 <: ElementaryStream
>  required: java.lang.Iterable[?0] where type ?0 <: ElementaryStream
>           
> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>                                                                               
> ^
> 
> I can't find anything wrong with these types so it may be a compiler
> bug. I can submit it if you haven't already.
> 
> I did find a workaround, though I don't know why this works when the
> previous one does not. But I had added an EasyMockSugar trait to
> ScalaTest 1.0 recently. Using that trait you get no compiler error.
> (Actually the only thing you'd need to use is the mock method of trait
> EasyMockSugar. You can just use that and nothing else from ScalaTest,
> but you'd have to grab the snapshot as this only in 1.0). This
> compiles and runs fine:
> 
> import org.scalatest.FunSuite
> import org.scalatest.mock.EasyMockSugar
> 
> class MyOtherSuite extends FunSuite with EasyMockSugar {
> 
>   test("easymock issue") {
> 
>     trait TopologyModel extends GetElementaryStreamsMethod
> 
>     val mockTopologyModel = mock[TopologyModel]
> 
>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
> java.util.ArrayList()
> 
>     expecting {
>      
> call(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>     }
> 
>     whenExecuting(mockTopologyModel) {
>       val result = mockTopologyModel.getAllElementaryStreams
>       assert(result === streams)
>     }
>   }
> }
> 
> Bill
> 
> On Sun, Aug 30, 2009 at 5:08 AM, alIac<java.peritus <at> gmail.com> wrote:
>>
>> I'm trying to add an easymock expectation for a java method defined as
>> follows:
>>
>>        Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>
>> The expectation is set up as follows:
>>
>>
>>        var streams:java.lang.Iterable[_ <: ElementaryStream] =
>> Lists.newArrayList()
>>
>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>
>>
>> During compile I get the following:
>>
>> Error:Error:line (61)error: type mismatch;
>> found   : java.lang.Iterable[_$1] where type _$1 <:
>> com.foo.vms.topology.core.ElementaryStream
>> required: java.lang.Iterable[?0] where type ?0 <:
>> com.foo.vms.topology.core.ElementaryStream
>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>
>> I can't seem to define the streams var correctly.
>> --
>> View this message in context:
>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25211005.html
>> Sent from the Scala mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Bill Venners
> Artima, Inc.
> http://www.artima.com
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233413.html
Sent from the Scala mailing list archive at Nabble.com.

Re: Scala to Java Generics Problem?

Hi Eric,

On Mon, Aug 31, 2009 at 7:19 PM, Eric Torreborre<etorreborre <at> yahoo.com> wrote:
>
> Hi Bill,
>
> I'm really interested in understanding why this works by using your EasyMock
> trait. It is still calling EasyMock.expect right? If anyone else also has a
> clue on this,...
>
My theory is it is a compiler bug. So the bug shows up for some reason
in one case, but not the other.

That said, I'm old enough to remember five years that I spent
programming in C++. During those years there were about three
occasions in which I was absolutely completely convinced the C++
compiler had a bug. But it always turned out to be my bug. This was a
lesson in humility that I carried with me into my Java and now Scala
years. But given I came to Scala much earlier stage in the languages
evolution than I did to the earlier languages, I've actually stumbled
upon Scala compiler bugs turned out to *not* be my bug. Hard to say if
this is a real one or not, but I sure can't see anything wrong with
the code with my compiler-eye.

> Moreover, this issue already popped up in a different form, though when
> trying to return java.util.Enumeration values (un-genericized ones, see my
> previous post for a link). So I suspect that there is a potential issue
> (bug?) with the Java-Scala integration.
>
I looked at that and I think that's not a compiler bug:

http://groups.google.com/group/specs-users/browse_thread/thread/e97fd63c434dd59b

I think what you have there is an ungenerified Java library, which
appears in Scala as if it is parameterized with an existential type.

[error]  found   : java.lang.Object with java.util.Enumeration[String]{ ... }
[error]  required: java.util.Enumeration[?0] where type ?0
[error]       new java.util.Enumeration[String] {
[error]       ^

What's coming back from getHeaders as far as the Scala compiler is concerned is:

java.util.Enumeration[_]

Thus you have the problem of turning that into an Enumeration[String],
which you'll need to do with a cast as you suggested. If that sounds
unsafe to you, that's because it is, but it is because you need to
call into an ungenerified Java library. So you shouldn't feel guilty
about the cast. Even though it is unsafe, it's your only way back to
type safety. I think about the best thing Emil can do if he's doing
this cast repeatedly is factor the cast out into one place and call
that method multiple times instead of hard coding the cast in multiple
places.

Bill

> Eric.
>
>
> Bill Venners-3 wrote:
>>
>> Hi allac,
>>
>> I investigated this and was able to reproduce the type error:
>>
>> import org.scalatest.FunSuite
>> import org.scalatest.mock.EasyMockSugar
>> import org.easymock.EasyMock.{expect => expectCall, replay, verify,
>> createMock}
>>
>> class MySuite extends FunSuite {
>>
>>   test("easymock issue") {
>>
>>     trait TopologyModel extends GetElementaryStreamsMethod
>>
>>     val mockTopologyModel = createMock(classOf[TopologyModel])
>>
>>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
>> java.util.ArrayList()
>>
>>
>> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>
>>     replay(mockTopologyModel)
>>     val result = mockTopologyModel.getAllElementaryStreams
>>     assert(result === streams)
>>     verify(mockTopologyModel)
>>   }
>> }
>>
>> /*
>> The Java files are:
>>
>> // In ElementaryStream.java
>> public class ElementaryStream {}
>>
>> // In GetElementaryStreamsMethod.java
>> public interface GetElementaryStreamsMethod {
>>     Iterable<? extends ElementaryStream> getAllElementaryStreams();
>> }
>> */
>>
>> If I used the full forSome form:
>>
>> var streams: java.lang.Iterable[T] forSome { type T <:
>> ElementaryStream } = new java.util.ArrayList()
>>
>> I'd get the same error message:
>>
>>  found   : java.lang.Iterable[_$1] where type _$1 <: ElementaryStream
>>  required: java.lang.Iterable[?0] where type ?0 <: ElementaryStream
>>
>> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>
>> ^
>>
>> I can't find anything wrong with these types so it may be a compiler
>> bug. I can submit it if you haven't already.
>>
>> I did find a workaround, though I don't know why this works when the
>> previous one does not. But I had added an EasyMockSugar trait to
>> ScalaTest 1.0 recently. Using that trait you get no compiler error.
>> (Actually the only thing you'd need to use is the mock method of trait
>> EasyMockSugar. You can just use that and nothing else from ScalaTest,
>> but you'd have to grab the snapshot as this only in 1.0). This
>> compiles and runs fine:
>>
>> import org.scalatest.FunSuite
>> import org.scalatest.mock.EasyMockSugar
>>
>> class MyOtherSuite extends FunSuite with EasyMockSugar {
>>
>>   test("easymock issue") {
>>
>>     trait TopologyModel extends GetElementaryStreamsMethod
>>
>>     val mockTopologyModel = mock[TopologyModel]
>>
>>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
>> java.util.ArrayList()
>>
>>     expecting {
>>
>> call(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>     }
>>
>>     whenExecuting(mockTopologyModel) {
>>       val result = mockTopologyModel.getAllElementaryStreams
>>       assert(result === streams)
>>     }
>>   }
>> }
>>
>> Bill
>>
>> On Sun, Aug 30, 2009 at 5:08 AM, alIac<java.peritus <at> gmail.com> wrote:
>>>
>>> I'm trying to add an easymock expectation for a java method defined as
>>> follows:
>>>
>>>        Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>>
>>> The expectation is set up as follows:
>>>
>>>
>>>        var streams:java.lang.Iterable[_ <: ElementaryStream] =
>>> Lists.newArrayList()
>>>
>>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>
>>>
>>> During compile I get the following:
>>>
>>> Error:Error:line (61)error: type mismatch;
>>> found   : java.lang.Iterable[_$1] where type _$1 <:
>>> com.foo.vms.topology.core.ElementaryStream
>>> required: java.lang.Iterable[?0] where type ?0 <:
>>> com.foo.vms.topology.core.ElementaryStream
>>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>
>>> I can't seem to define the streams var correctly.
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25211005.html
>>> Sent from the Scala mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Bill Venners
>> Artima, Inc.
>> http://www.artima.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233413.html
> Sent from the Scala mailing list archive at Nabble.com.
>
>

--

-- 
Bill Venners
Artima, Inc.
http://www.artima.com

Re: Scala to Java Generics Problem?

> Thus you have the problem of turning that into an Enumeration[String],
which you'll need to do with a cast as you suggested. If that sounds
unsafe to you, that's because it is, but it is because you need to
call into an ungenerified Java library.

Actually, if we do this (using specs and Mockito):

object test extends org.specs.Specification with org.specs.mock.Mockito {
   val raw = mock[HttpServletRequest]
   val enum: java.util.Enumeration[_] = new java.util.Enumeration[String] { 
       val headers = Array("en-us", "bg;q=0.9") 
       private var current = 0 
       def nextElement: String = { 
         headers(current) 
       } 
       def hasMoreElements: Boolean = { 
         current < headers.length - 1 
       }} 

   raw.getHeaderNames() returns enum // error here

}

We get the same type of compilation error:

type mismatch;
 found   : java.util.Enumeration[_$1] where type _$1
 required: java.util.Enumeration[?0] where type ?0

I've been seeing this several times when dealing with pre-java 1.5 code and
found very annoying to be unable to declare in Scala a type which would be
equivalent to an ungenericized Java type. But I may be wrong and missing
something there also.

E.

Bill Venners-3 wrote:
> 
> Hi Eric,
> 
> On Mon, Aug 31, 2009 at 7:19 PM, Eric Torreborre<etorreborre <at> yahoo.com>
> wrote:
>>
>> Hi Bill,
>>
>> I'm really interested in understanding why this works by using your
>> EasyMock
>> trait. It is still calling EasyMock.expect right? If anyone else also has
>> a
>> clue on this,...
>>
> My theory is it is a compiler bug. So the bug shows up for some reason
> in one case, but not the other.
> 
> That said, I'm old enough to remember five years that I spent
> programming in C++. During those years there were about three
> occasions in which I was absolutely completely convinced the C++
> compiler had a bug. But it always turned out to be my bug. This was a
> lesson in humility that I carried with me into my Java and now Scala
> years. But given I came to Scala much earlier stage in the languages
> evolution than I did to the earlier languages, I've actually stumbled
> upon Scala compiler bugs turned out to *not* be my bug. Hard to say if
> this is a real one or not, but I sure can't see anything wrong with
> the code with my compiler-eye.
> 
>> Moreover, this issue already popped up in a different form, though when
>> trying to return java.util.Enumeration values (un-genericized ones, see
>> my
>> previous post for a link). So I suspect that there is a potential issue
>> (bug?) with the Java-Scala integration.
>>
> I looked at that and I think that's not a compiler bug:
> 
> http://groups.google.com/group/specs-users/browse_thread/thread/e97fd63c434dd59b
> 
> I think what you have there is an ungenerified Java library, which
> appears in Scala as if it is parameterized with an existential type.
> 
> [error]  found   : java.lang.Object with java.util.Enumeration[String]{
> ... }
> [error]  required: java.util.Enumeration[?0] where type ?0
> [error]       new java.util.Enumeration[String] {
> [error]       ^
> 
> What's coming back from getHeaders as far as the Scala compiler is
> concerned is:
> 
> java.util.Enumeration[_]
> 
> Thus you have the problem of turning that into an Enumeration[String],
> which you'll need to do with a cast as you suggested. If that sounds
> unsafe to you, that's because it is, but it is because you need to
> call into an ungenerified Java library. So you shouldn't feel guilty
> about the cast. Even though it is unsafe, it's your only way back to
> type safety. I think about the best thing Emil can do if he's doing
> this cast repeatedly is factor the cast out into one place and call
> that method multiple times instead of hard coding the cast in multiple
> places.
> 
> Bill
> 
>> Eric.
>>
>>
>> Bill Venners-3 wrote:
>>>
>>> Hi allac,
>>>
>>> I investigated this and was able to reproduce the type error:
>>>
>>> import org.scalatest.FunSuite
>>> import org.scalatest.mock.EasyMockSugar
>>> import org.easymock.EasyMock.{expect => expectCall, replay, verify,
>>> createMock}
>>>
>>> class MySuite extends FunSuite {
>>>
>>>   test("easymock issue") {
>>>
>>>     trait TopologyModel extends GetElementaryStreamsMethod
>>>
>>>     val mockTopologyModel = createMock(classOf[TopologyModel])
>>>
>>>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
>>> java.util.ArrayList()
>>>
>>>
>>> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>
>>>     replay(mockTopologyModel)
>>>     val result = mockTopologyModel.getAllElementaryStreams
>>>     assert(result === streams)
>>>     verify(mockTopologyModel)
>>>   }
>>> }
>>>
>>> /*
>>> The Java files are:
>>>
>>> // In ElementaryStream.java
>>> public class ElementaryStream {}
>>>
>>> // In GetElementaryStreamsMethod.java
>>> public interface GetElementaryStreamsMethod {
>>>     Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>> }
>>> */
>>>
>>> If I used the full forSome form:
>>>
>>> var streams: java.lang.Iterable[T] forSome { type T <:
>>> ElementaryStream } = new java.util.ArrayList()
>>>
>>> I'd get the same error message:
>>>
>>>  found   : java.lang.Iterable[_$1] where type _$1 <: ElementaryStream
>>>  required: java.lang.Iterable[?0] where type ?0 <: ElementaryStream
>>>
>>> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>
>>> ^
>>>
>>> I can't find anything wrong with these types so it may be a compiler
>>> bug. I can submit it if you haven't already.
>>>
>>> I did find a workaround, though I don't know why this works when the
>>> previous one does not. But I had added an EasyMockSugar trait to
>>> ScalaTest 1.0 recently. Using that trait you get no compiler error.
>>> (Actually the only thing you'd need to use is the mock method of trait
>>> EasyMockSugar. You can just use that and nothing else from ScalaTest,
>>> but you'd have to grab the snapshot as this only in 1.0). This
>>> compiles and runs fine:
>>>
>>> import org.scalatest.FunSuite
>>> import org.scalatest.mock.EasyMockSugar
>>>
>>> class MyOtherSuite extends FunSuite with EasyMockSugar {
>>>
>>>   test("easymock issue") {
>>>
>>>     trait TopologyModel extends GetElementaryStreamsMethod
>>>
>>>     val mockTopologyModel = mock[TopologyModel]
>>>
>>>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
>>> java.util.ArrayList()
>>>
>>>     expecting {
>>>
>>> call(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>     }
>>>
>>>     whenExecuting(mockTopologyModel) {
>>>       val result = mockTopologyModel.getAllElementaryStreams
>>>       assert(result === streams)
>>>     }
>>>   }
>>> }
>>>
>>> Bill
>>>
>>> On Sun, Aug 30, 2009 at 5:08 AM, alIac<java.peritus <at> gmail.com> wrote:
>>>>
>>>> I'm trying to add an easymock expectation for a java method defined as
>>>> follows:
>>>>
>>>>        Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>>>
>>>> The expectation is set up as follows:
>>>>
>>>>
>>>>        var streams:java.lang.Iterable[_ <: ElementaryStream] =
>>>> Lists.newArrayList()
>>>>
>>>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>
>>>>
>>>> During compile I get the following:
>>>>
>>>> Error:Error:line (61)error: type mismatch;
>>>> found   : java.lang.Iterable[_$1] where type _$1 <:
>>>> com.foo.vms.topology.core.ElementaryStream
>>>> required: java.lang.Iterable[?0] where type ?0 <:
>>>> com.foo.vms.topology.core.ElementaryStream
>>>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>
>>>> I can't seem to define the streams var correctly.
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25211005.html
>>>> Sent from the Scala mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Bill Venners
>>> Artima, Inc.
>>> http://www.artima.com
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233413.html
>> Sent from the Scala mailing list archive at Nabble.com.
>>
>>
> 
> 
> 
> -- 
> Bill Venners
> Artima, Inc.
> http://www.artima.com
> 
> 

--

-- 
View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233872.html
Sent from the Scala mailing list archive at Nabble.com.

Re: Scala to Java Generics Problem?

Hi Eric,

I think this problem is different from the problem Emil Ivanov posted
about, but it looks a lot like the potential compiler bug that allac
was seeing. Because you've declared the type of enum to be
Enumeration[_], which should be the return type of getHeaderNames as
seen from Scala. But getHeaderNames' return type is a Java raw type,
and for some reason you're getting this weird compiler error message.
I'll wrap up the little code example I made up and submit a bug
report.

Bill

On Mon, Aug 31, 2009 at 8:41 PM, Eric Torreborre<etorreborre <at> yahoo.com> wrote:
>
>> Thus you have the problem of turning that into an Enumeration[String],
> which you'll need to do with a cast as you suggested. If that sounds
> unsafe to you, that's because it is, but it is because you need to
> call into an ungenerified Java library.
>
> Actually, if we do this (using specs and Mockito):
>
> object test extends org.specs.Specification with org.specs.mock.Mockito {
>   val raw = mock[HttpServletRequest]
>   val enum: java.util.Enumeration[_] = new java.util.Enumeration[String] {
>       val headers = Array("en-us", "bg;q=0.9")
>       private var current = 0
>       def nextElement: String = {
>         headers(current)
>       }
>       def hasMoreElements: Boolean = {
>         current < headers.length - 1
>       }}
>
>   raw.getHeaderNames() returns enum // error here
>
> }
>
> We get the same type of compilation error:
>
> type mismatch;
>  found   : java.util.Enumeration[_$1] where type _$1
>  required: java.util.Enumeration[?0] where type ?0
>
> I've been seeing this several times when dealing with pre-java 1.5 code and
> found very annoying to be unable to declare in Scala a type which would be
> equivalent to an ungenericized Java type. But I may be wrong and missing
> something there also.
>
> E.
>
>
> Bill Venners-3 wrote:
>>
>> Hi Eric,
>>
>> On Mon, Aug 31, 2009 at 7:19 PM, Eric Torreborre<etorreborre <at> yahoo.com>
>> wrote:
>>>
>>> Hi Bill,
>>>
>>> I'm really interested in understanding why this works by using your
>>> EasyMock
>>> trait. It is still calling EasyMock.expect right? If anyone else also has
>>> a
>>> clue on this,...
>>>
>> My theory is it is a compiler bug. So the bug shows up for some reason
>> in one case, but not the other.
>>
>> That said, I'm old enough to remember five years that I spent
>> programming in C++. During those years there were about three
>> occasions in which I was absolutely completely convinced the C++
>> compiler had a bug. But it always turned out to be my bug. This was a
>> lesson in humility that I carried with me into my Java and now Scala
>> years. But given I came to Scala much earlier stage in the languages
>> evolution than I did to the earlier languages, I've actually stumbled
>> upon Scala compiler bugs turned out to *not* be my bug. Hard to say if
>> this is a real one or not, but I sure can't see anything wrong with
>> the code with my compiler-eye.
>>
>>> Moreover, this issue already popped up in a different form, though when
>>> trying to return java.util.Enumeration values (un-genericized ones, see
>>> my
>>> previous post for a link). So I suspect that there is a potential issue
>>> (bug?) with the Java-Scala integration.
>>>
>> I looked at that and I think that's not a compiler bug:
>>
>> http://groups.google.com/group/specs-users/browse_thread/thread/e97fd63c434dd59b
>>
>> I think what you have there is an ungenerified Java library, which
>> appears in Scala as if it is parameterized with an existential type.
>>
>> [error]  found   : java.lang.Object with java.util.Enumeration[String]{
>> ... }
>> [error]  required: java.util.Enumeration[?0] where type ?0
>> [error]       new java.util.Enumeration[String] {
>> [error]       ^
>>
>> What's coming back from getHeaders as far as the Scala compiler is
>> concerned is:
>>
>> java.util.Enumeration[_]
>>
>> Thus you have the problem of turning that into an Enumeration[String],
>> which you'll need to do with a cast as you suggested. If that sounds
>> unsafe to you, that's because it is, but it is because you need to
>> call into an ungenerified Java library. So you shouldn't feel guilty
>> about the cast. Even though it is unsafe, it's your only way back to
>> type safety. I think about the best thing Emil can do if he's doing
>> this cast repeatedly is factor the cast out into one place and call
>> that method multiple times instead of hard coding the cast in multiple
>> places.
>>
>> Bill
>>
>>> Eric.
>>>
>>>
>>> Bill Venners-3 wrote:
>>>>
>>>> Hi allac,
>>>>
>>>> I investigated this and was able to reproduce the type error:
>>>>
>>>> import org.scalatest.FunSuite
>>>> import org.scalatest.mock.EasyMockSugar
>>>> import org.easymock.EasyMock.{expect => expectCall, replay, verify,
>>>> createMock}
>>>>
>>>> class MySuite extends FunSuite {
>>>>
>>>>   test("easymock issue") {
>>>>
>>>>     trait TopologyModel extends GetElementaryStreamsMethod
>>>>
>>>>     val mockTopologyModel = createMock(classOf[TopologyModel])
>>>>
>>>>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
>>>> java.util.ArrayList()
>>>>
>>>>
>>>> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>
>>>>     replay(mockTopologyModel)
>>>>     val result = mockTopologyModel.getAllElementaryStreams
>>>>     assert(result === streams)
>>>>     verify(mockTopologyModel)
>>>>   }
>>>> }
>>>>
>>>> /*
>>>> The Java files are:
>>>>
>>>> // In ElementaryStream.java
>>>> public class ElementaryStream {}
>>>>
>>>> // In GetElementaryStreamsMethod.java
>>>> public interface GetElementaryStreamsMethod {
>>>>     Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>>> }
>>>> */
>>>>
>>>> If I used the full forSome form:
>>>>
>>>> var streams: java.lang.Iterable[T] forSome { type T <:
>>>> ElementaryStream } = new java.util.ArrayList()
>>>>
>>>> I'd get the same error message:
>>>>
>>>>  found   : java.lang.Iterable[_$1] where type _$1 <: ElementaryStream
>>>>  required: java.lang.Iterable[?0] where type ?0 <: ElementaryStream
>>>>
>>>> expectCall(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>
>>>> ^
>>>>
>>>> I can't find anything wrong with these types so it may be a compiler
>>>> bug. I can submit it if you haven't already.
>>>>
>>>> I did find a workaround, though I don't know why this works when the
>>>> previous one does not. But I had added an EasyMockSugar trait to
>>>> ScalaTest 1.0 recently. Using that trait you get no compiler error.
>>>> (Actually the only thing you'd need to use is the mock method of trait
>>>> EasyMockSugar. You can just use that and nothing else from ScalaTest,
>>>> but you'd have to grab the snapshot as this only in 1.0). This
>>>> compiles and runs fine:
>>>>
>>>> import org.scalatest.FunSuite
>>>> import org.scalatest.mock.EasyMockSugar
>>>>
>>>> class MyOtherSuite extends FunSuite with EasyMockSugar {
>>>>
>>>>   test("easymock issue") {
>>>>
>>>>     trait TopologyModel extends GetElementaryStreamsMethod
>>>>
>>>>     val mockTopologyModel = mock[TopologyModel]
>>>>
>>>>     var streams: java.lang.Iterable[_ <: ElementaryStream] = new
>>>> java.util.ArrayList()
>>>>
>>>>     expecting {
>>>>
>>>> call(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>     }
>>>>
>>>>     whenExecuting(mockTopologyModel) {
>>>>       val result = mockTopologyModel.getAllElementaryStreams
>>>>       assert(result === streams)
>>>>     }
>>>>   }
>>>> }
>>>>
>>>> Bill
>>>>
>>>> On Sun, Aug 30, 2009 at 5:08 AM, alIac<java.peritus <at> gmail.com> wrote:
>>>>>
>>>>> I'm trying to add an easymock expectation for a java method defined as
>>>>> follows:
>>>>>
>>>>>        Iterable<? extends ElementaryStream> getAllElementaryStreams();
>>>>>
>>>>> The expectation is set up as follows:
>>>>>
>>>>>
>>>>>        var streams:java.lang.Iterable[_ <: ElementaryStream] =
>>>>> Lists.newArrayList()
>>>>>
>>>>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>>
>>>>>
>>>>> During compile I get the following:
>>>>>
>>>>> Error:Error:line (61)error: type mismatch;
>>>>> found   : java.lang.Iterable[_$1] where type _$1 <:
>>>>> com.foo.vms.topology.core.ElementaryStream
>>>>> required: java.lang.Iterable[?0] where type ?0 <:
>>>>> com.foo.vms.topology.core.ElementaryStream
>>>>> expect(mockTopologyModel.getAllElementaryStreams).andStubReturn(streams)
>>>>>
>>>>> I can't seem to define the streams var correctly.
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25211005.html
>>>>> Sent from the Scala mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bill Venners
>>>> Artima, Inc.
>>>> http://www.artima.com
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233413.html
>>> Sent from the Scala mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Bill Venners
>> Artima, Inc.
>> http://www.artima.com
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Scala-to-Java-Generics-Problem--tp25211005p25233872.html
> Sent from the Scala mailing list archive at Nabble.com.
>
>

--

-- 
Bill Venners
Artima, Inc.
http://www.artima.com

Re: Parent class of a trait

Hi again,

I've tried to track down exactly where this information about the
actual base class "gets lost". It seems to happen during the 'erasure'
phase. Can you confirm this?

And if so, is there a way to skip this phase? I've tried, and
apparently the 'constructors' phase depends on it (i.e. it throws an
exception if I just comment out the 'erasure' phase). Do other phases,
such as lazyVals, lambdaLift, flatten, mixer or cleanup, depend on the
'erasure' phase as well?

Cheers

Valentin

On Mon, Aug 24, 2009 at 9:58 PM, Valentin Wüstholz<wuestholz <at> gmail.com> wrote:
> Thanks! My example input is this:
>
>> trait T
>> class C
>> trait U extends C
>
> Now when I process the AST (just before code generation) for trait U,
> I would like to know what the base class of U is (C in this case). But
> the 'parents' field in the AST contains the base class of the base
> class (Object in this case), as you explained earlier. I don't
> understand why you don't store the base class and all mixed in traits
> in the parents field instead. Or is there another way to extract the
> fact that U extends C from the AST? That would be fine for me.
>
> Was that more understandable?
>
> Cheers
>
> Valentin
>
> On Mon, Aug 24, 2009 at 6:19 PM, martin odersky<martin.odersky <at> epfl.ch> wrote:
>> On Mon, Aug 24, 2009 at 2:47 PM, Valentin Wüstholz<wuestholz <at> gmail.com> wrote:
>>> Thanks for the clarification! That was also what I suspected.
>>>
>>> But I don't quite understand why you store the superclass of the
>>> actual base class. Don't you lose some information that way? Or is
>>> this just something you don't need in your code generator?
>>
>> I am not sure I understand. What's your input and AST exactly?
>>
>>  -- martin
>>
>