Ceylon + Android, blocked by Java 7

[Stephane Galles]

Hi,

I wanted to try a Ceylon "hello word" on my Android device but the
Android 'dx' tool (JVM -> Dalvik bytecode converter) can not process
Java 7 bytecode.

Do you think that the ceylon Java 7 prerequisite might be relaxed
someday and be lowered to Java 6 ?

[Gavin King]

Um, I had been under the impression that even though we require Java 7
to run the compiler, that nothing stands in the way of us producing
Java 6 compatible bytecodes. But probably Stef is the one who really
knows if that's correct or not...

> --
> You received this message because you are subscribed to the Google Groups "ceylon-users" group.
> To post to this group, send email to ceylon...@googlegroups.com.
> To unsubscribe from this group, send email to ceylon-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ceylon-users?hl=en.
>



--
Gavin King
gavin...@gmail.com
http://in.relation.to/Bloggers/Gavin
http://ceylon-lang.org
http://hibernate.org
http://seamframework.org

[Stephane Epardaud]

At the moment yes, we could. But that'd be a moot point since making
the runtime work (and fit) on Android, and especially modules might be
an issue. I recently read that application size was an issue on
Android.

Also in the future we'll likely use Java 7 bytecodes such as
InvokeDynamic so producing Java 6 bytecode is a very precarious
solution.
--
Stéphane Épardaud

[Gavin King]

On Mon, Oct 1, 2012 at 9:23 AM, Stephane Epardaud
<stephane...@gmail.com> wrote:
> At the moment yes, we could. But that'd be a moot point since making
> the runtime work (and fit) on Android, and especially modules might be
> an issue. I recently read that application size was an issue on
> Android.

OK but in fact compiled Ceylon code runs just perfectly fine without
the Ceylon runtime. The runtime is only really needed when you have
multiple versions of the same module.

> Also in the future we'll likely use Java 7 bytecodes such as
> InvokeDynamic so producing Java 6 bytecode is a very precarious
> solution.

Right, but if Java 6 compatible bytecode were a prerequisite for
Android support then we would need to have a switch to turn off the
Java 7 stuff. Android is of strategic importance to the language...

[Stephane Epardaud]

On 1 October 2012 15:26, Gavin King <gavin...@gmail.com> wrote:
> OK but in fact compiled Ceylon code runs just perfectly fine without
> the Ceylon runtime. The runtime is only really needed when you have
> multiple versions of the same module.

And to get the modules in the first place.

> Right, but if Java 6 compatible bytecode were a prerequisite for
> Android support then we would need to have a switch to turn off the
> Java 7 stuff. Android is of strategic importance to the language...

I guess we can, but I also want proof that the language and sdk
modules are not too big to make this possible. I've simply no idea.
--
Stéphane Épardaud

[Gavin King]

On Mon, Oct 1, 2012 at 10:01 AM, Stephane Epardaud
<stephane...@gmail.com> wrote:
> On 1 October 2012 15:26, Gavin King <gavin...@gmail.com> wrote:
>> OK but in fact compiled Ceylon code runs just perfectly fine without
>> the Ceylon runtime. The runtime is only really needed when you have
>> multiple versions of the same module.
>
> And to get the modules in the first place.

Well, OK, but deploying an app to android is already going to be an
explicit step, why can't you just pre-fetch the modules and when you
pass them to dex of whatever its called?

>> Right, but if Java 6 compatible bytecode were a prerequisite for
>> Android support then we would need to have a switch to turn off the
>> Java 7 stuff. Android is of strategic importance to the language...
>
> I guess we can, but I also want proof that the language and sdk
> modules are not too big to make this possible. I've simply no idea.

Well, hell, we're trying _very_ hard to not bloat out the language
module. And the SDK itself is modular...

[Stephane Epardaud]

On 1 October 2012 16:34, Gavin King <gavin...@gmail.com> wrote:
> Well, OK, but deploying an app to android is already going to be an
> explicit step, why can't you just pre-fetch the modules and when you
> pass them to dex of whatever its called?

Yes, and ideally we'd even support that whole packaging bit as part of
our standard tools, I guess. But not right now.

> Well, hell, we're trying _very_ hard to not bloat out the language
> module. And the SDK itself is modular...

We are, and it may work, and we'll do our best to make it work, but
I'd like to see numbers.

--
Stéphane Épardaud

[Nikolay Rychkov]

I propose to use something like  http://proguard.sourceforge.net/ to use exactly classes needed to run program from Ceylon SDK. So, SDK size will not be a problem.

2012/10/1 Stephane Epardaud <stephane...@gmail.com>

[Stephane Galles]

Indeed, ProGuard is even already integrated in the Android build system : http://developer.android.com/tools/help/proguard.html

Now, for all practical purposes, and as I'm by no means an Android expert, I'm currently trying to get more information about an hypothetical compatibility of 'dx' with the Java 7 bytecode in the Android-dev group :
https://groups.google.com/forum/?fromgroups=#!topic/android-developers/imBkVvTG-Hc
Information on this subject is rather sparce it seems.

[Stéphane Gallès]

Theorically Ceylon + Android should now be possible AFAICT (yes, replying to myself for this one year old question :) )

The Android team has released android studio 0.3.2 today and now it supports Java language level 7 features.
http://tools.android.com/recent/androidstudio032released

So I guess it means that the 'dx' tool now must also support JDK 7 bytecode (just speculating here, I didn't try it for now)

It looks like an interesting new playground for Ceylon

[Tako Schotanus]

Oh, that's certainly interesting news!

Now hopefully someone with time on their hands and some knowledge of Android will take this information and try it out! hehe :)

-Tako

--
You received this message because you are subscribed to the Google Groups "ceylon-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ceylon-users...@googlegroups.com.

To post to this group, send email to ceylon...@googlegroups.com.

Visit this group at http://groups.google.com/group/ceylon-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/55f831d0-dbd7-45a0-86c6-da9d9b511c64%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gavin King]

Excellent.

This is something we need to invest some time into.

On Thu, Oct 31, 2013 at 9:25 PM, Stéphane Gallès
<stephan...@gmail.com> wrote:
>

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-users...@googlegroups.com.
>
> To post to this group, send email to ceylon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ceylon-users/55f831d0-dbd7-45a0-86c6-da9d9b511c64%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Gavin King
ga...@ceylon-lang.org
http://profiles.google.com/gavin.king

[Stéphane Gallès]

Support of Java 7 bytecode in 'dx' confirmed by :
https://android-review.googlesource.com/#/c/58880/
At least that something !

[Gavin King]

So what we need to know is:

- is it easy to use Android APIs from Ceylon, or do we need some kind
of adaptors?
- how can we reasonably integrate dx into our toolchain?

On Thu, Oct 31, 2013 at 10:32 PM, Stéphane Gallès

> https://groups.google.com/d/msgid/ceylon-users/d5c3f2e9-d2cf-4e29-9d13-2f42d6c6bdd9%40googlegroups.com.

[Tako Schotanus]

On Thu, Oct 31, 2013 at 10:47 PM, Gavin King <gavin...@gmail.com> wrote:

So what we need to know is:

- is it easy to use Android APIs from Ceylon, or do we need some kind
of adaptors?

Supposedly it's as if you're programming Java, as far as I know it gets compiled normally and dx is just the final translation step.

So I'm guessing the problem from our PoV is that we must "expose" a different native environment.

So no java.base/7 (or maybe, but a more limited one) and java.swing but a different set based on Android.

And I think we can forget about using JBoss Modules and I'm almost sure we can forget about the CMR (I doubt Android's security model allows us to execute downloaded code). So that probably leaves pre-packaged assemblies that get installed manually.

 

- how can we reasonably integrate dx into our toolchain?

I don't think we'll do much integration here, it would most likely be a post-processing step, converting a bunch of modules (or assembly) into an APK. (Not saying that couldn't be built into our tools of course) 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAP7PoCcPnQRGt4pAK8-yaLN%3Dj23qR2nAYfOeV-%3DZNK8vcQ5Yqg%40mail.gmail.com.

[Gavin King]

On Fri, Nov 1, 2013 at 12:30 AM, Tako Schotanus <ta...@codejive.org> wrote:

> Supposedly it's as if you're programming Java, as far as I know it gets
> compiled normally and dx is just the final translation step.
> So I'm guessing the problem from our PoV is that we must "expose" a
> different native environment.
> So no java.base/7 (or maybe, but a more limited one) and java.swing but a
> different set based on Android.

Well android is a framework with its own APIs, and it's possible that
we would need some adaptors of some kind.

[Stéphane Gallès]

Hey ! It works !

I'm currently looking at my Android tablet that displays a "Hello world" String in a TextView widget, and this String is created by a Ceylon class.

:)

(I'll post ASAP a detailled explanation of how to setup this)

[Gavin King]

Awesome! Great news :-)

Did you have to do anything nasty or inconvenient to make it happen?

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-users...@googlegroups.com.
> To post to this group, send email to ceylon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ceylon-users/117103a9-922b-48ab-990c-e27886f5ff2b%40googlegroups.com.

>
> For more options, visit https://groups.google.com/groups/opt_out.

[Gavin King]

P.S. How would you like to be the official lead of the Elephandroid project?

[Tako Schotanus]

Wow , so cool! :)

-Tako

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/CAP7PoCe8r_DTLhLvzsm-DF7JJ3sLcceEP9%2BLZVkASOXtTASwCQ%40mail.gmail.com.

[Stéphane Gallès]

Awesome! Great news :-)

Did you have to do anything nasty or inconvenient to make it happen?

Actually it was rather straightforward, I thought that I would have to use the command line, but the IDE was enough.

The brand new official Android IDE (AndroidStudio) in now based on IntelliJ, but for obvious reason (that is, to compile the Ceylon class !) I’ve used the Eclipse Android plugin instead.

For my first attempt, I’ve tried a naive approach, but it did not work (I can’t say I was surprised). First I’ve created an Android project, and then, I’ve activated the Ceylon builder. But it seems that the result was slightly broken. It seems that the .exploded directory was not populated (I’m not sure, I’ll double check)

Second approach :
I’ve created two projects :
- A java project with the Ceylon builder activated.
- A simple Android project.

Then, In the Android project I’ve added two entries in the classpath :
- The .exploded directory of the Ceylon project
- The ceylon.language-1.0.0.car renamed as a ‘jar’ (If you keep the ‘car’ I think that it won’t work).
Do not forget to check the ‘exported’ checkbox in the classpath options, else, these entries won’t be uploaded on your Android device. Also I think that you should update the Eclipse plugin, and maybe also use the latest SDK version (that is currently 19) because I don’t know if the plugin keep several versions of the ‘dx’ tool for each SDK version (and you must use the very latest ‘dx’ in order to be able to process the Java 7 classes from the Ceylon project).

Now, you should be be able to use your Ceylon classes in the Android project (and run the project on a device).

For now, the Ceylon project do not see the Android SDK, so for instance, you can not inherit from a class of the Android SDK. I’ll try to add the Android stub jars in the Ceylon project to check if I’m able to implement an Android Activity via a Ceylon class.

But, of course, it would be great to make the first approach work, that is, to have a real hybrid Ceylon-Android project.


 

[Gavin King]

And did you go to project properties and check "Enable Java classes
calling Ceylon"?

On Sat, Nov 2, 2013 at 10:23 AM, Stéphane Gallès
<stephan...@gmail.com> wrote:

For my first attempt, I’ve tried a naive approach, but it did not work
(I can’t say I was surprised). First I’ve created an Android project,
and then, I’ve activated the Ceylon builder. But it seems that the
result was slightly broken. It seems that the .exploded directory was
not populated (I’m not sure, I’ll double check)

[Stéphane Gallès]

And did you go to project properties and check "Enable Java classes
calling Ceylon"?

Yes, indeed, this option was activated.

Actually, I’ve performed more tests, and it really seems that something does not work when both plugins are integrated (even though both the Android plugin and the Ceylon plugin are very high quality plugins, the thing is, they act on the same area of the compilation process, that why I did not really expect this to work out of the box for the very first integration).
 
When I have both a Ceylon class and a Java class in the src directory tree, this is what I get in the .exploded directory :
- I find the ‘.class’ of the Ceylon class
- I do not find the ‘.class’ of the Java class (The directories of the package are created though, but no ‘.class’ inside these directories). If I get this right I should also find the ‘.class’ of the Java class right ?
And actually the behaviour is very hectic, when I modify either the Java source or the Ceylon source, sometimes it seems that the compilation succeed. But fails when a recompilation is triggered by an other action. I have the feeling that the Android and the Ceylon builders somewhat compete here.

I’ve tried to activate/deactivates the Ceylon and Android builders but I can’t find a good explanation of what happening so far.

 

[Stéphane Gallès]

P.S. How would you like to be the official lead of the Elephandroid project?

Well, first thanks a lot you for this offer. It is very tempting.
However, to be honest, I think that I should leave this for someone else, because of two objective reasons :

1) I’m really a server-side guy and actually quite a beginner in the Android world.  I’m interested in Ceylon because I definitely want to use it server-side, and as I also wanted to learn some Android because I find the Android ecosystem and its architecture very interesting. By mixing Ceylon + Android I thought that it was a very good opportunity to learn both at the same time. Long story made short, I never had the opportunity to program at large with Android, and to lead the Elephandroid project you need someone who has a very good vision of the whole Android API, what are the paint points, what could be improved using Ceylon, what would be a specific Ceylon Android API if necessary, what are the performance problem, device constraints, and so on. That’s to say someone who has a lot of real world experience with Android.
Helas, I do not have this experience.

2) I think I wouldn’t have enough free time to devote to this task as a lead.  I would slow down the whole process.

I’m sure that there are Android Guru out there that would kill to be the lead of the Elephandroid project.
Thanks again.

 

[Gavin King]

1. Do you think it might just be a matter of the order that the
builders run in? You can actually control that by editing the .project
file.

2. Ceylon classes go into exploded/ (and of course into the .cars in
modules/), but Java classes go into classes/.

> --
> You received this message because you are subscribed to the Google Groups
> "ceylon-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ceylon-users...@googlegroups.com.
> To post to this group, send email to ceylon...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ceylon-users.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/ceylon-users/3437dce2-b68d-44f2-b255-bb215e73d7d8%40googlegroups.com.

>
> For more options, visit https://groups.google.com/groups/opt_out.

[Stéphane Gallès]

OK, the Ceylon+Android hybrid project kind’a work now.

Still, there are at least three remaining issues :

Issue A)   Problem with the ‘clean/rebuild project’ of the Ceylon plugin in a Java project

I think it is a bug in the Ceylon plugin. How to reproduce : create a plain Java project, add the Ceylon builder with Java->Ceylon calls, create a Java class that uses a created Ceylon class, then trigger a ‘clean project’ : the Ceylon class are cleaned, but are not recompiled. To force a recompilation, the source of the Ceylon class must be modified.

Now, it seems that the Android plugins triggers a lot of partial rebuild or clean (I’m just speculating here), and the consequence is that the Ceylon classes constantly disappear because of the bug in the Ceylon plugin (once again, this is my gut feeling, I can’t prove this).
Indeed Gavin, I’ve tried to modify the order of the Builders, but this does not seem to fix this problem with the ceylon .class files that are not recompiled.

Do you want me to create an issue for this ? Are you already aware of this problem ?

Issue B)   Problem with the “Ceylon Language Module” exposed as a ‘car’ in the classpath

This time, I think that the problem is in the Android plugin. In theory, the Android plugin should be able to add the “Ceylon Language Module” in the APK when the library is checked as ‘exported’ in the “Order and Export” dialog of Eclipse. Actually is does not work and it triggers “class not found exceptions” on the Android device when a Ceylon class is loaded. To make this work, I’ve found out that the module must be added as a ‘jar’ not as a ‘car’. The manual workaround is very easy, but I’ve not idea how this could be fixed to work out of the box.

Issue C)   The “exported property” of “Ceylon Project Modules” in the Eclipse dialog “Order and Export” is randomly removed

This one is nasty, I don’t know if the problem is in  Eclipse,Android plugin, or Ceylon plugin, but sometimes, when you check the “export” property of “Ceylon Project Modules” in  “Order and Export” the checkbox is unchecked when you come back to the dialog


Now, that being said, if you want to create an Hybrid Android+Ceylon project :

1) Create an Android Application Project. In the first dialog of the Wizard you must chose “Compile With: API 19: Android 4.4” (for “Minimum Required SDK” and “Target SDK” chose a value that matches your device). You must a use a recent SDK because the ‘dx’ tool version is per SDK, and you must get the version that is Java 7 enabled (SDK 18 might work, SDK 17 should not work, but I’ve not tested this)
2) Enable the Ceylon Compiler (enable “Compile for JVM” and “java class calling Ceylon”)
3) In Project Properties > Java Build Path > Order and Export  : check “export” “Ceylon Project Module”
4) In Project Properties > Java Build Path > Libraries : Add an “External Jar”, ceylon.language-1.0.0.jar (that is, the ceylon.language-1.0.0.car renamed as a jar). (this is because of problem B above). In Order and Export, check the “export” checkbox for this jar
5) Create a Ceylon class that is used by the main Activity created by the Android wizard.
6) Because of problem A, if you notice random compilation errors, just modify the source of the Ceylon class, save it, it should be recompiled.
7) Execute the project as an Android application on your device (or the emulator)
8) If you get a “classnotfound exception” for your Ceylon class on the Android device, this could be because of problem A or problem C. So check that the “Ceylon Language Module” is still exported, and check that the project still compiles, the Ceylon class may have been deleted when you launched the Android application (in this case, just modify the ceylon source to force the recompilation).

[Stéphane Gallès]

A new proof of concept test :

using Eclipse and a Ceylon+Android project I've implemented an Android activity in a Ceylon class (that's to say, my Ceylon class inherits from android.app.Activity). And I could execute this activity on my Android tablet.

Now, I've found a few more rough edges :
1) https://github.com/ceylon/ceylon-compiler/issues/1422 is almost a blocker, as the "R" android resource class can not be imported in the activity (I've hardcoded the resource numbers as a workaround)
2) In order to inherit from android.app.Activity in my Ceylon class, I had to "import-jar" the android.jar library in my local repo (even though the jar is already part of the classpath in the project, but it does not help for the import in the Ceylon classes AFAICT). But now, the "Ceylon Project Module" classpath entry includes the android.jar...and as the "Ceylon Project Module" must be "exported" in order to be deployed on the android device, the Android build process also tries to add android.jar in the APK...and to say the least in does not work. So, the workaround here is : do not export "Ceylon Project Module" and directly add the ".exploded" directory as a new exported entry in the classpath. (bottom line, the problem here is that the android.jar lib is a "provided" lib, that's to say, it already is on the device).
3) I really don't know why, but I've found '.class' files of Java classes in the '.exploded' directory (I was expecting only compiled Ceylon classes here). This has created collision problems during the build of the APK. I had to manually delete these '.class' files in order to be able to deploy the APK on my tablet (else, some Java classes were added twice in the APK).

And now I think I'm going to stop the daily spam on this thread :)

[Stéphane Gallès]

FYI, I don't know if this is even remotely interesting for you guys, but I've encountered my first case of Dalvik being very angry at the Ceylon runtime.
Related to the metamodel usage, it seems.

I had written something like :

ViewType findViewById2<ViewType>(Integer id){
        assert (is ViewType textView = findViewById(id));  
        return textView;
    }

And I got :

W/dalvikvm(20155): Unable to resolve superclass of Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager; (1356)
W/dalvikvm(20155): Link of class 'Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;' failed
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;)
E/dalvikvm(20155): Could not find class 'com.redhat.ceylon.compiler.typechecker.model.NothingType', referenced from method com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Nothing.toProducedType
W/dalvikvm(20155): VFY: unable to resolve new-instance 1386 (Lcom/redhat/ceylon/compiler/typechecker/model/NothingType;) in Lcom/redhat/ceylon/compiler/java/runtime/model/TypeDescriptor$Nothing;
D/dalvikvm(20155): VFY: replacing opcode 0x22 at 0x0000
D/dalvikvm(20155): DexOpt: unable to opt direct call 0x2959 at 0x0a in Lcom/redhat/ceylon/compiler/java/runtime/model/TypeDescriptor$Nothing;.toProducedType
W/dalvikvm(20155): Unable to resolve superclass of Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager; (1356)
W/dalvikvm(20155): Link of class 'Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;' failed
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;)
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/typechecker/model/ProducedType;)
W/dalvikvm(20155): Unable to resolve superclass of Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager; (1356)
W/dalvikvm(20155): Link of class 'Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;' failed
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;)
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/typechecker/model/ProducedType;)
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/typechecker/model/ProducedType;)
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/typechecker/model/ProducedType;)
W/dalvikvm(20155): Unable to resolve superclass of Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager; (1356)
W/dalvikvm(20155): Link of class 'Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;' failed
W/dalvikvm(20155): VFY: unable to find class referenced in signature (Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;)
W/dalvikvm(20155): Unable to resolve superclass of Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager; (1356)
W/dalvikvm(20155): Link of class 'Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;' failed
I/dalvikvm(20155): Could not find method com.redhat.ceylon.compiler.java.runtime.model.RuntimeModuleManager.findModuleForClass, referenced from method com.redhat.ceylon.compiler.java.runtime.model.TypeDescriptor$Class.toProducedType
W/dalvikvm(20155): VFY: unable to resolve virtual method 10454: Lcom/redhat/ceylon/compiler/java/runtime/model/RuntimeModuleManager;.findModuleForClass (Ljava/lang/Class;)Lcom/redhat/ceylon/compiler/typechecker/model/Module;
D/dalvikvm(20155): VFY: replacing opcode 0x6e at 0x0008
I/dalvikvm(20155): DexOpt: unable to optimize static field ref 0x0959 at 0x10 in Lcom/redhat/ceylon/compiler/java/runtime/model/TypeDescriptor$Class;.toProducedType
W/dalvikvm(20155): VFY: unable to resolve exception class 1456 (Ljava/lang/ReflectiveOperationException;)
W/dalvikvm(20155): VFY: unable to find exception handler at addr 0x58
W/dalvikvm(20155): VFY:  rejected Lcom/redhat/ceylon/compiler/java/runtime/metamodel/Metamodel;.addAnnotation (Lceylon/language/SequenceBuilder;Ljava/lang/annotation/Annotation;Lcom/redhat/ceylon/compiler/java/runtime/metamodel/Predicates$Predicate;)V
W/dalvikvm(20155): VFY:  rejecting opcode 0x0d at 0x0058
W/dalvikvm(20155): VFY:  rejected Lcom/redhat/ceylon/compiler/java/runtime/metamodel/Metamodel;.addAnnotation (Lceylon/language/SequenceBuilder;Ljava/lang/annotation/Annotation;Lcom/redhat/ceylon/compiler/java/runtime/metamodel/Predicates$Predicate;)V
W/dalvikvm(20155): Verifier rejected class Lcom/redhat/ceylon/compiler/java/runtime/metamodel/Metamodel;
D/AndroidRuntime(20155): Shutting down VM
W/dalvikvm(20155): threadid=1: thread exiting with uncaught exception (group=0x40f2b300)
E/AndroidRuntime(20155): FATAL EXCEPTION: main
E/AndroidRuntime(20155): java.lang.VerifyError: com/redhat/ceylon/compiler/java/runtime/metamodel/Metamodel
E/AndroidRuntime(20155):     at com.redhat.ceylon.compiler.java.Util.isReified(Util.java:41)
...

[Gavin King]

Looks like you don't have the typechecker jar at runtime. You need it
if you want to use the metamodel.

By the way, the only reason I have not been responding to your emails
is lack of time to read them properly.

On Wed, Nov 13, 2013 at 12:59 AM, Stéphane Gallès

> https://groups.google.com/d/msgid/ceylon-users/b7d2278d-dac3-4493-826b-dd7541fdd499%40googlegroups.com.

[Stéphane Gallès]

 
No problem Gavin, with Devoxx and the release of 1.0,  I understand that you had to focus on the on the scope of 1.0. I was not worried :)

Indeed I had to add ceylon.runtime.jar,, but also a bunch of other jars (actually I've added all 'com.redhat.ceylon.*.jar', because at least the typechecker was necessary)

And it almost worked ! with one remaining error, Dalvik threw a class not found for java.lang.ReflectiveOperationException. It took me while to understand that this problem was related to the version of Android on my tablet. Actually, java.lang.ReflectiveOperationException was added in SDK 19, that's to say Android 4.4 (aka KitKat). So much for my real tablet...

So, I've started an Android emulator with Android 4.4, and now, I get something much more interesting related to the cache creation that fails on Android. BTW I don't understand why the path of the cache is /.ceylon/cache in the stacktrace below, because it would fail on any flavour on Unix. I'll try to debug this in order to understand what's happening here. The path computation for the cache must be broken on Android I guess.

 

Exception Ljava/lang/IllegalArgumentException; thrown while initializing Lcom/redhat/ceylon/compiler/java/runtime/metamodel/Metamodel;
 Shutting down VM
 threadid=1: thread exiting with uncaught exception (group=0xb1b11b90)
 FATAL EXCEPTION: main
 Process: com.example.elephandroid, PID: 1366
 java.lang.ExceptionInInitializerError
     at com.redhat.ceylon.compiler.java.Util.isReified(Util.java:41)
     at com.example.elephandroid.Foo.findViewById2$priv$(ceylonsrc.ceylon:24)
     at com.example.elephandroid.Foo.onCreate(ceylonsrc.ceylon:14)
     at android.app.Activity.performCreate(Activity.java:5243)
     at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1087)
     at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2140)
     at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2226)
     at android.app.ActivityThread.access$700(ActivityThread.java:135)
     at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1397)
     at android.os.Handler.dispatchMessage(Handler.java:102)
     at android.os.Looper.loop(Looper.java:137)
     at android.app.ActivityThread.main(ActivityThread.java:4998)
     at java.lang.reflect.Method.invokeNative(Native Method)
     at java.lang.reflect.Method.invoke(Method.java:515)
     at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:777)
     at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:593)
     at dalvik.system.NativeStart.main(Native Method)
 Caused by: java.lang.IllegalArgumentException: java.lang.reflect.InvocationTargetException
     at com.redhat.ceylon.cmr.api.RepositoryManagerBuilder.<init>(RepositoryManagerBuilder.java:60)
     at com.redhat.ceylon.cmr.api.RepositoryManagerBuilder.<init>(RepositoryManagerBuilder.java:52)
     at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.resetModuleManager(Metamodel.java:90)
     at com.redhat.ceylon.compiler.java.runtime.metamodel.Metamodel.<clinit>(Metamodel.java:82)
     ... 17 more
 Caused by: java.lang.reflect.InvocationTargetException
     at java.lang.reflect.Constructor.constructNative(Native Method)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
     at com.redhat.ceylon.cmr.api.RepositoryManagerBuilder.<init>(RepositoryManagerBuilder.java:58)
     ... 20 more
 Caused by: java.lang.IllegalArgumentException: Cannot create Ceylon cache repository directory: /.ceylon/cache
     at com.redhat.ceylon.cmr.impl.RootRepositoryManager.<init>(RootRepositoryManager.java:56)
     at com.redhat.ceylon.cmr.impl.RootRepositoryManager.<init>(RootRepositoryManager.java:50)
     at com.redhat.ceylon.cmr.impl.RepositoryManagerBuilderImpl.<init>(RepositoryManagerBuilderImpl.java:45)
     ... 23 more

[Tako Schotanus]

> The path computation for the cache must be broken on Android I guess. 

It uses the System property "user.home", if that's not set on Android it will indeed fail.

Otherwise I don't know what could cause this.

-Tako

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/0cbf086e-cc72-40a2-8b0d-5c9068aaa879%40googlegroups.com.

[Stéphane Gallès]

OK, thanks Tako, actually I found out that this behavior is confirmed by this documentation :
http://developer.android.com/reference/java/lang/System.html
use.home : (Not useful on Android) : Empty

Actually, AFAICT, on Android the file system must be accessed with :
http://developer.android.com/reference/android/content/Context.html
Either for the external storage or the internal one.

So, is this cache the download cache for the 'car' ?
Does it even make sense for an Android device ? Even if it makes sense, I don't know if
Dalvik will accept to run the downloaded car.
And anyway, it would have to be Android specific 'car', as the 'car' from Herd would have to be transformed into Dalvik 'car'.

To put it differently, shouldn't we have an option to disable the cache behavior altogether in the Ceylon runtime ?

Stephane.

[Tako Schotanus]

Well there is an issue somewhere to disable caching, but in the mean time I'd just set the user.home property to some sensible value. If there are no remote repositories then no modules will ever get downloaded and the cache folder will never get used, but at least Ceylon will be happy.

Btw, if you only want to set/override the cache folder you can also set the system property "ceylon.cache.repo", but I'm guessing "user.home" will be used in a number of other places as well.

-Tako

To view this discussion on the web visit https://groups.google.com/d/msgid/ceylon-users/6bfe0f49-e909-4b9f-a78a-20de5f057e1a%40googlegroups.com.