there’s a bug somewhere: pointing finger got lost

99 views
Skip to first unread message

Roland Kuhn

unread,
Jun 27, 2012, 5:40:50 AM6/27/12
to scala-i...@googlegroups.com
Hi folks,

I’m not sure whose bug this is, but as I’m only seeing it in Eclipse I’ll start here. Bottom line: I cannot define a varargs method from Scala so that it is really usable from Java within Eclipse. Works fine with cmdline javac, though.

=============
rk:test rkuhn$ cat varargs.scala 
package varargs

class A {
  @scala.annotation.varargs
  def f(x: AnyRef*) = 42
}
rk:test rkuhn$ scalac varargs.scala 
=============
rk:test rkuhn$ cat Varargs.java 
package varargs;

class Varargs {

  public void test() {
    A a = new A();
    System.out.println(a.f("hello", 42));
  }

}
rk:test rkuhn$ javac -classpath $SCALALIB:. Varargs.java 
rk:test rkuhn$ java -jar /Users/rkuhn/eclipse/plugins/org.eclipse.jdt.core_3.7.3.v20120119-1537.jar -classpath $SCALALIB:. Varargs.java
----------
1. ERROR in Varargs.java (at line 7)
System.out.println(a.f("hello", 42));
                    ^
The method f(Object[]) in the type A is not applicable for the arguments (String, int)
----------
1 problem (1 error)rk:test rkuhn$ 
=============
rk:test rkuhn$ greadlink -f $SCALALIB 
/Users/rkuhn/comp/scala/dists/scala-2.9.3-20120621-003020-0132464e70/lib/scala-library.jar
rk:test rkuhn$ java -version
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
=============
rk:test rkuhn$ javap -v -p -c -l varargs.A
Classfile /Users/rkuhn/comp/scala/test/varargs/A.class
  Last modified 2012-jun-27; size 1122 bytes
  MD5 checksum 9c5e88b523ead1707bbb3e741f008209
  Compiled from "varargs.scala"
public class varargs.A implements scala.ScalaObject
  SourceFile: "varargs.scala"
    ScalaSig: length = 0x3
     05 00 00 
  RuntimeVisibleAnnotations:
    0: #37(#38=s#39)
  minor version: 0
  major version: 49
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Utf8               SourceFile
   #2 = Utf8               varargs.scala
   #3 = Utf8               f
   #4 = Utf8               ([Ljava/lang/Object;)I
   #5 = Utf8               Code
   #6 = Utf8               LineNumberTable
   #7 = Utf8               scala/Predef$
   #8 = Class              #7             //  scala/Predef$
   #9 = Utf8               MODULE$
  #10 = Utf8               Lscala/Predef$;
  #11 = NameAndType        #9:#10         //  MODULE$:Lscala/Predef$;
  #12 = Fieldref           #8.#11         //  scala/Predef$.MODULE$:Lscala/Predef$;
  #13 = Utf8               wrapRefArray
  #14 = Utf8               ([Ljava/lang/Object;)Lscala/collection/mutable/WrappedArray;
  #15 = NameAndType        #13:#14        //  wrapRefArray:([Ljava/lang/Object;)Lscala/collection/mutable/WrappedArray;
  #16 = Methodref          #8.#15         //  scala/Predef$.wrapRefArray:([Ljava/lang/Object;)Lscala/collection/mutable/WrappedArray;
  #17 = Utf8               varargs/A
  #18 = Class              #17            //  varargs/A
  #19 = Utf8               (Lscala/collection/Seq;)I
  #20 = NameAndType        #3:#19         //  f:(Lscala/collection/Seq;)I
  #21 = Methodref          #18.#20        //  varargs/A.f:(Lscala/collection/Seq;)I
  #22 = Utf8               this
  #23 = Utf8               Lvarargs/A;
  #24 = Utf8               x
  #25 = Utf8               [Ljava/lang/Object;
  #26 = Utf8               LocalVariableTable
  #27 = Utf8               Lscala/collection/Seq;
  #28 = Utf8               (Lscala/collection/Seq<Ljava/lang/Object;>;)I
  #29 = Utf8               Signature
  #30 = Utf8               <init>
  #31 = Utf8               ()V
  #32 = Utf8               java/lang/Object
  #33 = Class              #32            //  java/lang/Object
  #34 = NameAndType        #30:#31        //  "<init>":()V
  #35 = Methodref          #33.#34        //  java/lang/Object."<init>":()V
  #36 = Utf8               ScalaSig
  #37 = Utf8               Lscala/reflect/ScalaSignature;
  #38 = Utf8               bytes
  #39 = Utf8               [[ SNIP ]]
  #40 = Utf8               RuntimeVisibleAnnotations
  #41 = Utf8               scala/ScalaObject
  #42 = Class              #41            //  scala/ScalaObject
{
  public int f(java.lang.Object...);
    flags: ACC_PUBLIC, ACC_VARARGS
    LineNumberTable:
      line 5: 0
    LocalVariableTable:
      Start  Length  Slot  Name   Signature
             0      12     0  this   Lvarargs/A;
             0      12     1     x   [Ljava/lang/Object;
    Code:
      stack=3, locals=2, args_size=2
         0: aload_0       
         1: getstatic     #12                 // Field scala/Predef$.MODULE$:Lscala/Predef$;
         4: aload_1       
         5: invokevirtual #16                 // Method scala/Predef$.wrapRefArray:([Ljava/lang/Object;)Lscala/collection/mutable/WrappedArray;
         8: invokevirtual #21                 // Method f:(Lscala/collection/Seq;)I
        11: ireturn       
      LineNumberTable:
        line 5: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
               0      12     0  this   Lvarargs/A;
               0      12     1     x   [Ljava/lang/Object;

  public int f(scala.collection.Seq<java.lang.Object>);
    flags: ACC_PUBLIC
    LineNumberTable:
      line 5: 0
    LocalVariableTable:
      Start  Length  Slot  Name   Signature
             0       3     0  this   Lvarargs/A;
             0       3     1     x   Lscala/collection/Seq;
    Code:
      stack=1, locals=2, args_size=2
         0: bipush        42
         2: ireturn       
      LineNumberTable:
        line 5: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
               0       3     0  this   Lvarargs/A;
               0       3     1     x   Lscala/collection/Seq;
    Signature: #28                          // (Lscala/collection/Seq<Ljava/lang/Object;>;)I

  public varargs.A();
    flags: ACC_PUBLIC
    LineNumberTable:
      line 3: 0
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0       
         1: invokespecial #35                 // Method java/lang/Object."<init>":()V
         4: return        
      LineNumberTable:
        line 3: 0
}


Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn


iulian dragos

unread,
Jun 27, 2012, 8:20:24 AM6/27/12
to scala-i...@googlegroups.com
On Wed, Jun 27, 2012 at 11:40 AM, Roland Kuhn <goo...@rkuhn.info> wrote:
Hi folks,

I’m not sure whose bug this is, but as I’m only seeing it in Eclipse I’ll start here. Bottom line: I cannot define a varargs method from Scala so that it is really usable from Java within Eclipse. Works fine with cmdline javac, though.

It works for me when I pass -source 1.5 or above to the Eclipse Java compiler:

$ java -jar /Applications/Programming/eclipse-indigo/plugins/org.eclipse.jdt.core_3.7.3.v20120119-1537.jar -source 1.7 -cp classes/:/Users/dragos/workspace/git/scala/build/quick/classes/library/ Varargs.java 
$ java -jar /Applications/Programming/eclipse-indigo/plugins/org.eclipse.jdt.core_3.7.3.v20120119-1537.jar -source 1.6 -cp classes/:/Users/dragos/workspace/git/scala/build/quick/classes/library/ Varargs.java 
$ java -jar /Applications/Programming/eclipse-indigo/plugins/org.eclipse.jdt.core_3.7.3.v20120119-1537.jar -source 1.5 -cp classes/:/Users/dragos/workspace/git/scala/build/quick/classes/library/ Varargs.java 
$ java -jar /Applications/Programming/eclipse-indigo/plugins/org.eclipse.jdt.core_3.7.3.v20120119-1537.jar -source 1.4 -cp classes/:/Users/dragos/workspace/git/scala/build/quick/classes/library/ Varargs.java 



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

Roland Kuhn

unread,
Jun 27, 2012, 9:38:04 AM6/27/12
to scala-i...@googlegroups.com
Hi Iulian,

oh, that’s nice (I can confirm that this makes it work on the command line). Which Eclipse preferences setting does this correspond to? Java -> Compiler -> “Compiler compliance level” is set to 1.6.

Regards,

Roland

iulian dragos

unread,
Jun 27, 2012, 9:48:25 AM6/27/12
to scala-i...@googlegroups.com
On Wed, Jun 27, 2012 at 3:38 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
Hi Iulian,

oh, that’s nice (I can confirm that this makes it work on the command line). Which Eclipse preferences setting does this correspond to? Java -> Compiler -> “Compiler compliance level” is set to 1.6.

That sounds right. I assume you see a different error message, right?

Roland Kuhn

unread,
Jun 27, 2012, 9:59:55 AM6/27/12
to scala-i...@googlegroups.com
27 jun 2012 kl. 15:48 skrev iulian dragos:



On Wed, Jun 27, 2012 at 3:38 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
Hi Iulian,

oh, that’s nice (I can confirm that this makes it work on the command line). Which Eclipse preferences setting does this correspond to? Java -> Compiler -> “Compiler compliance level” is set to 1.6.

That sounds right. I assume you see a different error message, right?

Between command line and Eclipse? Yes, that is indeed the case: they differ in which signature they ask for.

Eclipse: The method f(Seq<Object>) in the type Varargs is not applicable for the arguments (String, 
 int)
cmdline: The method f(Object[]) in the type A is not applicable for the arguments (String, int)

So, what is the conclusion?

Regards,

Roland

Jeppe Nejsum Madsen

unread,
Jun 27, 2012, 10:22:14 AM6/27/12
to scala-i...@googlegroups.com
On Wed, Jun 27, 2012 at 3:59 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
>
> 27 jun 2012 kl. 15:48 skrev iulian dragos:
>
>
>
> On Wed, Jun 27, 2012 at 3:38 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
>>
>> Hi Iulian,
>>
>> oh, that’s nice (I can confirm that this makes it work on the command
>> line). Which Eclipse preferences setting does this correspond to? Java ->
>> Compiler -> “Compiler compliance level” is set to 1.6.
>
>
> That sounds right. I assume you see a different error message, right?
>
>
> Between command line and Eclipse? Yes, that is indeed the case: they differ
> in which signature they ask for.
>
> Eclipse: The method f(Seq<Object>) in the type Varargs is not applicable for
> the arguments (String,
>  int)
> cmdline: The method f(Object[]) in the type A is not applicable for the
> arguments (String, int)
>
> So, what is the conclusion?

It could be the "Source Compatibility" setting which seem to match the
"-source" command line parameter

/Jeppe

Roland Kuhn

unread,
Jun 27, 2012, 10:27:33 AM6/27/12
to scala-i...@googlegroups.com
Those settings were greyed out and showing “1.6”, and unchecking the “use defaults” box did not change anything beyond making the individual settings changeable.

Regards,

iulian dragos

unread,
Jun 27, 2012, 11:37:40 AM6/27/12
to scala-i...@googlegroups.com
On Wed, Jun 27, 2012 at 3:59 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

27 jun 2012 kl. 15:48 skrev iulian dragos:



On Wed, Jun 27, 2012 at 3:38 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
Hi Iulian,

oh, that’s nice (I can confirm that this makes it work on the command line). Which Eclipse preferences setting does this correspond to? Java -> Compiler -> “Compiler compliance level” is set to 1.6.

That sounds right. I assume you see a different error message, right?

Between command line and Eclipse? Yes, that is indeed the case: they differ in which signature they ask for.

Eclipse: The method f(Seq<Object>) in the type Varargs is not applicable for the arguments (String, 
 int)
cmdline: The method f(Object[]) in the type A is not applicable for the arguments (String, int)

So, what is the conclusion?

Please file a ticket. It looks like the presentation compiler does not create the Java compatible forwarders for @varargs methods. I didn't even know about this annotation :)

iulian
PS. It would probably work fine if the Scala code is in binary form (different project, or a jar on the classpath of the Java project)

Roland Kuhn

unread,
Jun 28, 2012, 3:30:29 AM6/28/12
to scala-i...@googlegroups.com
27 jun 2012 kl. 17:37 skrev iulian dragos:

On Wed, Jun 27, 2012 at 3:59 PM, Roland Kuhn <goo...@rkuhn.info> wrote:

27 jun 2012 kl. 15:48 skrev iulian dragos:



On Wed, Jun 27, 2012 at 3:38 PM, Roland Kuhn <goo...@rkuhn.info> wrote:
Hi Iulian,

oh, that’s nice (I can confirm that this makes it work on the command line). Which Eclipse preferences setting does this correspond to? Java -> Compiler -> “Compiler compliance level” is set to 1.6.

That sounds right. I assume you see a different error message, right?

Between command line and Eclipse? Yes, that is indeed the case: they differ in which signature they ask for.

Eclipse: The method f(Seq<Object>) in the type Varargs is not applicable for the arguments (String, 
 int)
cmdline: The method f(Object[]) in the type A is not applicable for the arguments (String, int)

So, what is the conclusion?

Please file a ticket. It looks like the presentation compiler does not create the Java compatible forwarders for @varargs methods. I didn't even know about this annotation :)


iulian
PS. It would probably work fine if the Scala code is in binary form (different project, or a jar on the classpath of the Java project)

Ah, yes, that explains it!

Thanks,

Roland

Scott Carey

unread,
Jan 19, 2016, 2:30:03 AM1/19/16
to Scala IDE User
This still seems to be an issue.  Any progress in the last 3.5 years?

iulian dragos

unread,
Jan 19, 2016, 5:03:26 AM1/19/16
to scala-i...@googlegroups.com
On Tue, Jan 19, 2016 at 8:30 AM, Scott Carey <scott...@gmail.com> wrote:
This still seems to be an issue.  Any progress in the last 3.5 years?

According to the linked ticket, no progress. As you for sure know, there's only a handful of developers here, and var-args annotations from Java isn't very high priority. However, if you (or someone else on this list) would like to help, we'd be happy to help you get started.

iulian
 

--
You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/334b5bf9-1e15-450b-a324-cec7e9c449ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Simon Schäfer

unread,
Jan 19, 2016, 5:09:24 AM1/19/16
to scala-i...@googlegroups.com


On 01/19/2016 08:30 AM, Scott Carey wrote:
This still seems to be an issue.  Any progress in the last 3.5 years?
Quite a long time for a bug to be remembered by anyone. I at least didn't even know it exists. If the fix is indeed just to translate Scala varargs to vararg annotation to Java varargs, then it should be easy to fix. I'm going to have a look.

Here is the ticket: https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1001108-presentation-compiler-does-not-generate-java-forwarders-for-@varargs-annotation/details#
Reply all
Reply to author
Forward
0 new messages