On Mon, Mar 26, 2012 at 3:01 AM, Jacob Nordfalk <[email protected]> wrote: > 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 <[email protected]> >> >> 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, by default it tries to put the compiled class files in the language pair directory, but if that fails, then it falls back to the system temp directory.
> 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. Yeah, I hadn't thought of that either until it was mentioned on IRC. ^^; >> On Mon, Mar 26, 2012 at 4:24 AM, Chinmay Dabral <[email protected]> >> 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 Yeah, the reason why you only see those messages the first time is that for efficiency and compatibility, it looks in the language pair directory and the system temp directory for the compiled class files, before trying to re-compile them. This is to eliminate the delay caused by the compilation step after the first invocation, and also to allow the compiled class files to be distributed with the language pair files for systems where a JDK isn't available. > 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'. So, when you compile the runtime for Android, those class files get generated automatically? Hmm... yeah, not the most elegant of solutions. > 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. Hmm... perhaps when run as a standalone, the transfer compile could have an option for invoking the ADK to compile to Dalvik classes? I'll need to look and see how/if it's possible to programatically invoke the ADK compiler, as well as how to tell if the ADK is present. > 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 Yeah, this solution would be re-inventing the wheel somewhat, IMO, as (AFAIK) the language pairs still have to be built from source (using make) before being packaged up for mobile, and if the ADK can be invoked to compile them for mobile, that can be done during that building for packaging process. -- Stephen ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
