Hi,
All interested in
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code/Make_lttoolbox-java_embeddable
or
http://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code/Apertium_on_your_mobile
please
read below.
2012/3/26 Chinmay Dabral <chinmay....@gmail.com>
> Hi,
>
> Investigating further, I looked at
> org/apertium/transfer/compile/ApertiumTransferCompile.java and it looks
> like it's trying to put the class files in the language directory, but it
> can't so it puts them in /tmp.
> I moved the files from /tmp to the language directory and it worked fine
> on the desktop, but on the phone it says "can't load this type of class
> file".
>
Yes, that is correct: Android can't run java .class files directly.
They'd need to be converted to Dalwik bytecode format first.
I didn't think of that complication.
Chinmay, congratulations, you have done a very important step in the
investigation of lttoolbox-java's embedability.
>
>
> On Mon, Mar 26, 2012 at 4:24 AM, Chinmay Dabral <chinmay....@gmail.com>wrote:
>
>> Hi,
>>
>> I created an Android project and also modified the class I created to
>> output to a string. But when I run the project on the phone, it throws a
>> "FileNotFoundException: /sdcard/apertium_eo_en_eo_en_t1x.java".
>>
>> I noticed that when you run a language pair first time on the desktop, it
>> says:
>>
>> Compiling: javac -cp /usr/local/share/apertium/lttoolbox.jar
>> /tmp/apertium_en_es_en_es_t3x.java
>>
>> and similar for a few other files. It doesn't say that the next time on.
>> There are class files corresponding to that in the /tmp folder after that.
>> If I delete those files it again compiles. Is it trying to do the same
>> thing on the phone? If so, is there a way to store those compiled files
>> somewhere it can find them (after first compiling on the desktop).
>>
>>
Good work.
Yes, transfer code is actually compiled to Java bytecode and loaded runtime.
If you look at this Java files you will see that it
represent apertium_eo-en_eo-en.t1x
The easiest way to get it to run on Android would be to bundle the
compiled apertium_eo_en_eo_en_t1x.java together with lttoolbox-java in the
same Jar file.
I.e., to add it to the source code and load the class from classpath
instead of loading it from an external file.
That might also be the best long-term solution, but it is also 'ugly'.
Another solution would be to look into how to convert a java JVM .class
file into a Dalwik class file (can they exist outside .dex files?). Also
not that pretty.
A third solution would be to change transfer. Instead of making Java source
code which is compiled (requiring the Java compiler and thus that JDK is
installed on the user's machine) perhaps bytecode could be generated
directly and saved for subsequent use.
This would require use of a bytecode generator (there's a lot of them out
there, but I havent looked into this area).
The bytecode that needs to be generated is not that complicated, as can be
seen from the generated apertium_eo_en_eo_en_t1x.java. It consists of some
variables, some methods (the macros), some if-statements and method
invocations.
Please also see http://wiki.apertium.org/wiki/Bytecode_for_transfer
Jacob
--
Jacob Nordfalk <https://plus.google.com/114820443085046080944>
http://javabog.dk
Android-udvikler og underviser på
IHK<http://cv.ihk.dk/diplomuddannelser/itd/vf/MAU>og
Lund&Bendsen <https://www.lundogbendsen.dk/undervisning/beskrivelse/LB1809/>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
