- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Problem: Java and Scala interoperability in 2.8.0.RC1
Tue, 2010-05-04, 17:10
Hi,
I'd like to invoke Scala code from Java.
I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
but these codes can't be compiled in Scala 2.8.0.RC1.
Here is the snippet code in TestFunctions.java
// TestFunctions.java
import scala.*;
public class TestFunctions {
static public Function0 test1 = new Function0() {
public Integer apply() { return 0; }
};
static public Function0 test2 = new Function0() {
public String apply() { return "aaaa"; }
};
}
Here is the compile error:
$ javac -cp ../lib/scala-library.jar TestFunctions.java
TestFunctions.java:6: is not abstract and
does not override abstract method apply$mcD$sp() in scala.Function0
public Integer apply() { return 0; }
^
TestFunctions.java:10: is not abstract and
does not override abstract method apply$mcD$sp() in scala.Function0
public String apply() { return "aaaa"; }
^
2 errors
I have two questions.
1. Is this scala 2.8.0 RC1 bug or is the specification of
interoperability between Scala and Java changed?
2. Are there any hints to modify this compile error?
My environments are the followings:
OS: Mac OSX 10.6.3
Java:
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
Scala:
Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
Regards,
K.Okamoto
Tue, 2010-05-04, 18:07
#2
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Jason,
Thank you for your reply.
> Specialization was enabled by default in RC1, and there were a few
> bugs reported and subsequently fixed. You can probably workaround the
> problem with the compiler option -no-specialization.
Because I want to compile my java code with scala-library.jar by javac,
I can't use the scalac compiler option.
Regards,
K.Okamoto
2010/5/5 Jason Zaugg :
> Specialization was enabled by default in RC1, and there were a few
> bugs reported and subsequently fixed. You can probably workaround the
> problem with the compiler option -no-specialization.
>
> The imminent (?) RC2 release should solve the problem, if not raise a bug.
>
> -jason
>
> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto wrote:
>> Hi,
>>
>> I'd like to invoke Scala code from Java.
>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
>> but these codes can't be compiled in Scala 2.8.0.RC1.
>>
>> Here is the snippet code in TestFunctions.java
>>
>> // TestFunctions.java
>> import scala.*;
>>
>> public class TestFunctions {
>> static public Function0 test1 = new Function0() {
>> public Integer apply() { return 0; }
>> };
>>
>> static public Function0 test2 = new Function0() {
>> public String apply() { return "aaaa"; }
>> };
>> }
>>
>>
>> Here is the compile error:
>>
>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>> TestFunctions.java:6: is not abstract and
>> does not override abstract method apply$mcD$sp() in scala.Function0
>> public Integer apply() { return 0; }
>> ^
>> TestFunctions.java:10: is not abstract and
>> does not override abstract method apply$mcD$sp() in scala.Function0
>> public String apply() { return "aaaa"; }
>> ^
>> 2 errors
>>
>> I have two questions.
>>
>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
>> interoperability between Scala and Java changed?
>> 2. Are there any hints to modify this compile error?
>>
>> My environments are the followings:
>>
>> OS: Mac OSX 10.6.3
>> Java:
>> java version "1.6.0_17"
>> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>> Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>>
>> Scala:
>> Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>>
>> Regards,
>> K.Okamoto
>>
>
Tue, 2010-05-04, 18:17
#3
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Oh, I see, that's a tricky problem. It seems that specialized traits
can't be (easily) extended from Java.
You could make a scala class to bridge between the abstract,
specialized methods on the interface Function0 and your java subclass.
The scala compiler will generate default implementations of the
specialised versions of apply. (e.g. apply$mcD$sp)
// scala
class MyFunction0[+R] extends Function0[R]
// java
public Function0 test2 = new MyFunction0() {
public String apply() { return "aaaa"; }
};
You can learn more about the internals of specialization from this
presentation [1].
-jason
[1] http://days2010.scala-lang.org/node/138/151
On Tue, May 4, 2010 at 6:57 PM, Kazumi Okamoto wrote:
> Jason,
>
> Thank you for your reply.
>
>> Specialization was enabled by default in RC1, and there were a few
>> bugs reported and subsequently fixed. You can probably workaround the
>> problem with the compiler option -no-specialization.
>
> Because I want to compile my java code with scala-library.jar by javac,
> I can't use the scalac compiler option.
>
> Regards,
> K.Okamoto
>
> 2010/5/5 Jason Zaugg :
>> Specialization was enabled by default in RC1, and there were a few
>> bugs reported and subsequently fixed. You can probably workaround the
>> problem with the compiler option -no-specialization.
>>
>> The imminent (?) RC2 release should solve the problem, if not raise a bug.
>>
>> -jason
>>
>> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto wrote:
>>> Hi,
>>>
>>> I'd like to invoke Scala code from Java.
>>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
>>> but these codes can't be compiled in Scala 2.8.0.RC1.
>>>
>>> Here is the snippet code in TestFunctions.java
>>>
>>> // TestFunctions.java
>>> import scala.*;
>>>
>>> public class TestFunctions {
>>> static public Function0 test1 = new Function0() {
>>> public Integer apply() { return 0; }
>>> };
>>>
>>> static public Function0 test2 = new Function0() {
>>> public String apply() { return "aaaa"; }
>>> };
>>> }
>>>
>>>
>>> Here is the compile error:
>>>
>>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>>> TestFunctions.java:6: is not abstract and
>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>> public Integer apply() { return 0; }
>>> ^
>>> TestFunctions.java:10: is not abstract and
>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>> public String apply() { return "aaaa"; }
>>> ^
>>> 2 errors
>>>
>>> I have two questions.
>>>
>>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
>>> interoperability between Scala and Java changed?
>>> 2. Are there any hints to modify this compile error?
>>>
>>> My environments are the followings:
>>>
>>> OS: Mac OSX 10.6.3
>>> Java:
>>> java version "1.6.0_17"
>>> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>>> Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>>>
>>> Scala:
>>> Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>>>
>>> Regards,
>>> K.Okamoto
>>>
>>
>
Tue, 2010-05-04, 18:27
#4
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Hi, Kazumi
> >> I have two questions.
> >>
> >> 1. Is this scala 2.8.0 RC1 bug or is the specification of
> >> interoperability between Scala and Java changed?
> >> 2. Are there any hints to modify this compile error?
I'm just a user, so I don't know the answer for the question 1.
But for the question 2, the following code can be complied.
(And I think it should work.)
Seeing the source code, @specialized annotation was added to
scala.Function0 since Scala 2.8.0.RC1.
Therefore, it seems that those who use scala.Function0 from Java codes
must implement so many auto-generated method.
(Those who use scala.Function1 from Java codes would be in dead stuck...)
I also want to know the answer for question 1 :)
-------
import scala.*;
public class TestFunctions {
static public Function0 test1 = new Function0() {
public Integer apply() {
return 0;
}
public void apply$mcV$sp() {
Function0$class.apply$mcV$sp(this);
}
public boolean apply$mcZ$sp() {
return Function0$class.apply$mcZ$sp(this);
}
public byte apply$mcB$sp() {
return Function0$class.apply$mcB$sp(this);
}
public short apply$mcS$sp() {
return Function0$class.apply$mcS$sp(this);
}
public char apply$mcC$sp() {
return Function0$class.apply$mcC$sp(this);
}
public int apply$mcI$sp() {
return Function0$class.apply$mcI$sp(this);
}
public long apply$mcL$sp() {
return Function0$class.apply$mcL$sp(this);
}
public float apply$mcF$sp() {
return Function0$class.apply$mcF$sp(this);
}
public double apply$mcD$sp() {
return Function0$class.apply$mcD$sp(this);
}
};
static public Function0 test2 = new Function0() {
public String apply() {
return "aaaa";
}
public void apply$mcV$sp() {
Function0$class.apply$mcV$sp(this);
}
public boolean apply$mcZ$sp() {
return Function0$class.apply$mcZ$sp(this);
}
public byte apply$mcB$sp() {
return Function0$class.apply$mcB$sp(this);
}
public short apply$mcS$sp() {
return Function0$class.apply$mcS$sp(this);
}
public char apply$mcC$sp() {
return Function0$class.apply$mcC$sp(this);
}
public int apply$mcI$sp() {
return Function0$class.apply$mcI$sp(this);
}
public long apply$mcL$sp() {
return Function0$class.apply$mcL$sp(this);
}
public float apply$mcF$sp() {
return Function0$class.apply$mcF$sp(this);
}
public double apply$mcD$sp() {
return Function0$class.apply$mcD$sp(this);
}
};
}
Best Regards,
Tue, 2010-05-04, 19:47
#5
difference between "() => { doStuff() }" and "{ doStuff()}"
what's the difference, except that i can only apply the latter to a
method which takes "f: => returntype" as a parameter and the first one
to methods which want "f: () => returntype"?
Tue, 2010-05-04, 19:57
#6
Re: difference between "() => { doStuff() }" and "{ doStuff()}
semantically there is really no much difference
syntactically "=> T" is more convenient for DSL's than "() => T"
for example:it is possible to define a 'while' function (having "=> T" parameters)
that can be called using natural while(condition){someCode} use-site syntax
by the way: I aways found it strange that Scala supports
functions with zero parameter lists but does not support
function values with zero parameter lists (maybe making
CBV parameters unnecessary (?))
Luc
On Tue, May 4, 2010 at 8:46 PM, HamsterofDeath <h-star@gmx.de> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
On Tue, May 4, 2010 at 8:46 PM, HamsterofDeath <h-star@gmx.de> wrote:
what's the difference, except that i can only apply the latter to a
method which takes "f: => returntype" as a parameter and the first one
to methods which want "f: () => returntype"?
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Tue, 2010-05-04, 20:07
#7
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
On Tuesday 04 May 2010, Jason Zaugg wrote:
> Oh, I see, that's a tricky problem. It seems that specialized traits
> can't be (easily) extended from Java.
>
> You could make a scala class to bridge between the abstract,
> specialized methods on the interface Function0 and your java subclass.
> The scala compiler will generate default implementations of the
> specialised versions of apply. (e.g. apply$mcD$sp)
In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be used. I don't know if it is considered an implementation detail or subject to change, though.
-Mark
> // scala
> class MyFunction0[+R] extends Function0[R]
>
> // java
> public Function0 test2 = new MyFunction0() {
> public String apply() { return "aaaa"; }
> };
>
> You can learn more about the internals of specialization from this
> presentation [1].
>
> -jason
>
> [1] http://days2010.scala-lang.org/node/138/151
>
> On Tue, May 4, 2010 at 6:57 PM, Kazumi Okamoto wrote:
> > Jason,
> >
> > Thank you for your reply.
> >
> >> Specialization was enabled by default in RC1, and there were a few
> >> bugs reported and subsequently fixed. You can probably workaround the
> >> problem with the compiler option -no-specialization.
> >
> > Because I want to compile my java code with scala-library.jar by javac,
> > I can't use the scalac compiler option.
> >
> > Regards,
> > K.Okamoto
> >
> > 2010/5/5 Jason Zaugg :
> >> Specialization was enabled by default in RC1, and there were a few
> >> bugs reported and subsequently fixed. You can probably workaround the
> >> problem with the compiler option -no-specialization.
> >>
> >> The imminent (?) RC2 release should solve the problem, if not raise a bug.
> >>
> >> -jason
> >>
> >> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto wrote:
> >>> Hi,
> >>>
> >>> I'd like to invoke Scala code from Java.
> >>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
> >>> but these codes can't be compiled in Scala 2.8.0.RC1.
> >>>
> >>> Here is the snippet code in TestFunctions.java
> >>>
> >>> // TestFunctions.java
> >>> import scala.*;
> >>>
> >>> public class TestFunctions {
> >>> static public Function0 test1 = new Function0() {
> >>> public Integer apply() { return 0; }
> >>> };
> >>>
> >>> static public Function0 test2 = new Function0() {
> >>> public String apply() { return "aaaa"; }
> >>> };
> >>> }
> >>>
> >>>
> >>> Here is the compile error:
> >>>
> >>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
> >>> TestFunctions.java:6: is not abstract and
> >>> does not override abstract method apply$mcD$sp() in scala.Function0
> >>> public Integer apply() { return 0; }
> >>> ^
> >>> TestFunctions.java:10: is not abstract and
> >>> does not override abstract method apply$mcD$sp() in scala.Function0
> >>> public String apply() { return "aaaa"; }
> >>> ^
> >>> 2 errors
> >>>
> >>> I have two questions.
> >>>
> >>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
> >>> interoperability between Scala and Java changed?
> >>> 2. Are there any hints to modify this compile error?
> >>>
> >>> My environments are the followings:
> >>>
> >>> OS: Mac OSX 10.6.3
> >>> Java:
> >>> java version "1.6.0_17"
> >>> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
> >>> Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
> >>>
> >>> Scala:
> >>> Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
> >>>
> >>> Regards,
> >>> K.Okamoto
> >>>
> >>
> >
>
>
Tue, 2010-05-04, 20:17
#8
Re: difference between "() => { doStuff() }" and "{ doStuff()}"
On Tuesday May 4 2010, HamsterofDeath wrote:
> what's the difference, except that i can only apply the latter to a
> method which takes "f: => returntype" as a parameter and the first
> one to methods which want "f: () => returntype"?
When you write { doStuff() } as an argument, it evaluates that block and
passes the result to the called method.
When you write () => { doStuff() } you're writing a function literal
whose type is Function1[Unit, Stuff] where Stuff is the result type for
the block containing doStuff().
Randall Schulz
Tue, 2010-05-04, 20:27
#9
Re: difference between "() => { doStuff() }" and "{ doStuff()}
Also, you can convert a CBN to a Function1 using _ :
def f(z: =>T) = z _ // the return is of type ()=>T
Max
On Tue, May 4, 2010 at 3:00 PM, Randall R Schulz <rschulz@sonic.net> wrote:
On Tuesday May 4 2010, HamsterofDeath wrote:
> what's the difference, except that i can only apply the latter to a
> method which takes "f: => returntype" as a parameter and the first
> one to methods which want "f: () => returntype"?
When you write { doStuff() } as an argument, it evaluates that block and
passes the result to the called method.
When you write () => { doStuff() } you're writing a function literal
whose type is Function1[Unit, Stuff] where Stuff is the result type for
the block containing doStuff().
Randall Schulz
Tue, 2010-05-04, 20:37
#10
Re: difference between "() => { doStuff() }" and "{ doStuff()}"
i assume you meant if i wrote:
val x = () => whatever()
and
val x = whatever()
?
because in both cases, as a parameter it is not evaluated immediately. i
tested it. take a look at HashMap.getOrElseUpdate
the function is "=> B", but is evaluated only if necessary
Randall R Schulz schrieb:
> On Tuesday May 4 2010, HamsterofDeath wrote:
>
>> what's the difference, except that i can only apply the latter to a
>> method which takes "f: => returntype" as a parameter and the first
>> one to methods which want "f: () => returntype"?
>>
>
> When you write { doStuff() } as an argument, it evaluates that block and
> passes the result to the called method.
>
> When you write () => { doStuff() } you're writing a function literal
> whose type is Function1[Unit, Stuff] where Stuff is the result type for
> the block containing doStuff().
>
>
> Randall Schulz
>
>
Tue, 2010-05-04, 20:57
#11
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
On Tue, 4 May 2010 14:58:02 -0400
Mark Harrah wrote:
> In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be used. I don't know if it is considered an implementation detail or subject to change, though.
Oh, it's working fine with Scala 2.8.0.RC1.
I hope scala.runtime.AbstractFunctionX could be useful skeletons like
java.util.AbstractList, available for users.
source:
import scala.Function0;
import scala.runtime.AbstractFunction0;
import scala.collection.mutable.Map;
import scala.collection.mutable.LinkedHashMap;
public class TestFunctions {
static public Function0 test1 = new AbstractFunction0() {
public Integer apply() {
return 0;
}
};
static public Function0 test2 = new AbstractFunction0() {
public String apply() {
return "aaaa";
}
};
public static void main(String[] args) {
Map map1 = new LinkedHashMap();
Map map2 = new LinkedHashMap();
System.out.printf("test1 = %d%n", map1.getOrElse(0, test1));
System.out.printf("test2 = %s%n", map2.getOrElse(0, test2));
};
}
results:
test1 = 0
test2 = aaaa
Tue, 2010-05-04, 21:27
#12
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Are there any hints to know if it is a implementation detail or not?
On Wed, 05 May 2010 04:51:39 +0900
Yukinori NAKATA wrote:
> > In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be used. I don't know if it is considered an implementation detail or subject to change, though.
>
> Oh, it's working fine with Scala 2.8.0.RC1.
>
> I hope scala.runtime.AbstractFunctionX could be useful skeletons like
> java.util.AbstractList, available for users.
Regards,
Yukinori NAKATA
--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
Tue, 2010-05-04, 22:37
#13
Re: difference between "() => { doStuff() }" and "{ doStuff()}
{ doStuff() } is a block expression containing a statement that when executed will call doStuff.() => { doStuff() } is a single expression consisting of a function that contains a block expression containing a statement that when executed will call doStuff.
If a method takes a () => T parameter, then you have to pass it a an expression of type () => T.If a method takes a => T parameter, then you have to pass it an expression of type T. However, behind the scenes that expression will be wrapped in a function, and that function will be invoked whenever the method reads it.
On Tue, May 4, 2010 at 2:46 PM, HamsterofDeath <h-star@gmx.de> wrote:
If a method takes a () => T parameter, then you have to pass it a an expression of type () => T.If a method takes a => T parameter, then you have to pass it an expression of type T. However, behind the scenes that expression will be wrapped in a function, and that function will be invoked whenever the method reads it.
On Tue, May 4, 2010 at 2:46 PM, HamsterofDeath <h-star@gmx.de> wrote:
what's the difference, except that i can only apply the latter to a
method which takes "f: => returntype" as a parameter and the first one
to methods which want "f: () => returntype"?
Tue, 2010-05-04, 23:47
#14
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Jason,
Thank you for your reply.
> You could make a scala class to bridge between the abstract,
> specialized methods on the interface Function0 and your java subclass.
> The scala compiler will generate default implementations of the
> specialised versions of apply. (e.g. apply$mcD$sp)
I tried this solution and it worked properly,but I have also questions.
How do I get the specialization method info of Scala? API documents or
source code?
Regards,
K.Okamoto
2010/5/5 Jason Zaugg :
> Oh, I see, that's a tricky problem. It seems that specialized traits
> can't be (easily) extended from Java.
>
> You could make a scala class to bridge between the abstract,
> specialized methods on the interface Function0 and your java subclass.
> The scala compiler will generate default implementations of the
> specialised versions of apply. (e.g. apply$mcD$sp)
>
> // scala
> class MyFunction0[+R] extends Function0[R]
>
> // java
> public Function0 test2 = new MyFunction0() {
> public String apply() { return "aaaa"; }
> };
>
> You can learn more about the internals of specialization from this
> presentation [1].
>
> -jason
>
> [1] http://days2010.scala-lang.org/node/138/151
>
> On Tue, May 4, 2010 at 6:57 PM, Kazumi Okamoto wrote:
>> Jason,
>>
>> Thank you for your reply.
>>
>>> Specialization was enabled by default in RC1, and there were a few
>>> bugs reported and subsequently fixed. You can probably workaround the
>>> problem with the compiler option -no-specialization.
>>
>> Because I want to compile my java code with scala-library.jar by javac,
>> I can't use the scalac compiler option.
>>
>> Regards,
>> K.Okamoto
>>
>> 2010/5/5 Jason Zaugg :
>>> Specialization was enabled by default in RC1, and there were a few
>>> bugs reported and subsequently fixed. You can probably workaround the
>>> problem with the compiler option -no-specialization.
>>>
>>> The imminent (?) RC2 release should solve the problem, if not raise a bug.
>>>
>>> -jason
>>>
>>> On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto wrote:
>>>> Hi,
>>>>
>>>> I'd like to invoke Scala code from Java.
>>>> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
>>>> but these codes can't be compiled in Scala 2.8.0.RC1.
>>>>
>>>> Here is the snippet code in TestFunctions.java
>>>>
>>>> // TestFunctions.java
>>>> import scala.*;
>>>>
>>>> public class TestFunctions {
>>>> static public Function0 test1 = new Function0() {
>>>> public Integer apply() { return 0; }
>>>> };
>>>>
>>>> static public Function0 test2 = new Function0() {
>>>> public String apply() { return "aaaa"; }
>>>> };
>>>> }
>>>>
>>>>
>>>> Here is the compile error:
>>>>
>>>> $ javac -cp ../lib/scala-library.jar TestFunctions.java
>>>> TestFunctions.java:6: is not abstract and
>>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>> public Integer apply() { return 0; }
>>>> ^
>>>> TestFunctions.java:10: is not abstract and
>>>> does not override abstract method apply$mcD$sp() in scala.Function0
>>>> public String apply() { return "aaaa"; }
>>>> ^
>>>> 2 errors
>>>>
>>>> I have two questions.
>>>>
>>>> 1. Is this scala 2.8.0 RC1 bug or is the specification of
>>>> interoperability between Scala and Java changed?
>>>> 2. Are there any hints to modify this compile error?
>>>>
>>>> My environments are the followings:
>>>>
>>>> OS: Mac OSX 10.6.3
>>>> Java:
>>>> java version "1.6.0_17"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
>>>> Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>>>>
>>>> Scala:
>>>> Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>>>>
>>>> Regards,
>>>> K.Okamoto
>>>>
>>>
>>
>
Wed, 2010-05-05, 07:07
#15
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Looking at the source code is your best bet at the moment, as Scaladoc
doesn't [1] show
- annotations of trait type parameters
- FunctionN, where N != 1
If you look at the source for Function1 [2], you can see the
@specialized annotation on the type parameters. I've grepped the
currentl list of specialiazed types and methods below.
-jason
[1] http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/...
[2] https://lampsvn.epfl.ch/trac/scala/browser/scala/trunk/src///library/sca...
scala/Function0.scala:trait Function0[@specialized +R] extends AnyRef { self =>
scala/Function1.scala:trait Function1[@specialized(scala.Int,
scala.Long, scala.Float, scala.Double) -T1,
scala/Function2.scala:trait Function2[@specialized(scala.Int,
scala.Long, scala.Double) -T1, @specialized
scala/Product1.scala:trait Product1[@specialized(Int, Long, Double)
+T1] extends Product {
scala/Product2.scala:trait Product2[@specialized(Int, Long, Double)
+T1, @specialized(Int, Long, Double)
scala/Tuple1.scala:case class Tuple1[@specialized(Int, Long, Double) +T1](_1:T1)
scala/Tuple2.scala:case class Tuple2[@specialized(Int, Long, Double)
+T1, @specialized(Int, Long, Double)
scala/collection/immutable/Range.scala: override def
foreach[@specialized(Unit) U](f: Int => U) {
scala/collection/immutable/Range.scala: override final def
foreach[@specialized(Unit) U](f: Int => U)
scala/runtime/AbstractFunction0.scala:abstract class
AbstractFunction0[@specialized +R] extends Function0
scala/runtime/AbstractFunction1.scala:abstract class
AbstractFunction1[@specialized(scala.Int, scala.Long
scala/runtime/AbstractFunction2.scala:abstract class
AbstractFunction2[@specialized(scala.Int, scala.Long
scala/runtime/AnyValCompanion.scala: * class
Tuple1[@specialized(Unit, Int, Double) T]
On Wed, May 5, 2010 at 12:42 AM, Kazumi Okamoto wrote:
> Jason,
>
> Thank you for your reply.
>
>> You could make a scala class to bridge between the abstract,
>> specialized methods on the interface Function0 and your java subclass.
>> The scala compiler will generate default implementations of the
>> specialised versions of apply. (e.g. apply$mcD$sp)
>
> I tried this solution and it worked properly,but I have also questions.
>
> How do I get the specialization method info of Scala? API documents or
> source code?
>
> Regards,
> K.Okamoto
Wed, 2010-05-05, 12:27
#16
Re: Problem: Java and Scala interoperability in 2.8.0.RC1
Hello,
> In the case of FunctionX, I think scala.runtime.AbstractFunctionX can be
> used. I don't know if it is considered an implementation detail or subject
> to change, though.
I found the discussion in scala-internals.
It says that users are granted to use AbstractFunctionX for general use.
Improvements for FunctionN
http://www.scala-lang.org/node/4338
Paul Phillips wrote:
> And I forgot to ask about naming: on the one hand they could go into
> scala.runtime.*, but that sends a message they're not for general use.
> Which, granted, might be the right message to send at this stage. If I
> put them in runtime maybe they should be called AnonFun0-22 or something
> along those lines.
Thanks for making discussions open.
Regards,
Yukinori NAKATA
--------------------------------------
GyaO! - Anime, Dramas, Movies, and Music videos [FREE]
http://pr.mail.yahoo.co.jp/gyao/
Wed, 2010-05-05, 22:57
#17
Re: difference between "() => { doStuff() }" and "{ doStuff()}
On 5 May 2010 04:56, Luc Duponcheel <luc.duponcheel@gmail.com> wrote:
Do you mean that you can call a function defined with no arguments by just using the function's name? e.g.
scala> def f = 6 f: Int
scala> fres17: Int = 6
scala> f()<console>:7: error: f of type Int does not take parameters f() ^
scala> val v = f _v: () => Int = <function0>
scala> vres19: () => Int = <function0>
scala> v() res20: Int = 6
I reckon the call-by-value is more to do with the usage-side rather than the implementation-side. However, with a very terse syntax for blocks/lambdas, the need for CBV is reduced. Thinking of Smalltalk style syntax:
isDone ifTrue: [ do1 ] ifFalse: [ do2 ]
CBV is still pretty neat though in my book.
by the way: I aways found it strange that Scala supports functions with zero parameter lists but does not support function values with zero parameter lists (maybe making CBV parameters unnecessary (?))
Do you mean that you can call a function defined with no arguments by just using the function's name? e.g.
scala> def f = 6 f: Int
scala> fres17: Int = 6
scala> f()<console>:7: error: f of type Int does not take parameters f() ^
scala> val v = f _v: () => Int = <function0>
scala> vres19: () => Int = <function0>
scala> v() res20: Int = 6
I reckon the call-by-value is more to do with the usage-side rather than the implementation-side. However, with a very terse syntax for blocks/lambdas, the need for CBV is reduced. Thinking of Smalltalk style syntax:
isDone ifTrue: [ do1 ] ifFalse: [ do2 ]
CBV is still pretty neat though in my book.
Thu, 2010-05-06, 08:07
#18
Re: difference between "() => { doStuff() }" and "{ doStuff()}
What I mean is the following:
functions having one empty parameter list
and function values having one empty parameter list
work nice together:
scala> def function() = "function"
function: ()java.lang.String
scala> function()
res0: java.lang.String = function
scala> var functionValue = () => "functionValue"
functionValue: () => java.lang.String = <function0>
scala> functionValue()
res1: java.lang.String = functionValue
scala> functionValue = function
functionValue: () => java.lang.String = <function0>
scala> functionValue()
res2: java.lang.String = function
Why not the same for
functions having zero parameter lists (exist in Scala)
and function values having zero parameter lists (do not exist in Scala)
scala> def function = "function"
function: java.lang.String
scala> function
res3: java.lang.String = function
scala> var functionValue = => "functionValue"
<console>:1: error: illegal start of simple expression
var functionValue = => "functionValue"
introducing function values with zero parameter lists
could, maybe, replace call by name
Luc
On Wed, May 5, 2010 at 11:54 PM, Steven Shaw <steshaw@gmail.com> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
functions having one empty parameter list
and function values having one empty parameter list
work nice together:
scala> def function() = "function"
function: ()java.lang.String
scala> function()
res0: java.lang.String = function
scala> var functionValue = () => "functionValue"
functionValue: () => java.lang.String = <function0>
scala> functionValue()
res1: java.lang.String = functionValue
scala> functionValue = function
functionValue: () => java.lang.String = <function0>
scala> functionValue()
res2: java.lang.String = function
Why not the same for
functions having zero parameter lists (exist in Scala)
and function values having zero parameter lists (do not exist in Scala)
scala> def function = "function"
function: java.lang.String
scala> function
res3: java.lang.String = function
scala> var functionValue = => "functionValue"
<console>:1: error: illegal start of simple expression
var functionValue = => "functionValue"
introducing function values with zero parameter lists
could, maybe, replace call by name
Luc
On Wed, May 5, 2010 at 11:54 PM, Steven Shaw <steshaw@gmail.com> wrote:
On 5 May 2010 04:56, Luc Duponcheel <luc.duponcheel@gmail.com> wrote:
by the way: I aways found it strange that Scala supports functions with zero parameter lists but does not support function values with zero parameter lists (maybe making CBV parameters unnecessary (?))
Do you mean that you can call a function defined with no arguments by just using the function's name? e.g.
scala> def f = 6 f: Int
scala> fres17: Int = 6
scala> f()<console>:7: error: f of type Int does not take parameters f() ^
scala> val v = f _v: () => Int = <function0>
scala> vres19: () => Int = <function0>
scala> v() res20: Int = 6
I reckon the call-by-value is more to do with the usage-side rather than the implementation-side. However, with a very terse syntax for blocks/lambdas, the need for CBV is reduced. Thinking of Smalltalk style syntax:
isDone ifTrue: [ do1 ] ifFalse: [ do2 ]
CBV is still pretty neat though in my book.
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Thu, 2010-05-06, 14:47
#19
Re: difference between "() => { doStuff() }" and "{ doStuff()}
On Thursday May 6 2010, Luc Duponcheel wrote:
> What I mean is the following:
> functions having one empty parameter list
> and function values having one empty parameter list
> work nice together:
>
> ...
>
> Why not the same for
> functions having zero parameter lists (exist in Scala)
> and function values having zero parameter lists (do not exist in
> Scala)
>
> ...
>
> introducing function values with zero parameter lists
> could, maybe, replace call by name
How would you refer to such a function value (to store it, pass it,
etc.) without invoking it?
> Luc
Randall Schulz
Thu, 2010-05-06, 15:17
#20
Re: difference between "() => { doStuff() }" and "{ doStuff()}
consider
scala> val fooArg = () => "fooArg"
fooArg: () => java.lang.String = <function0>
scala> def barFun(fooParam: () => java.lang.String) = fooParam()
barFun: (fooParam: () => java.lang.String)java.lang.String
scala> barFun(fooArg)
res0: java.lang.String = fooArg
well, I would like to do something like
scala> val fooArg = => "fooArg"
fooArg: => java.lang.String = <function???>
scala> def barFun(fooParam: => java.lang.String) = fooParam
barFun: (fooParam: => java.lang.String)java.lang.String
scala> barFun(fooArg)
res0: java.lang.String = fooArg
in other words: I would use the current CBN syntax
or am I missing something?
Luc
On Thu, May 6, 2010 at 3:42 PM, Randall R Schulz <rschulz@sonic.net> wrote:
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
scala> val fooArg = () => "fooArg"
fooArg: () => java.lang.String = <function0>
scala> def barFun(fooParam: () => java.lang.String) = fooParam()
barFun: (fooParam: () => java.lang.String)java.lang.String
scala> barFun(fooArg)
res0: java.lang.String = fooArg
well, I would like to do something like
scala> val fooArg = => "fooArg"
fooArg: => java.lang.String = <function???>
scala> def barFun(fooParam: => java.lang.String) = fooParam
barFun: (fooParam: => java.lang.String)java.lang.String
scala> barFun(fooArg)
res0: java.lang.String = fooArg
in other words: I would use the current CBN syntax
or am I missing something?
Luc
On Thu, May 6, 2010 at 3:42 PM, Randall R Schulz <rschulz@sonic.net> wrote:
On Thursday May 6 2010, Luc Duponcheel wrote:
> What I mean is the following:
> functions having one empty parameter list
> and function values having one empty parameter list
> work nice together:
>
> ...
>
> Why not the same for
> functions having zero parameter lists (exist in Scala)
> and function values having zero parameter lists (do not exist in
> Scala)
>
> ...
>
> introducing function values with zero parameter lists
> could, maybe, replace call by name
How would you refer to such a function value (to store it, pass it,
etc.) without invoking it?
> Luc
Randall Schulz
--
__~O
-\ <,
(*)/ (*)
reality goes far beyond imagination
Thu, 2010-05-06, 16:27
#21
Re: difference between "() => { doStuff() }" and "{ doStuff()}
On Thursday May 6 2010, you wrote:
> ...
>
> or am I missing something?
If f is a val whose type is one of these zero-arg-list functions, how do
you distinguish invoking that function from dereferencing f to get the
function itself? It seems strictly ambiguous to me.
> Luc
Randall Schulz
Thu, 2010-05-06, 16:37
#22
Re: difference between "() => { doStuff() }" and "{ doStuff()}
On Thu, May 06, 2010 at 08:21:21AM -0700, Randall R Schulz wrote:
> If f is a val whose type is one of these zero-arg-list functions, how
> do you distinguish invoking that function from dereferencing f to get
> the function itself? It seems strictly ambiguous to me.
The identical issue already exists with 1-empty-arg-list functions.
scala> def f() = 5
f: ()Int
scala> println(f)
5
And you'd distinguish it the same way.
scala> println(() => f)
Specialization was enabled by default in RC1, and there were a few
bugs reported and subsequently fixed. You can probably workaround the
problem with the compiler option -no-specialization.
The imminent (?) RC2 release should solve the problem, if not raise a bug.
-jason
On Tue, May 4, 2010 at 6:10 PM, Kazumi Okamoto wrote:
> Hi,
>
> I'd like to invoke Scala code from Java.
> I wrote some sample codes. These worked properly in Scala 2.8.0.Beta1,
> but these codes can't be compiled in Scala 2.8.0.RC1.
>
> Here is the snippet code in TestFunctions.java
>
> // TestFunctions.java
> import scala.*;
>
> public class TestFunctions {
> static public Function0 test1 = new Function0() {
> public Integer apply() { return 0; }
> };
>
> static public Function0 test2 = new Function0() {
> public String apply() { return "aaaa"; }
> };
> }
>
>
> Here is the compile error:
>
> $ javac -cp ../lib/scala-library.jar TestFunctions.java
> TestFunctions.java:6: is not abstract and
> does not override abstract method apply$mcD$sp() in scala.Function0
> public Integer apply() { return 0; }
> ^
> TestFunctions.java:10: is not abstract and
> does not override abstract method apply$mcD$sp() in scala.Function0
> public String apply() { return "aaaa"; }
> ^
> 2 errors
>
> I have two questions.
>
> 1. Is this scala 2.8.0 RC1 bug or is the specification of
> interoperability between Scala and Java changed?
> 2. Are there any hints to modify this compile error?
>
> My environments are the followings:
>
> OS: Mac OSX 10.6.3
> Java:
> java version "1.6.0_17"
> Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
> Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)
>
> Scala:
> Scala code runner version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
>
> Regards,
> K.Okamoto
>