Re: [scala] Scalandroid

[Matt Hellige]

On Nov 13, 2007 1:02 PM, David Pollak <feeder.of.the.bears@...> wrote:
> The Android VM reads JVM bytecode and converts it into DEX format.
>
> There's no reason that Android can't run any JVM language unless that
> language is dynamically creating bytecode at runtime (this is a
> questionmark.)  There's a discussion of this issue on the JVM Languages list
> right now.

(moving to the lounge...)

I've actually just tried this. The short answer is that it's going to
take at least a little work, and maybe a lot.

I generated the sample activity using the Android scaffolding scripts,
hacked up the build.xml a little bit and ported the main Activity
class to Scala. Everything compiled fine and installed to the
emulator, but I got denied : NoClassDefFoundError. I figured this is
likely a missing scala-library.jar, so I extracted just
scala.ScalaObject and scala.ScalaObject$class and packaged them up
with my own classes. This fixed the NoClassDefFoundError, but now I
get something worse. The onCreate() method of each activity must call
super.onCreate(). The phone checks for this and throws an exception
otherwise. But if I try to call super.onCreate() in my Scala code,  I
get a NoClassDefFoundError. Of course the same code works fine in
Java. The bytecode looks similar from javap, but clearly there's
something going on.

It might be as simple as writing some wrapper code in Java and then
delegating to Scala, but this makes me worry that the dx compiler does
depend in subtle ways on the bytecode. Unfortunately, I don't have any
more time to play with this today. I'd love to learn that it's
something simple.

Happy hacking...
Matt

--
Matt Hellige / matt@...
http://matt.immute.net

[martin odersky-2]

Matt,

> with my own classes. This fixed the NoClassDefFoundError, but now I
> get something worse. The onCreate() method of each activity must call
> super.onCreate(). The phone checks for this and throws an exception
> otherwise. But if I try to call super.onCreate() in my Scala code,  I
> get a NoClassDefFoundError.

It would be good to find out more about this. Certainly, Android would
be a great target for Scala programs if we could get it to work. Can
you give more details about the error your encountered? Which class
was not found?

Thanks

 -- Martin

[Matt Hellige]

On Nov 13, 2007 2:52 PM, martin odersky <odersky@...> wrote:

> Matt,
>
> > with my own classes. This fixed the NoClassDefFoundError, but now I
> > get something worse. The onCreate() method of each activity must call
> > super.onCreate(). The phone checks for this and throws an exception
> > otherwise. But if I try to call super.onCreate() in my Scala code,  I
> > get a NoClassDefFoundError.
>
> It would be good to find out more about this. Certainly, Android would
> be a great target for Scala programs if we could get it to work. Can
> you give more details about the error your encountered? Which class
> was not found?

Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
trying to call the superclass definition of onCreate(). (I realize
that that's not especially helpful.) If I have time, I will try to get
back to this later and find out more info. I think getting details
will require setting up the Android debugging environment a little
more carefully.

m

--
Matt Hellige / matt@...
http://matt.immute.net

[Imam Tashdid ul Alam]

everyone is talking about Android. the thing is, if
Android maintains all the specifications, nothing
should go wrong theoretically.

but, it looks like it is a different virtual machine
altogether. with a promise that it will not let Java
classes feel the difference.

on a relevant note, my question is this: suppose we
make a virtual machine (like Android). also, let's
suppose we interpret Java class files. if Android can
do that, I think IP isn't really the problem here. I'm
not so keen on legal issues anyway.

but the question is: what would be the key
modification/enhancement that would favor Scala-style
programming?

my first impression was that it would take functions a
little more seriously. but I think it is somewhat
misleading. functions seem to be doing fine being
objects. is there any possibility of significant
performance enhancement if functions are represented
differently in a bytecode convention?

I suspect the more effective way would be to take
generics seriously. somewhat along the lines of the
.NET machine. if theoretically it can be guaranteed
that some casts never fail (which, should be the case)
then a VM can take advantage of that. Scala's very
advanced type system, I think, does not get the
performance tuning it deserves. it's somewhat like
compiling a typed-lambda-calculus language to an
untyped one.

this is not a suggestion email, by the way. I just
want to know what's the case. I think a language like
Haskell gets most of its performance boost from
term-rewriting, which is almost impossible, or, I
think, unwise, to do in Scala. helpful people
enlighten me.

cheers,
Imam



      ____________________________________________________________________________________
Get easy, one-click access to your favorites.
Make Yahoo! your homepage.
http://www.yahoo.com/r/hs 

[Dave Webb]

My thinking started along similar thoughts, about alternative JVMs. Does the
advent of Android signal a crack in the hegemony of the JVM? In a few years
we could end up with more Java code running on Android than on Sun's JVM.

Is this an opportunity for an Open Source VM, which is functional/dynamic
friendly, and which can run old Java bytecodes translates or Scala, JRuby
etc native?

A bit off topic, but hey, it's the lounge.

Dave Webb


----- Original Message -----
From: "Imam Tashdid ul Alam" <uchchwhash@...>
To: <scala-lounge@...>
Sent: Tuesday, November 13, 2007 10:43 PM
Subject: Re: [scala-lounge] Re: [scala] Scalandroid

> everyone is talking about Android. the thing is, if
> Android maintains all the specifications, nothing
> should go wrong theoretically.
>
> but, it looks like it is a different virtual machine
> altogether. with a promise that it will not let Java
> classes feel the difference.
>
> on a relevant note, my question is this: suppose we
> make a virtual machine (like Android). also, let's
> suppose we interpret Java class files. if Android can
> do that, I think IP isn't really the problem here. I'm
> not so keen on legal issues anyway.
>
> but the question is: what would be the key
> modification/enhancement that would favor Scala-style
> programming?
>
> my first impression was that it would take functions a
> little more seriously. but I think it is somewhat
> misleading. functions seem to be doing fine being
> objects. is there any possibility of significant
> performance enhancement if functions are represented
> differently in a bytecode convention?
>
> I suspect the more effective way would be to take
> generics seriously. somewhat along the lines of the
> .NET machine. if theoretically it can be guaranteed
> that some casts never fail (which, should be the case)
> then a VM can take advantage of that. Scala's very
> advanced type system, I think, does not get the
> performance tuning it deserves. it's somewhat like
> compiling a typed-lambda-calculus language to an
> untyped one.
>
> this is not a suggestion email, by the way. I just
> want to know what's the case. I think a language like
> Haskell gets most of its performance boost from
> term-rewriting, which is almost impossible, or, I
> think, unwise, to do in Scala. helpful people
> enlighten me.
>
> cheers,
> Imam
>
>
>
>
> ____________________________________________________________________________________
> Get easy, one-click access to your favorites.
> Make Yahoo! your homepage.
> http://www.yahoo.com/r/hs 

[bearfeeder]

On Nov 13, 2007 3:12 PM, Dave Webb <dave@...> wrote:

My thinking started along similar thoughts, about alternative JVMs. Does the
advent of Android signal a crack in the hegemony of the JVM? In a few years
we could end up with more Java code running on Android than on Sun's JVM.

Is this an opportunity for an Open Source VM, which is functional/dynamic
friendly, and which can run old Java bytecodes translates or Scala, JRuby
etc native?

The answer to this question and many more lies in the JVM Languages group. :-)
 

A bit off topic, but hey, it's the lounge.

Dave Webb

----- Original Message -----
From: "Imam Tashdid ul Alam" <uchchwhash@...>
To: <scala-lounge@...>

Sent: Tuesday, November 13, 2007 10:43 PM
Subject: Re: [scala-lounge] Re: [scala] Scalandroid

> everyone is talking about Android. the thing is, if
> Android maintains all the specifications, nothing
> should go wrong theoretically.
>
> but, it looks like it is a different virtual machine
> altogether. with a promise that it will not let Java
> classes feel the difference.
>
> on a relevant note, my question is this: suppose we
> make a virtual machine (like Android). also, let's
> suppose we interpret Java class files. if Android can
> do that, I think IP isn't really the problem here. I'm
> not so keen on legal issues anyway.
>
> but the question is: what would be the key
> modification/enhancement that would favor Scala-style
> programming?
>
> my first impression was that it would take functions a
> little more seriously. but I think it is somewhat
> misleading. functions seem to be doing fine being
> objects. is there any possibility of significant
> performance enhancement if functions are represented
> differently in a bytecode convention?
>
> I suspect the more effective way would be to take
> generics seriously. somewhat along the lines of the
> .NET machine. if theoretically it can be guaranteed
> that some casts never fail (which, should be the case)
> then a VM can take advantage of that. Scala's very
> advanced type system, I think, does not get the
> performance tuning it deserves. it's somewhat like
> compiling a typed-lambda-calculus language to an
> untyped one.
>
> this is not a suggestion email, by the way. I just
> want to know what's the case. I think a language like
> Haskell gets most of its performance boost from
> term-rewriting, which is almost impossible, or, I
> think, unwise, to do in Scala. helpful people
> enlighten me.
>
> cheers,
> Imam
>
>
>
>
> ____________________________________________________________________________________
> Get easy, one-click access to your favorites.
> Make Yahoo! your homepage.
> http://www.yahoo.com/r/hs

--
lift, the secure, simple, powerful web framework
http://liftweb.net

[Imam Tashdid ul Alam]

--- David Pollak <feeder.of.the.bears@...>
wrote:
> The answer to this question and many more lies in
> the JVM Languages group.
> :-)

hmm. didn't know that group existed. thanks! and Neal
Gafter is there!

looks like the hot favorites are:
from John Rose's list:
- tail calls and tail recursion
- continuations and coroutines
- tuples and value-oriented types
- lightweight method objects
- runtime support for closures
- invokedynamic  
from Rémi Forax:
- reified generics (generics at runtime)

so I guess my initial guesses were pretty much right
(as possible candidates) but someone did mention
Parrot :fear: as a fearful example of... well, being
too broad in scope. my question (still burning) is
that which one (or two) of these would be of the
greatest importance from a Scala perspective. I
suppose continuations and coroutines are not exactly
what I have in mind.



      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

[Ingo Maier-2]

It looks like it has problems with invokespecial and super. The
following will work:

Java:

public class MyActivity extends Activity
{
     /** Called with the activity is first created. */
     @Override
     public void onCreate(Bundle icicle)
     {
         super.onCreate(icicle);
         new Sub().f(this);
     }
}

Scala:

class Foo {
   def g(a: Activity) {
     val tv = new TextView(a)
     tv.setText("Hello Android. Cheers, Scala")
     a.setContentView(tv)
   }
}

class Sub extends Foo {
   def f(a: Activity) { g(a) }
}

If I replace the call to g with an explicit super reference, i.e.,

class Sub extends Foo {
   def f(a: Activity) { super.g(a) }
}

I get a NoSuchMethodError at runtime:

E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
E/AndroidRuntime(545): at my.test.MyActivity.onCreate(MyActivity.java:14)
E/AndroidRuntime(545): at
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
E/AndroidRuntime(545): at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
E/AndroidRuntime(545): ... 11 more


The only difference of the generated bytecode I can see from javap's
output is a different constant pool and that it uses invokespecial
instead of invokevirtual in f. Invokespecial is also used if I move g to
Sub and make it private, but it works that way.

Just wanted to share my results. Anyone else playing with it?

Ingo


Matt Hellige wrote:

> On Nov 13, 2007 2:52 PM, martin odersky <odersky@...> wrote:
>> Matt,
>>
>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>> get something worse. The onCreate() method of each activity must call
>>> super.onCreate(). The phone checks for this and throws an exception
>>> otherwise. But if I try to call super.onCreate() in my Scala code,  I
>>> get a NoClassDefFoundError.
>> It would be good to find out more about this. Certainly, Android would
>> be a great target for Scala programs if we could get it to work. Can
>> you give more details about the error your encountered? Which class
>> was not found?
>
> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
> trying to call the superclass definition of onCreate(). (I realize
> that that's not especially helpful.) If I have time, I will try to get
> back to this later and find out more info. I think getting details
> will require setting up the Android debugging environment a little
> more carefully.
>
> m
>

[Ingo Maier-2]

One more thing: it works if Foo is a trait or an abstract class.

Ingo

Ingo Maier wrote:

> It looks like it has problems with invokespecial and super. The
> following will work:
>
> Java:
>
> public class MyActivity extends Activity
> {
>     /** Called with the activity is first created. */
>     @Override
>     public void onCreate(Bundle icicle)
>     {
>         super.onCreate(icicle);
>         new Sub().f(this);
>     }
> }
>
> Scala:
>
> class Foo {
>   def g(a: Activity) {
>     val tv = new TextView(a)
>     tv.setText("Hello Android. Cheers, Scala")
>     a.setContentView(tv)
>   }
> }
>
> class Sub extends Foo {
>   def f(a: Activity) { g(a) }
> }
>
> If I replace the call to g with an explicit super reference, i.e.,
>
> class Sub extends Foo {
>   def f(a: Activity) { super.g(a) }
> }
>
> I get a NoSuchMethodError at runtime:
>
> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
> E/AndroidRuntime(545): at my.test.MyActivity.onCreate(MyActivity.java:14)
> E/AndroidRuntime(545): at
> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
> E/AndroidRuntime(545): at
> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
> E/AndroidRuntime(545): ... 11 more
>
>
> The only difference of the generated bytecode I can see from javap's
> output is a different constant pool and that it uses invokespecial
> instead of invokevirtual in f. Invokespecial is also used if I move g to
> Sub and make it private, but it works that way.
>
> Just wanted to share my results. Anyone else playing with it?
>
> Ingo
>
>
> Matt Hellige wrote:
>> On Nov 13, 2007 2:52 PM, martin odersky <odersky@...> wrote:
>>> Matt,
>>>
>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>> get something worse. The onCreate() method of each activity must call
>>>> super.onCreate(). The phone checks for this and throws an exception
>>>> otherwise. But if I try to call super.onCreate() in my Scala code,  I
>>>> get a NoClassDefFoundError.
>>> It would be good to find out more about this. Certainly, Android would
>>> be a great target for Scala programs if we could get it to work. Can
>>> you give more details about the error your encountered? Which class
>>> was not found?
>>
>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>> trying to call the superclass definition of onCreate(). (I realize
>> that that's not especially helpful.) If I have time, I will try to get
>> back to this later and find out more info. I think getting details
>> will require setting up the Android debugging environment a little
>> more carefully.
>>
>> m
>>
>

[Iulian Dragos-2]

There was a bug in the Scala compiler. The ACC_SUPER flag was not
generated for classfiles. This flag turns on the lookup algorithm for
invoke special. More information is given here:
http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd

Ingo's code works now (and the prime numbers example!) You need the svn
version, or tonights nightly build.

Cheers,
Iulian

Ingo Maier wrote:

> One more thing: it works if Foo is a trait or an abstract class.
>
> Ingo
>
> Ingo Maier wrote:
>> It looks like it has problems with invokespecial and super. The
>> following will work:
>>
>> Java:
>>
>> public class MyActivity extends Activity
>> {
>>     /** Called with the activity is first created. */
>>     @Override
>>     public void onCreate(Bundle icicle)
>>     {
>>         super.onCreate(icicle);
>>         new Sub().f(this);
>>     }
>> }
>>
>> Scala:
>>
>> class Foo {
>>   def g(a: Activity) {
>>     val tv = new TextView(a)
>>     tv.setText("Hello Android. Cheers, Scala")
>>     a.setContentView(tv)
>>   }
>> }
>>
>> class Sub extends Foo {
>>   def f(a: Activity) { g(a) }
>> }
>>
>> If I replace the call to g with an explicit super reference, i.e.,
>>
>> class Sub extends Foo {
>>   def f(a: Activity) { super.g(a) }
>> }
>>
>> I get a NoSuchMethodError at runtime:
>>
>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>> E/AndroidRuntime(545): at my.test.MyActivity.onCreate(MyActivity.java:14)
>> E/AndroidRuntime(545): at
>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>
>> E/AndroidRuntime(545): at
>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>
>> E/AndroidRuntime(545): ... 11 more
>>
>>
>> The only difference of the generated bytecode I can see from javap's
>> output is a different constant pool and that it uses invokespecial
>> instead of invokevirtual in f. Invokespecial is also used if I move g
>> to Sub and make it private, but it works that way.
>>
>> Just wanted to share my results. Anyone else playing with it?
>>
>> Ingo
>>
>>
>> Matt Hellige wrote:
>>> On Nov 13, 2007 2:52 PM, martin odersky
>>> <odersky@...> wrote:
>>>> Matt,
>>>>
>>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>>> get something worse. The onCreate() method of each activity must call
>>>>> super.onCreate(). The phone checks for this and throws an exception
>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,  I
>>>>> get a NoClassDefFoundError.
>>>> It would be good to find out more about this. Certainly, Android would
>>>> be a great target for Scala programs if we could get it to work. Can
>>>> you give more details about the error your encountered? Which class
>>>> was not found?
>>>
>>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>>> trying to call the superclass definition of onCreate(). (I realize
>>> that that's not especially helpful.) If I have time, I will try to get
>>> back to this later and find out more info. I think getting details
>>> will require setting up the Android debugging environment a little
>>> more carefully.
>>>
>>> m
>>>
>>
>
>

[Matt Hellige]

Excellent! That was simpler than I thought, and fixed a bug, too!


On Nov 14, 2007 11:40 AM, Iulian Dragos <iulian.dragos@...> wrote:
> There was a bug in the Scala compiler. The ACC_SUPER flag was not
> generated for classfiles. This flag turns on the lookup algorithm for
> invoke special. More information is given here:
> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>
> Ingo's code works now (and the prime numbers example!) You need the svn
> version, or tonights nightly build.

--
Matt Hellige / matt@...
http://matt.immute.net

[martin odersky-2]

On Nov 14, 2007 6:40 PM, Iulian Dragos <iulian.dragos@...> wrote:

> There was a bug in the Scala compiler. The ACC_SUPER flag was not
> generated for classfiles. This flag turns on the lookup algorithm for
> invoke special. More information is given here:
> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>
> Ingo's code works now (and the prime numbers example!) You need the svn
> version, or tonights nightly build.
>
> Cheers,
> Iulian
>
>
> Ingo Maier wrote:
> > One more thing: it works if Foo is a trait or an abstract class.
> >
> > Ingo
> >
> > Ingo Maier wrote:
> >> It looks like it has problems with invokespecial and super. The
> >> following will work:
> >>
> >> Java:
> >>
> >> public class MyActivity extends Activity
> >> {
> >>     /** Called with the activity is first created. */
> >>     @Override
> >>     public void onCreate(Bundle icicle)
> >>     {
> >>         super.onCreate(icicle);
> >>         new Sub().f(this);
> >>     }
> >> }
> >>
> >> Scala:
> >>
> >> class Foo {
> >>   def g(a: Activity) {
> >>     val tv = new TextView(a)
> >>     tv.setText("Hello Android. Cheers, Scala")
> >>     a.setContentView(tv)
> >>   }
> >> }
> >>
> >> class Sub extends Foo {
> >>   def f(a: Activity) { g(a) }
> >> }
> >>
> >> If I replace the call to g with an explicit super reference, i.e.,
> >>
> >> class Sub extends Foo {
> >>   def f(a: Activity) { super.g(a) }
> >> }
> >>
> >> I get a NoSuchMethodError at runtime:
> >>
> >> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
> >> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
> >> E/AndroidRuntime(545): at my.test.MyActivity.onCreate(MyActivity.java:14)
> >> E/AndroidRuntime(545): at
> >> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
> >>
> >> E/AndroidRuntime(545): at
> >> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
> >>
> >> E/AndroidRuntime(545): ... 11 more
> >>
> >>
> >> The only difference of the generated bytecode I can see from javap's
> >> output is a different constant pool and that it uses invokespecial
> >> instead of invokevirtual in f. Invokespecial is also used if I move g
> >> to Sub and make it private, but it works that way.
> >>
> >> Just wanted to share my results. Anyone else playing with it?
> >>
> >> Ingo
> >>
> >>
> >> Matt Hellige wrote:
> >>> On Nov 13, 2007 2:52 PM, martin odersky
> >>> <odersky@...> wrote:
> >>>> Matt,
> >>>>
> >>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
> >>>>> get something worse. The onCreate() method of each activity must call
> >>>>> super.onCreate(). The phone checks for this and throws an exception
> >>>>> otherwise. But if I try to call super.onCreate() in my Scala code,  I
> >>>>> get a NoClassDefFoundError.
> >>>> It would be good to find out more about this. Certainly, Android would
> >>>> be a great target for Scala programs if we could get it to work. Can
> >>>> you give more details about the error your encountered? Which class
> >>>> was not found?
> >>>
> >>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
> >>> trying to call the superclass definition of onCreate(). (I realize
> >>> that that's not especially helpful.) If I have time, I will try to get
> >>> back to this later and find out more info. I think getting details
> >>> will require setting up the Android debugging environment a little
> >>> more carefully.
> >>>
> >>> m
> >>>
> >>
> >
> >
>
>

[martin odersky-2]

On Nov 14, 2007 6:40 PM, Iulian Dragos <iulian.dragos@...> wrote:
> There was a bug in the Scala compiler. The ACC_SUPER flag was not
> generated for classfiles. This flag turns on the lookup algorithm for
> invoke special. More information is given here:
> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>
I see. That's what I was guessing, more or less. Thanks for finding it
out so quickly!
It's very encouraging that the prime numbers example runs. The next
thing to do is
check whether we can run the scala distribution on Android as is, or whether we
need to cur out some files which use unsupported features. Anyway, I
think Android might be really significant. It would be great if Scala
was running on it from the start.

Cheers

 -- Martin

[Timothy Bussmann]

Hi everyone,

I of course also immediately thought of Scala when I read over Android.  Anyway, I have the Eclipse plug-in set up and doing all the builds nicely (no need to play with Ant).  As noted earlier, the one thing stopping me at this point is not have scala.Object on the emulator.  I certainly imagine the whole Scala library will be needed, assuming you want to use the libraries.

I played around with the dx command line tool and set it up to compile scala-library.jar to .dex format.  As it turns out, I got a VM OutOfMemoryError because dex doesn't allocate enough memory to handle such a large library.  I've already posted a message on the Android Google-Group asking them to support passing arguments to the VM.  I was able to successfully compile the library if I took the actor and xml folders out (no specific reason, I just suspected those weren't depended on by other code, and the xml folder is huge).  I haven't yet figured out how to move the compiled .dex file over to the Android emulator AND have an application package reference it.  

I have a few leads, but just haven't had the time to follow through yet.  Primarily, I'm trying to see if there's an easy way to tweak the dx command line arguments to include the .jar while compiling the user activity code.  Otherwise, I've been browsing through the ADT source code (the eclipse plug-in).  I noted a clearly relevant method called getExternalJars() in build/BaseBuilder.java.

Anyone else working on getting the scala-library.jar onto the emulator?  Any suggestions or progress?

Tim

Iulian Dragos-2 wrote:

There was a bug in the Scala compiler. The ACC_SUPER flag was not
generated for classfiles. This flag turns on the lookup algorithm for
invoke special. More information is given here:
http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd

Ingo's code works now (and the prime numbers example!) You need the svn
version, or tonights nightly build.

Cheers,
Iulian

Ingo Maier wrote:
> One more thing: it works if Foo is a trait or an abstract class.
>
> Ingo
>
> Ingo Maier wrote:
>> It looks like it has problems with invokespecial and super. The
>> following will work:
>>
>> Java:
>>
>> public class MyActivity extends Activity
>> {
>>     /** Called with the activity is first created. */
>>     @Override
>>     public void onCreate(Bundle icicle)
>>     {
>>         super.onCreate(icicle);
>>         new Sub().f(this);
>>     }
>> }
>>
>> Scala:
>>
>> class Foo {
>>   def g(a: Activity) {
>>     val tv = new TextView(a)
>>     tv.setText("Hello Android. Cheers, Scala")
>>     a.setContentView(tv)
>>   }
>> }
>>
>> class Sub extends Foo {
>>   def f(a: Activity) { g(a) }
>> }
>>
>> If I replace the call to g with an explicit super reference, i.e.,
>>
>> class Sub extends Foo {
>>   def f(a: Activity) { super.g(a) }
>> }
>>
>> I get a NoSuchMethodError at runtime:
>>
>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>> E/AndroidRuntime(545): at my.test.MyActivity.onCreate(MyActivity.java:14)
>> E/AndroidRuntime(545): at
>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>
>> E/AndroidRuntime(545): at
>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>
>> E/AndroidRuntime(545): ... 11 more
>>
>>
>> The only difference of the generated bytecode I can see from javap's
>> output is a different constant pool and that it uses invokespecial
>> instead of invokevirtual in f. Invokespecial is also used if I move g
>> to Sub and make it private, but it works that way.
>>
>> Just wanted to share my results. Anyone else playing with it?
>>
>> Ingo
>>
>>
>> Matt Hellige wrote:
>>> On Nov 13, 2007 2:52 PM, martin odersky
>>> <[e-mail]> wrote:
>>>> Matt,
>>>>
>>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>>> get something worse. The onCreate() method of each activity must call
>>>>> super.onCreate(). The phone checks for this and throws an exception
>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,  I
>>>>> get a NoClassDefFoundError.
>>>> It would be good to find out more about this. Certainly, Android would
>>>> be a great target for Scala programs if we could get it to work. Can
>>>> you give more details about the error your encountered? Which class
>>>> was not found?
>>>
>>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>>> trying to call the superclass definition of onCreate(). (I realize
>>> that that's not especially helpful.) If I have time, I will try to get
>>> back to this later and find out more info. I think getting details
>>> will require setting up the Android debugging environment a little
>>> more carefully.
>>>
>>> m
>>>
>>
>
>

[Timothy Bussmann]

Alright, so with some more fiddling around in the Eclipse plug-in, I have managed to get to the point where the discussion I quote below is.  Right now my application (a hello world) pushes and launches successfully all within Eclipse (again, no manual command lines!).  In order to incorporate the Scala library, it actually turned out to be much simpler than I had thought.  I simply added my cut down version of the library as an  external Jar to the project, and made sure it was checked in the Export tab as well.  The result was 3.8 MB .apk package including the library.  I then simply ran the project like normal and the package pushed to the device and launched successfully!

Now, I haven't tried the specific example cited below, but like others, my application crashes with a NoSuchMethodError.  I used the latest version of lib/scala-library.jar from the repository, current as of 12:10am Nov-16.  I'll give the example below a try tomorrow.

I hope this can get up and running because I sure like the idea of programming in Scala for Android while everyone else has to use stinky Java :)

Tim


Hi everyone,

I of course also immediately thought of Scala when I read over Android.  Anyway, I have the Eclipse plug-in set up and doing all the builds nicely (no need to play with Ant).  As noted earlier, the one thing stopping me at this point is not have scala.Object on the emulator.  I certainly imagine the whole Scala library will be needed, assuming you want to use the libraries.

I played around with the dx command line tool and set it up to compile scala-library.jar to .dex format.  As it turns out, I got a VM OutOfMemoryError because dex doesn't allocate enough memory to handle such a large library.  I've already posted a message on the Android Google-Group asking them to support passing arguments to the VM.  I was able to successfully compile the library if I took the actor and xml folders out (no specific reason, I just suspected those weren't depended on by other code, and the xml folder is huge).  I haven't yet figured out how to move the compiled .dex file over to the Android emulator AND have an application package reference it.  

I have a few leads, but just haven't had the time to follow through yet.  Primarily, I'm trying to see if there's an easy way to tweak the dx command line arguments to include the .jar while compiling the user activity code.  Otherwise, I've been browsing through the ADT source code (the eclipse plug-in).  I noted a clearly relevant method called getExternalJars() in build/BaseBuilder.java.

Anyone else working on getting the scala-library.jar onto the emulator?  Any suggestions or progress?

Tim

Iulian Dragos-2 wrote:

There was a bug in the Scala compiler. The ACC_SUPER flag was not
generated for classfiles. This flag turns on the lookup algorithm for
invoke special. More information is given here:
http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd

Ingo's code works now (and the prime numbers example!) You need the svn
version, or tonights nightly build.

Cheers,
Iulian

Ingo Maier wrote:
> One more thing: it works if Foo is a trait or an abstract class.
>
> Ingo
>
> Ingo Maier wrote:
>> It looks like it has problems with invokespecial and super. The
>> following will work:
>>
>> Java:
>>
>> public class MyActivity extends Activity
>> {
>>     /** Called with the activity is first created. */
>>     @Override
>>     public void onCreate(Bundle icicle)
>>     {
>>         super.onCreate(icicle);
>>         new Sub().f(this);
>>     }
>> }
>>
>> Scala:
>>
>> class Foo {
>>   def g(a: Activity) {
>>     val tv = new TextView(a)
>>     tv.setText("Hello Android. Cheers, Scala")
>>     a.setContentView(tv)
>>   }
>> }
>>
>> class Sub extends Foo {
>>   def f(a: Activity) { g(a) }
>> }
>>
>> If I replace the call to g with an explicit super reference, i.e.,
>>
>> class Sub extends Foo {
>>   def f(a: Activity) { super.g(a) }
>> }
>>
>> I get a NoSuchMethodError at runtime:
>>
>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>> E/AndroidRuntime(545): at my.test.MyActivity.onCreate(MyActivity.java:14)
>> E/AndroidRuntime(545): at
>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>
>> E/AndroidRuntime(545): at
>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>
>> E/AndroidRuntime(545): ... 11 more
>>
>>
>> The only difference of the generated bytecode I can see from javap's
>> output is a different constant pool and that it uses invokespecial
>> instead of invokevirtual in f. Invokespecial is also used if I move g
>> to Sub and make it private, but it works that way.
>>
>> Just wanted to share my results. Anyone else playing with it?
>>
>> Ingo
>>
>>
>> Matt Hellige wrote:
>>> On Nov 13, 2007 2:52 PM, martin odersky
>>> <[e-mail]> wrote:
>>>> Matt,
>>>>
>>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>>> get something worse. The onCreate() method of each activity must call
>>>>> super.onCreate(). The phone checks for this and throws an exception
>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,  I
>>>>> get a NoClassDefFoundError.
>>>> It would be good to find out more about this. Certainly, Android would
>>>> be a great target for Scala programs if we could get it to work. Can
>>>> you give more details about the error your encountered? Which class
>>>> was not found?
>>>
>>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>>> trying to call the superclass definition of onCreate(). (I realize
>>> that that's not especially helpful.) If I have time, I will try to get
>>> back to this later and find out more info. I think getting details
>>> will require setting up the Android debugging environment a little
>>> more carefully.
>>>
>>> m
>>>
>>
>
>

[Ingo Maier-2]

Timothy,

Timothy Bussmann wrote:

> Alright, so with some more fiddling around in the Eclipse plug-in, I have
> managed to get to the point where the discussion I quote below is.  Right
> now my application (a hello world) pushes and launches successfully all
> within Eclipse (again, no manual command lines!).  In order to incorporate
> the Scala library, it actually turned out to be much simpler than I had
> thought.  I simply added my cut down version of the library as an  external
> Jar to the project, and made sure it was checked in the Export tab as well.
> The result was 3.8 MB .apk package including the library.  I then simply ran
> the project like normal and the package pushed to the device and launched
> successfully!

Did you use the android and the scala plugin? How did you manage that
the Android plugin compiles the .class files from the bin folder of the
Sala project?

With the command line tools, dx works fine for me, even with the
complete scala library (I just copied the .class files to the projects
bin for now). I get a 4.4MB .dex and a 1MB .apk (which is just a zip)
which uploads fine.

>
> Now, I haven't tried the specific example cited below, but like others, my
> application crashes with a NoSuchMethodError.  I used the latest version of
> lib/scala-library.jar from the repository, current as of 12:10am Nov-16.
> I'll give the example below a try tomorrow.

Strange. Are you sure that your NoSuchMethodError happens at the super
call? You can get a stack trace with the ddms debugger. You can even
start it after the exception was thrown. It definitely works for me with
a custom build I did immediately after Iulian committed the ACC_SUPER
patch. Anyways, maybe you discovered another bug. Can you post your code?

Ingo

>
> I hope this can get up and running because I sure like the idea of
> programming in Scala for Android while everyone else has to use stinky Java
> :)
>
> Tim
>
>
> Timothy Bussmann wrote:
>> Hi everyone,
>>
>> I of course also immediately thought of Scala when I read over Android.
>> Anyway, I have the Eclipse plug-in set up and doing all the builds nicely
>> (no need to play with Ant).  As noted earlier, the one thing stopping me
>> at this point is not have scala.Object on the emulator.  I certainly
>> imagine the whole Scala library will be needed, assuming you want to use
>> the libraries.
>>
>> I played around with the dx command line tool and set it up to compile
>> scala-library.jar to .dex format.  As it turns out, I got a VM
>> OutOfMemoryError because dex doesn't allocate enough memory to handle such
>> a large library.  I've already posted a message on the Android
>> Google-Group asking them to support passing arguments to the VM.  I was
>> able to successfully compile the library if I took the actor and xml
>> folders out (no specific reason, I just suspected those weren't depended
>> on by other code, and the xml folder is huge).  I haven't yet figured out
>> how to move the compiled .dex file over to the Android emulator AND have
>> an application package reference it.  
>>
>> I have a few leads, but just haven't had the time to follow through yet.
>> Primarily, I'm trying to see if there's an easy way to tweak the dx
>> command line arguments to include the .jar while compiling the user
>> activity code.  Otherwise, I've been browsing through the ADT source code
>> (the eclipse plug-in).  I noted a clearly relevant method called
>> getExternalJars() in build/BaseBuilder.java.
>>
>> Anyone else working on getting the scala-library.jar onto the emulator?
>> Any suggestions or progress?
>>
>> Tim
>>
>>
>>
>> Iulian Dragos-2 wrote:
>>> There was a bug in the Scala compiler. The ACC_SUPER flag was not
>>> generated for classfiles. This flag turns on the lookup algorithm for
>>> invoke special. More information is given here:
>>> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>>>
>>> Ingo's code works now (and the prime numbers example!) You need the svn
>>> version, or tonights nightly build.
>>>
>>> Cheers,
>>> Iulian
>>>
>>> Ingo Maier wrote:
>>>> One more thing: it works if Foo is a trait or an abstract class.
>>>>
>>>> Ingo
>>>>
>>>> Ingo Maier wrote:
>>>>> It looks like it has problems with invokespecial and super. The
>>>>> following will work:
>>>>>
>>>>> Java:
>>>>>
>>>>> public class MyActivity extends Activity
>>>>> {
>>>>>     /** Called with the activity is first created. */
>>>>>     @Override
>>>>>     public void onCreate(Bundle icicle)
>>>>>     {
>>>>>         super.onCreate(icicle);
>>>>>         new Sub().f(this);
>>>>>     }
>>>>> }
>>>>>
>>>>> Scala:
>>>>>
>>>>> class Foo {
>>>>>   def g(a: Activity) {
>>>>>     val tv = new TextView(a)
>>>>>     tv.setText("Hello Android. Cheers, Scala")
>>>>>     a.setContentView(tv)
>>>>>   }
>>>>> }
>>>>>
>>>>> class Sub extends Foo {
>>>>>   def f(a: Activity) { g(a) }
>>>>> }
>>>>>
>>>>> If I replace the call to g with an explicit super reference, i.e.,
>>>>>
>>>>> class Sub extends Foo {
>>>>>   def f(a: Activity) { super.g(a) }
>>>>> }
>>>>>
>>>>> I get a NoSuchMethodError at runtime:
>>>>>
>>>>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>>>>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>>>>> E/AndroidRuntime(545): at
>>>>> my.test.MyActivity.onCreate(MyActivity.java:14)
>>>>> E/AndroidRuntime(545): at
>>>>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>>>>
>>>>> E/AndroidRuntime(545): at
>>>>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>>>>
>>>>> E/AndroidRuntime(545): ... 11 more
>>>>>
>>>>>
>>>>> The only difference of the generated bytecode I can see from javap's
>>>>> output is a different constant pool and that it uses invokespecial
>>>>> instead of invokevirtual in f. Invokespecial is also used if I move g
>>>>> to Sub and make it private, but it works that way.
>>>>>
>>>>> Just wanted to share my results. Anyone else playing with it?
>>>>>
>>>>> Ingo
>>>>>
>>>>>
>>>>> Matt Hellige wrote:
>>>>>> On Nov 13, 2007 2:52 PM, martin odersky
>>>>>> <odersky@...> wrote:
>>>>>>> Matt,
>>>>>>>
>>>>>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>>>>>> get something worse. The onCreate() method of each activity must
>>>>>>>> call
>>>>>>>> super.onCreate(). The phone checks for this and throws an exception
>>>>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,
>>>>>>>> I
>>>>>>>> get a NoClassDefFoundError.
>>>>>>> It would be good to find out more about this. Certainly, Android
>>>>>>> would
>>>>>>> be a great target for Scala programs if we could get it to work. Can
>>>>>>> you give more details about the error your encountered? Which class
>>>>>>> was not found?
>>>>>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>>>>>> trying to call the superclass definition of onCreate(). (I realize
>>>>>> that that's not especially helpful.) If I have time, I will try to get
>>>>>> back to this later and find out more info. I think getting details
>>>>>> will require setting up the Android debugging environment a little
>>>>>> more carefully.
>>>>>>
>>>>>> m
>>>>>>
>>>>
>>>
>>>
>>
>

[Iulian Dragos-2]

Timothy Bussmann wrote:

> Alright, so with some more fiddling around in the Eclipse plug-in, I have
> managed to get to the point where the discussion I quote below is.  Right
> now my application (a hello world) pushes and launches successfully all
> within Eclipse (again, no manual command lines!).  In order to incorporate
> the Scala library, it actually turned out to be much simpler than I had
> thought.  I simply added my cut down version of the library as an  external
> Jar to the project, and made sure it was checked in the Export tab as well.
> The result was 3.8 MB .apk package including the library.  I then simply ran
> the project like normal and the package pushed to the device and launched
> successfully!

This is very cool! I haven't tried the Eclipse plugin yet, but it sounds
like I should :)

> Now, I haven't tried the specific example cited below, but like others, my
> application crashes with a NoSuchMethodError.  I used the latest version of
> lib/scala-library.jar from the repository, current as of 12:10am Nov-16.
> I'll give the example below a try tomorrow.

The library found under lib/ in the SVN repository is a bootstrap
library, usually the last final release. The bug you mention is fixed in
the svn, so what you need to do is either checkout the trunk and build
the compiler, or download one of the nightly distributions found here:

http://www.scala-lang.org/downloads/distrib/files/nightly/

We plan on having a release by the end of the month, but until then the
above should be ok for experimenting.

Iulian

>
> I hope this can get up and running because I sure like the idea of
> programming in Scala for Android while everyone else has to use stinky Java
> :)
>
> Tim
>
>
> Timothy Bussmann wrote:
>> Hi everyone,
>>
>> I of course also immediately thought of Scala when I read over Android.
>> Anyway, I have the Eclipse plug-in set up and doing all the builds nicely
>> (no need to play with Ant).  As noted earlier, the one thing stopping me
>> at this point is not have scala.Object on the emulator.  I certainly
>> imagine the whole Scala library will be needed, assuming you want to use
>> the libraries.
>>
>> I played around with the dx command line tool and set it up to compile
>> scala-library.jar to .dex format.  As it turns out, I got a VM
>> OutOfMemoryError because dex doesn't allocate enough memory to handle such
>> a large library.  I've already posted a message on the Android
>> Google-Group asking them to support passing arguments to the VM.  I was
>> able to successfully compile the library if I took the actor and xml
>> folders out (no specific reason, I just suspected those weren't depended
>> on by other code, and the xml folder is huge).  I haven't yet figured out
>> how to move the compiled .dex file over to the Android emulator AND have
>> an application package reference it.  
>>
>> I have a few leads, but just haven't had the time to follow through yet.
>> Primarily, I'm trying to see if there's an easy way to tweak the dx
>> command line arguments to include the .jar while compiling the user
>> activity code.  Otherwise, I've been browsing through the ADT source code
>> (the eclipse plug-in).  I noted a clearly relevant method called
>> getExternalJars() in build/BaseBuilder.java.
>>
>> Anyone else working on getting the scala-library.jar onto the emulator?
>> Any suggestions or progress?
>>
>> Tim
>>
>>
>>
>> Iulian Dragos-2 wrote:
>>> There was a bug in the Scala compiler. The ACC_SUPER flag was not
>>> generated for classfiles. This flag turns on the lookup algorithm for
>>> invoke special. More information is given here:
>>> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>>>
>>> Ingo's code works now (and the prime numbers example!) You need the svn
>>> version, or tonights nightly build.
>>>
>>> Cheers,
>>> Iulian
>>>
>>> Ingo Maier wrote:
>>>> One more thing: it works if Foo is a trait or an abstract class.
>>>>
>>>> Ingo
>>>>
>>>> Ingo Maier wrote:
>>>>> It looks like it has problems with invokespecial and super. The
>>>>> following will work:
>>>>>
>>>>> Java:
>>>>>
>>>>> public class MyActivity extends Activity
>>>>> {
>>>>>     /** Called with the activity is first created. */
>>>>>     @Override
>>>>>     public void onCreate(Bundle icicle)
>>>>>     {
>>>>>         super.onCreate(icicle);
>>>>>         new Sub().f(this);
>>>>>     }
>>>>> }
>>>>>
>>>>> Scala:
>>>>>
>>>>> class Foo {
>>>>>   def g(a: Activity) {
>>>>>     val tv = new TextView(a)
>>>>>     tv.setText("Hello Android. Cheers, Scala")
>>>>>     a.setContentView(tv)
>>>>>   }
>>>>> }
>>>>>
>>>>> class Sub extends Foo {
>>>>>   def f(a: Activity) { g(a) }
>>>>> }
>>>>>
>>>>> If I replace the call to g with an explicit super reference, i.e.,
>>>>>
>>>>> class Sub extends Foo {
>>>>>   def f(a: Activity) { super.g(a) }
>>>>> }
>>>>>
>>>>> I get a NoSuchMethodError at runtime:
>>>>>
>>>>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>>>>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>>>>> E/AndroidRuntime(545): at
>>>>> my.test.MyActivity.onCreate(MyActivity.java:14)
>>>>> E/AndroidRuntime(545): at
>>>>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>>>>
>>>>> E/AndroidRuntime(545): at
>>>>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>>>>
>>>>> E/AndroidRuntime(545): ... 11 more
>>>>>
>>>>>
>>>>> The only difference of the generated bytecode I can see from javap's
>>>>> output is a different constant pool and that it uses invokespecial
>>>>> instead of invokevirtual in f. Invokespecial is also used if I move g
>>>>> to Sub and make it private, but it works that way.
>>>>>
>>>>> Just wanted to share my results. Anyone else playing with it?
>>>>>
>>>>> Ingo
>>>>>
>>>>>
>>>>> Matt Hellige wrote:
>>>>>> On Nov 13, 2007 2:52 PM, martin odersky
>>>>>> <odersky@...> wrote:
>>>>>>> Matt,
>>>>>>>
>>>>>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>>>>>> get something worse. The onCreate() method of each activity must
>>>>>>>> call
>>>>>>>> super.onCreate(). The phone checks for this and throws an exception
>>>>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,
>>>>>>>> I
>>>>>>>> get a NoClassDefFoundError.
>>>>>>> It would be good to find out more about this. Certainly, Android
>>>>>>> would
>>>>>>> be a great target for Scala programs if we could get it to work. Can
>>>>>>> you give more details about the error your encountered? Which class
>>>>>>> was not found?
>>>>>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>>>>>> trying to call the superclass definition of onCreate(). (I realize
>>>>>> that that's not especially helpful.) If I have time, I will try to get
>>>>>> back to this later and find out more info. I think getting details
>>>>>> will require setting up the Android debugging environment a little
>>>>>> more carefully.
>>>>>>
>>>>>> m
>>>>>>
>>>>
>>>
>>>
>>
>

[Timothy Bussmann]

I used both the Android and Scala plugin together on the same project.  First, I created a new Scala project ScalaAndroid (zip of the project attached).  I then right clicked on it and converted it to an Android project.  Finally, I manually edited the project file to include a Java build just before the Scala build (to compile the R.java file).  Actually, is that even necessary?  Will the scala compiler compile java files as well?  I also added the Java library to the project because the Scala plugin complained about not being able to find java.rmi.Remote.

Now I'm not sure what goes on behind the scenes, but everything happens as you would expect.  The compiled .class files get picked up and packed into the .apk just like they should.

When debugging (also inside Eclipse :), my activity did crash on the super.onCreate(icicle) call.  However, as pointed out, I was using the scala libraries in the lib/ folder, which actually don't include the fix.  I'll give the nightly build a try soon.

Let me know if you still have trouble using both the Android and Scala plugins together to run this.

TimScalaAndroid.zip

Ingo Maier-2 wrote:

Timothy,

Timothy Bussmann wrote:
> Alright, so with some more fiddling around in the Eclipse plug-in, I have
> managed to get to the point where the discussion I quote below is.  Right
> now my application (a hello world) pushes and launches successfully all
> within Eclipse (again, no manual command lines!).  In order to incorporate
> the Scala library, it actually turned out to be much simpler than I had
> thought.  I simply added my cut down version of the library as an  external
> Jar to the project, and made sure it was checked in the Export tab as well.
> The result was 3.8 MB .apk package including the library.  I then simply ran
> the project like normal and the package pushed to the device and launched
> successfully!

Did you use the android and the scala plugin? How did you manage that
the Android plugin compiles the .class files from the bin folder of the
Sala project?

With the command line tools, dx works fine for me, even with the
complete scala library (I just copied the .class files to the projects
bin for now). I get a 4.4MB .dex and a 1MB .apk (which is just a zip)
which uploads fine.

>
> Now, I haven't tried the specific example cited below, but like others, my
> application crashes with a NoSuchMethodError.  I used the latest version of
> lib/scala-library.jar from the repository, current as of 12:10am Nov-16.
> I'll give the example below a try tomorrow.

Strange. Are you sure that your NoSuchMethodError happens at the super
call? You can get a stack trace with the ddms debugger. You can even
start it after the exception was thrown. It definitely works for me with
a custom build I did immediately after Iulian committed the ACC_SUPER
patch. Anyways, maybe you discovered another bug. Can you post your code?

Ingo

>
> I hope this can get up and running because I sure like the idea of
> programming in Scala for Android while everyone else has to use stinky Java
> :)
>
> Tim
>
>
> Timothy Bussmann wrote:
>> Hi everyone,
>>
>> I of course also immediately thought of Scala when I read over Android.
>> Anyway, I have the Eclipse plug-in set up and doing all the builds nicely
>> (no need to play with Ant).  As noted earlier, the one thing stopping me
>> at this point is not have scala.Object on the emulator.  I certainly
>> imagine the whole Scala library will be needed, assuming you want to use
>> the libraries.
>>
>> I played around with the dx command line tool and set it up to compile
>> scala-library.jar to .dex format.  As it turns out, I got a VM
>> OutOfMemoryError because dex doesn't allocate enough memory to handle such
>> a large library.  I've already posted a message on the Android
>> Google-Group asking them to support passing arguments to the VM.  I was
>> able to successfully compile the library if I took the actor and xml
>> folders out (no specific reason, I just suspected those weren't depended
>> on by other code, and the xml folder is huge).  I haven't yet figured out
>> how to move the compiled .dex file over to the Android emulator AND have
>> an application package reference it.  
>>
>> I have a few leads, but just haven't had the time to follow through yet.
>> Primarily, I'm trying to see if there's an easy way to tweak the dx
>> command line arguments to include the .jar while compiling the user
>> activity code.  Otherwise, I've been browsing through the ADT source code
>> (the eclipse plug-in).  I noted a clearly relevant method called
>> getExternalJars() in build/BaseBuilder.java.
>>
>> Anyone else working on getting the scala-library.jar onto the emulator?
>> Any suggestions or progress?
>>
>> Tim
>>
>>
>>
>> Iulian Dragos-2 wrote:
>>> There was a bug in the Scala compiler. The ACC_SUPER flag was not
>>> generated for classfiles. This flag turns on the lookup algorithm for
>>> invoke special. More information is given here:
>>> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>>>
>>> Ingo's code works now (and the prime numbers example!) You need the svn
>>> version, or tonights nightly build.
>>>
>>> Cheers,
>>> Iulian
>>>
>>> Ingo Maier wrote:
>>>> One more thing: it works if Foo is a trait or an abstract class.
>>>>
>>>> Ingo
>>>>
>>>> Ingo Maier wrote:
>>>>> It looks like it has problems with invokespecial and super. The
>>>>> following will work:
>>>>>
>>>>> Java:
>>>>>
>>>>> public class MyActivity extends Activity
>>>>> {
>>>>>     /** Called with the activity is first created. */
>>>>>     @Override
>>>>>     public void onCreate(Bundle icicle)
>>>>>     {
>>>>>         super.onCreate(icicle);
>>>>>         new Sub().f(this);
>>>>>     }
>>>>> }
>>>>>
>>>>> Scala:
>>>>>
>>>>> class Foo {
>>>>>   def g(a: Activity) {
>>>>>     val tv = new TextView(a)
>>>>>     tv.setText("Hello Android. Cheers, Scala")
>>>>>     a.setContentView(tv)
>>>>>   }
>>>>> }
>>>>>
>>>>> class Sub extends Foo {
>>>>>   def f(a: Activity) { g(a) }
>>>>> }
>>>>>
>>>>> If I replace the call to g with an explicit super reference, i.e.,
>>>>>
>>>>> class Sub extends Foo {
>>>>>   def f(a: Activity) { super.g(a) }
>>>>> }
>>>>>
>>>>> I get a NoSuchMethodError at runtime:
>>>>>
>>>>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>>>>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>>>>> E/AndroidRuntime(545): at
>>>>> my.test.MyActivity.onCreate(MyActivity.java:14)
>>>>> E/AndroidRuntime(545): at
>>>>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>>>>
>>>>> E/AndroidRuntime(545): at
>>>>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>>>>
>>>>> E/AndroidRuntime(545): ... 11 more
>>>>>
>>>>>
>>>>> The only difference of the generated bytecode I can see from javap's
>>>>> output is a different constant pool and that it uses invokespecial
>>>>> instead of invokevirtual in f. Invokespecial is also used if I move g
>>>>> to Sub and make it private, but it works that way.
>>>>>
>>>>> Just wanted to share my results. Anyone else playing with it?
>>>>>
>>>>> Ingo
>>>>>
>>>>>
>>>>> Matt Hellige wrote:
>>>>>> On Nov 13, 2007 2:52 PM, martin odersky
>>>>>> <[e-mail]> wrote:
>>>>>>> Matt,
>>>>>>>
>>>>>>>> with my own classes. This fixed the NoClassDefFoundError, but now I
>>>>>>>> get something worse. The onCreate() method of each activity must
>>>>>>>> call
>>>>>>>> super.onCreate(). The phone checks for this and throws an exception
>>>>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,
>>>>>>>> I
>>>>>>>> get a NoClassDefFoundError.
>>>>>>> It would be good to find out more about this. Certainly, Android
>>>>>>> would
>>>>>>> be a great target for Scala programs if we could get it to work. Can
>>>>>>> you give more details about the error your encountered? Which class
>>>>>>> was not found?
>>>>>> Sorry, that was a typo. I meant to say that I get a NoSuchMethodError,
>>>>>> trying to call the superclass definition of onCreate(). (I realize
>>>>>> that that's not especially helpful.) If I have time, I will try to get
>>>>>> back to this later and find out more info. I think getting details
>>>>>> will require setting up the Android debugging environment a little
>>>>>> more carefully.
>>>>>>
>>>>>> m
>>>>>>
>>>>
>>>
>>>
>>
>

[Ingo Maier-2]

As Sean, the Scala plugin maintainer, has pointed out in the past, Java
and Scala in the same project is not a good idea. (see this thread,
e.g.,
http://www.nabble.com/Mixed-Java-Scala-Project-Organization-t3256807.html)

And indeed, on my installation, the Scala builder won't work reliably on
the Scala-Android project. Not sure if it works when I remove the Java
stuff, i.e., not depend on the xml in the res folder R.java is generated
from (scalac cannot compile Java, btw).

I think a better way would be a non-intrusive thing and put the core
Android stuff in an Android project and the Scala stuff in another
project. The Android plugin currently does not deal with project
dependencies though, only with additional jars. So, the class files from
other projects do not get compiled into the dex unless one makes a jar
from them. Im currently patching the Android plugin to include other
projects' bin folders to see if this approach is feasible.

On more thing: keep in mind that you not only need a recent scala
library but also a recent scalac.

Ingo


Timothy Bussmann wrote:

> I used both the Android and Scala plugin together on the same project.
> First, I created a new Scala project ScalaAndroid (zip of the project
> attached).  I then right clicked on it and converted it to an Android
> project.  Finally, I manually edited the project file to include a Java
> build just before the Scala build (to compile the R.java file).  Actually,
> is that even necessary?  Will the scala compiler compile java files as well?
> I also added the Java library to the project because the Scala plugin
> complained about not being able to find java.rmi.Remote.
>
> Now I'm not sure what goes on behind the scenes, but everything happens as
> you would expect.  The compiled .class files get picked up and packed into
> the .apk just like they should.
>
> When debugging (also inside Eclipse :), my activity did crash on the
> super.onCreate(icicle) call.  However, as pointed out, I was using the scala
> libraries in the lib/ folder, which actually don't include the fix.  I'll
> give the nightly build a try soon.
>
> Let me know if you still have trouble using both the Android and Scala
> plugins together to run this.
>
> Tim http://www.nabble.com/file/p13804329/ScalaAndroid.zip ScalaAndroid.zip
>
>
> Ingo Maier-2 wrote:
>> Timothy,
>>
>> Timothy Bussmann wrote:
>>> Alright, so with some more fiddling around in the Eclipse plug-in, I have
>>> managed to get to the point where the discussion I quote below is.  Right
>>> now my application (a hello world) pushes and launches successfully all
>>> within Eclipse (again, no manual command lines!).  In order to
>>> incorporate
>>> the Scala library, it actually turned out to be much simpler than I had
>>> thought.  I simply added my cut down version of the library as an
>>> external
>>> Jar to the project, and made sure it was checked in the Export tab as
>>> well.
>>> The result was 3.8 MB .apk package including the library.  I then simply
>>> ran
>>> the project like normal and the package pushed to the device and launched
>>> successfully!
>> Did you use the android and the scala plugin? How did you manage that
>> the Android plugin compiles the .class files from the bin folder of the
>> Sala project?
>>
>> With the command line tools, dx works fine for me, even with the
>> complete scala library (I just copied the .class files to the projects
>> bin for now). I get a 4.4MB .dex and a 1MB .apk (which is just a zip)
>> which uploads fine.
>>
>>> Now, I haven't tried the specific example cited below, but like others,
>>> my
>>> application crashes with a NoSuchMethodError.  I used the latest version
>>> of
>>> lib/scala-library.jar from the repository, current as of 12:10am Nov-16.
>>> I'll give the example below a try tomorrow.
>> Strange. Are you sure that your NoSuchMethodError happens at the super
>> call? You can get a stack trace with the ddms debugger. You can even
>> start it after the exception was thrown. It definitely works for me with
>> a custom build I did immediately after Iulian committed the ACC_SUPER
>> patch. Anyways, maybe you discovered another bug. Can you post your code?
>>
>> Ingo
>>
>>> I hope this can get up and running because I sure like the idea of
>>> programming in Scala for Android while everyone else has to use stinky
>>> Java
>>> :)
>>>
>>> Tim
>>>
>>>
>>> Timothy Bussmann wrote:
>>>> Hi everyone,
>>>>
>>>> I of course also immediately thought of Scala when I read over Android.
>>>> Anyway, I have the Eclipse plug-in set up and doing all the builds
>>>> nicely
>>>> (no need to play with Ant).  As noted earlier, the one thing stopping me
>>>> at this point is not have scala.Object on the emulator.  I certainly
>>>> imagine the whole Scala library will be needed, assuming you want to use
>>>> the libraries.
>>>>
>>>> I played around with the dx command line tool and set it up to compile
>>>> scala-library.jar to .dex format.  As it turns out, I got a VM
>>>> OutOfMemoryError because dex doesn't allocate enough memory to handle
>>>> such
>>>> a large library.  I've already posted a message on the Android
>>>> Google-Group asking them to support passing arguments to the VM.  I was
>>>> able to successfully compile the library if I took the actor and xml
>>>> folders out (no specific reason, I just suspected those weren't depended
>>>> on by other code, and the xml folder is huge).  I haven't yet figured
>>>> out
>>>> how to move the compiled .dex file over to the Android emulator AND have
>>>> an application package reference it.  
>>>>
>>>> I have a few leads, but just haven't had the time to follow through yet.
>>>> Primarily, I'm trying to see if there's an easy way to tweak the dx
>>>> command line arguments to include the .jar while compiling the user
>>>> activity code.  Otherwise, I've been browsing through the ADT source
>>>> code
>>>> (the eclipse plug-in).  I noted a clearly relevant method called
>>>> getExternalJars() in build/BaseBuilder.java.
>>>>
>>>> Anyone else working on getting the scala-library.jar onto the emulator?
>>>> Any suggestions or progress?
>>>>
>>>> Tim
>>>>
>>>>
>>>>
>>>> Iulian Dragos-2 wrote:
>>>>> There was a bug in the Scala compiler. The ACC_SUPER flag was not
>>>>> generated for classfiles. This flag turns on the lookup algorithm for
>>>>> invoke special. More information is given here:
>>>>> http://weblog.ikvm.net/PermaLink.aspx?guid=99fcff6c-8ab7-4358-9467-ddf71dd20acd
>>>>>
>>>>> Ingo's code works now (and the prime numbers example!) You need the svn
>>>>> version, or tonights nightly build.
>>>>>
>>>>> Cheers,
>>>>> Iulian
>>>>>
>>>>> Ingo Maier wrote:
>>>>>> One more thing: it works if Foo is a trait or an abstract class.
>>>>>>
>>>>>> Ingo
>>>>>>
>>>>>> Ingo Maier wrote:
>>>>>>> It looks like it has problems with invokespecial and super. The
>>>>>>> following will work:
>>>>>>>
>>>>>>> Java:
>>>>>>>
>>>>>>> public class MyActivity extends Activity
>>>>>>> {
>>>>>>>     /** Called with the activity is first created. */
>>>>>>>     @Override
>>>>>>>     public void onCreate(Bundle icicle)
>>>>>>>     {
>>>>>>>         super.onCreate(icicle);
>>>>>>>         new Sub().f(this);
>>>>>>>     }
>>>>>>> }
>>>>>>>
>>>>>>> Scala:
>>>>>>>
>>>>>>> class Foo {
>>>>>>>   def g(a: Activity) {
>>>>>>>     val tv = new TextView(a)
>>>>>>>     tv.setText("Hello Android. Cheers, Scala")
>>>>>>>     a.setContentView(tv)
>>>>>>>   }
>>>>>>> }
>>>>>>>
>>>>>>> class Sub extends Foo {
>>>>>>>   def f(a: Activity) { g(a) }
>>>>>>> }
>>>>>>>
>>>>>>> If I replace the call to g with an explicit super reference, i.e.,
>>>>>>>
>>>>>>> class Sub extends Foo {
>>>>>>>   def f(a: Activity) { super.g(a) }
>>>>>>> }
>>>>>>>
>>>>>>> I get a NoSuchMethodError at runtime:
>>>>>>>
>>>>>>> E/AndroidRuntime(545): Caused by: java.lang.NoSuchMethodError: g
>>>>>>> E/AndroidRuntime(545): at my.test.Sub.f(MyActivity.scala:26)
>>>>>>> E/AndroidRuntime(545): at
>>>>>>> my.test.MyActivity.onCreate(MyActivity.java:14)
>>>>>>> E/AndroidRuntime(545): at
>>>>>>> android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:786)
>>>>>>>
>>>>>>> E/AndroidRuntime(545): at
>>>>>>> android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1367)
>>>>>>>
>>>>>>> E/AndroidRuntime(545): ... 11 more
>>>>>>>
>>>>>>>
>>>>>>> The only difference of the generated bytecode I can see from javap's
>>>>>>> output is a different constant pool and that it uses invokespecial
>>>>>>> instead of invokevirtual in f. Invokespecial is also used if I move g
>>>>>>> to Sub and make it private, but it works that way.
>>>>>>>
>>>>>>> Just wanted to share my results. Anyone else playing with it?
>>>>>>>
>>>>>>> Ingo
>>>>>>>
>>>>>>>
>>>>>>> Matt Hellige wrote:
>>>>>>>> On Nov 13, 2007 2:52 PM, martin odersky
>>>>>>>> <odersky@...> wrote:
>>>>>>>>> Matt,
>>>>>>>>>
>>>>>>>>>> with my own classes. This fixed the NoClassDefFoundError, but now
>>>>>>>>>> I
>>>>>>>>>> get something worse. The onCreate() method of each activity must
>>>>>>>>>> call
>>>>>>>>>> super.onCreate(). The phone checks for this and throws an
>>>>>>>>>> exception
>>>>>>>>>> otherwise. But if I try to call super.onCreate() in my Scala code,
>>>>>>>>>> I
>>>>>>>>>> get a NoClassDefFoundError.
>>>>>>>>> It would be good to find out more about this. Certainly, Android
>>>>>>>>> would
>>>>>>>>> be a great target for Scala programs if we could get it to work.
>>>>>>>>> Can
>>>>>>>>> you give more details about the error your encountered? Which class
>>>>>>>>> was not found?
>>>>>>>> Sorry, that was a typo. I meant to say that I get a
>>>>>>>> NoSuchMethodError,
>>>>>>>> trying to call the superclass definition of onCreate(). (I realize
>>>>>>>> that that's not especially helpful.) If I have time, I will try to
>>>>>>>> get
>>>>>>>> back to this later and find out more info. I think getting details
>>>>>>>> will require setting up the Android debugging environment a little
>>>>>>>> more carefully.
>>>>>>>>
>>>>>>>> m
>>>>>>>>
>>>>>
>>
>>
>

[John Nilsson]

On Tue, 2007-11-13 at 23:12 +0000, Dave Webb wrote:

> My thinking started along similar thoughts, about alternative JVMs. Does the
> advent of Android signal a crack in the hegemony of the JVM? In a few years
> we could end up with more Java code running on Android than on Sun's JVM.
>
> Is this an opportunity for an Open Source VM, which is functional/dynamic
> friendly, and which can run old Java bytecodes translates or Scala, JRuby
> etc native?
>
> A bit off topic, but hey, it's the lounge.
>
> Dave Webb

LLVM (where Apple is putting their money) is Open Source. Someone with
more insight in compiler technology might be able to tell us if LLVM is
an interesting contender.

Regards,
John