xmlvm-developers Mailing List for XMLVM

Hey,

I'm working on getting XMLVM set up in Eclipse (I've been using the command line thus far) so I can submit a few patches. I installed Subclipse and checked out the project, but I'm getting 5 errors - 1 in xmlvm2c/lib/proxies/org/xml/sax/helpers and 4 in xmlvm2c/lib/proxies/org/apache/harmony/luni/lang/reflect. The first says that the method getClassLoader() is undefined for org.xml.sax.helpers.NewInstance, and the rest have to do with failures to implement abstract methods of AnnotatedElement and TypeVariable.

Any pointers on how to resolve these issues? Could it be a JDK version issue?

Thanks, Sam

Hello everybody,

if you don't check out XMLVM source code, you can stop reading now.


SourceForge is in process to upgrade all their projects to their new
platform. Today XMLVM was upgraded, which means you have to change your SVN
clients to use this URL from now on:

svn://svn.code.sf.net/p/xmlvm/code/

Cheers
// Sascha

that is some fine debugging you did there!

Please note that the patch you sent makes changes to code that was 
generated by crossmobile. For a proper fix, checkout crossmobile, edit 
file advisor.xml and look for the line <alias name ="__NSCFDictionary"/>

Underneath you should add a second alias for __NSDictionaryM. Once you 
have done that, run ant gen-xmlvm-ios in the crossmobile directory. This 
will re-generate the wrapper code.

Arno


On 3/24/13 1:33 PM, JR Schmidt wrote:
> To follow up on my own question, I resolved this.  This was tricky,
> since the debugger was of limited use as one cannot trace into native code.
>
> The crash happens in UIApplication:didFinishLaunching with options, but
> BEFORE hitting the "Java" version of this subroutine.  It actually
> happens while trying to "wrap" the NSDictionary "launchOptions"
> argument, which explains why this only occurs when launching from Mail,
> and not from the home screen.
>
> The crash is due to a "bug" (really, omission) in the WRAPPER_CREATOR of
> NSDictionary.  See patch below:
>
> --- src/xmlvm2c/lib/wrapper/org_xmlvm_ios_NSDictionary.m (revision 1)
> +++ src/xmlvm2c/lib/wrapper/org_xmlvm_ios_NSDictionary.m    (working copy)
> @@ -17,7 +17,7 @@
>
>    static JAVA_OBJECT __WRAPPER_CREATOR(NSObject* obj)
>    {
> -    if([obj class] == [NSDictionary class] || ([NSStringFromClass([obj
> class]) isEqual:@"__NSCFDictionary"]))
> +    if([obj class] == [NSDictionary class] || ([NSStringFromClass([obj
> class]) isEqual:@"__NSCFDictionary"]) || ([NSStringFromClass([obj
> class]) isEqual:@"__NSDictionaryM"]))
>        {
>            [obj retain];
>            JAVA_OBJECT jobj = __NEW_org_xmlvm_ios_NSDictionary();
>
>
> JR
>

To follow up on my own question, I resolved this.  This was tricky, 
since the debugger was of limited use as one cannot trace into native code.

The crash happens in UIApplication:didFinishLaunching with options, but 
BEFORE hitting the "Java" version of this subroutine.  It actually 
happens while trying to "wrap" the NSDictionary "launchOptions" 
argument, which explains why this only occurs when launching from Mail, 
and not from the home screen.

The crash is due to a "bug" (really, omission) in the WRAPPER_CREATOR of 
NSDictionary.  See patch below:

--- src/xmlvm2c/lib/wrapper/org_xmlvm_ios_NSDictionary.m (revision 1)
+++ src/xmlvm2c/lib/wrapper/org_xmlvm_ios_NSDictionary.m    (working copy)
@@ -17,7 +17,7 @@

  static JAVA_OBJECT __WRAPPER_CREATOR(NSObject* obj)
  {
-    if([obj class] == [NSDictionary class] || ([NSStringFromClass([obj 
class]) isEqual:@"__NSCFDictionary"]))
+    if([obj class] == [NSDictionary class] || ([NSStringFromClass([obj 
class]) isEqual:@"__NSCFDictionary"]) || ([NSStringFromClass([obj 
class]) isEqual:@"__NSDictionaryM"]))
      {
          [obj retain];
          JAVA_OBJECT jobj = __NEW_org_xmlvm_ios_NSDictionary();


JR

-- 
J.R. Schmidt
WebMO, LLC

Fax: (734) 418-1077
E-mail: sc...@we...
http://www.webmo.net

from what you've described its hard to tell where the problem is. Can 
you try to set a breakpoint and single-step until you hit the location 
where things head south?

Arno


On 3/23/13 12:26 PM, JR Schmidt wrote:
> I have ported a major Java app, quite successfully, with XMLVM thus
> far.  I am using the new-ios-api.
>
> The app runs fine when started from the iOS main screen (no launch
> options).  It is also able of responding to a  "handleURL" request to
> open a file, which also works fine SO LONG AS THE APP IS ALREADY OPEN.
>
> However, if the app is launched automatically by iOS in response to a
> request (in this case, from Mail) the app crashes.  From the debugger, I
> can see that this happens VERY EARLY on:
>
> (C) main() is called, which calls
> the (Java) main(), which calls
> UIApplication.main(), which calls
> UIApplicationMain()
>
> The app crashes immediately on UIApplcationMain() and doesn't even make
> it to didFinishLaunchingWithOptions.
>
> There is no "user" code which is even touched in this process.
> Furthermore, from the debugger, all code sequence seems identical
> whether the app was launched manually or by Mail -- but it crashes in
> the latter case and works fine in the former!
>
> The crash is an EXC_BAD_ACCESS in some spin_lock.
>
> Any thoughts on this?  Anyone seen this before?
>
> JR
>

I have ported a major Java app, quite successfully, with XMLVM thus 
far.  I am using the new-ios-api.

The app runs fine when started from the iOS main screen (no launch 
options).  It is also able of responding to a  "handleURL" request to 
open a file, which also works fine SO LONG AS THE APP IS ALREADY OPEN.

However, if the app is launched automatically by iOS in response to a 
request (in this case, from Mail) the app crashes.  From the debugger, I 
can see that this happens VERY EARLY on:

(C) main() is called, which calls
the (Java) main(), which calls
UIApplication.main(), which calls
UIApplicationMain()

The app crashes immediately on UIApplcationMain() and doesn't even make 
it to didFinishLaunchingWithOptions.

There is no "user" code which is even touched in this process. 
Furthermore, from the debugger, all code sequence seems identical 
whether the app was launched manually or by Mail -- but it crashes in 
the latter case and works fine in the former!

The crash is an EXC_BAD_ACCESS in some spin_lock.

Any thoughts on this?  Anyone seen this before?

JR

-- 
J.R. Schmidt
WebMO, LLC

Fax: (734) 418-1077
E-mail: sc...@we...
http://www.webmo.net

I wanted to mention a nice project that was funded by the Mozilla 
Foundation: cross-compile an Android app to HTML5 so that it can run in 
any browser: http://xmlvm.org/html5/

Credit goes to Victor Woeltjen for adding a Posix/SDL backend to XMLVM's 
Android Compat Lib (--target=sdlandroid) and to Alon Zakai from Mozilla 
to iron out some issues with emscripten.

Arno

On 10/15/12 7:28 AM, JR Schmidt wrote:
> It appears that object serialization relies on a few redlist-ed
> "objectaccessor" classes within Harmony.  Removing those from the
> redlist and recompiling generates some linker errors since
> (unsurprisingly) these low level classes rely on some native code. I am
> curious:  If I grab the corresponding native code from Harmony and link
> this in, is this likely to work?  Or is all the internal class data
> stored in a completely different format?

No, it won't work. XMLVM implements JNI differently so you will have to 
adapt the native implementations from Harmony. The reason we don't 
implement JNI is because XMLVM operates under a closed world assumption 
(i.e., all classes that belong to an application are known at compile 
time) that allows for better optimizations compared to the JNI API. 
After you remove classes from the red list, you should run "ant 
gen-c-native-skeletons". This will generate stubs for native methods in 
src/xmlvm2c/lib/native that you can implement.

>  Alternatively, is there ANY
> reflection support implemented in XMLVM?

We do support reflection, but that won't help you to access the native 
layer.

> Any thought on getting serialization working via a straightforward fix,
> or should I just "manually" serialize objects into a bytestream?

Well, ideally you port over Harmony's native implementation to XMLVM. 
This is a clean solution that would also benefit other XMLVMers.

Arno

It appears that object serialization relies on a few redlist-ed 
"objectaccessor" classes within Harmony.  Removing those from the 
redlist and recompiling generates some linker errors since 
(unsurprisingly) these low level classes rely on some native code. I am 
curious:  If I grab the corresponding native code from Harmony and link 
this in, is this likely to work?  Or is all the internal class data 
stored in a completely different format?  Alternatively, is there ANY 
reflection support implemented in XMLVM?

Any thought on getting serialization working via a straightforward fix, 
or should I just "manually" serialize objects into a bytestream?

Thanks for any advice,
JR

-- 
J.R. Schmidt
WebMO, LLC

Fax: (734) 418-1077
E-mail: sc...@we...
http://www.webmo.net

Hello all!

There is an issue now with the new iphone & new ios, in terms of architecture armv6

First of all, this architecture was silently obsolete under ios 5, but the compiler still produced binaries for it.
Now, with the release of ios 6/iphone 5 the architecture is completely removed.
To be precise, if someone forces the system to produce armv6 binaries, he gets the following error:

No architectures to compile for (ARCHS=armv6, VALID_ARCHS=armv7 armv7s).

Moreover, lowest supported iOS version is 4.3
(versions up to 4.2 including, have known problems)

So, what do you think about these issues and iOS project creation?

Arno,

Thank you, I understand.

 > The only way to solve this is to name-mangle the
 > return type into the generated C function names. That is a little more
 > than a weekend project.

I thought this can be done by xslt.

Kensuke

On 2012/08/08 2:01, Arno Puder wrote:
>
> this is an interesting problem. The Java language does not permit
> overloading of methods whose signature only differ in the return type.
> However, due to type erasing it can happen that on byte-code level you
> end up having two methods that only differ in their return type and the
> JVM can handle this. There has been a debate whether this should be
> permissible or not and the semantics in Java 7 have changed: In Java 7,
> the arguments need to be different *after* type erasure. Here is a nice
> writeup that explains this better than I could:
> http://notatube.blogspot.com/2010/07/interesting-change-to-method-signature.html
>
> So, wrt Java 7, XMLVM is doing the right thing, which of course doesn't
> solve the Scala issue. The only way to solve this is to name-mangle the
> return type into the generated C function names. That is a little more
> than a weekend project.
>
> Arno
>
-- 
      松崎 憲介 (MATSUZAKI Kensuke)
   URL : http://www.kitec.co.jp/

this is an interesting problem. The Java language does not permit
overloading of methods whose signature only differ in the return type.
However, due to type erasing it can happen that on byte-code level you
end up having two methods that only differ in their return type and the
JVM can handle this. There has been a debate whether this should be
permissible or not and the semantics in Java 7 have changed: In Java 7,
the arguments need to be different *after* type erasure. Here is a nice
writeup that explains this better than I could:
http://notatube.blogspot.com/2010/07/interesting-change-to-method-signature.html

So, wrt Java 7, XMLVM is doing the right thing, which of course doesn't
solve the Scala issue. The only way to solve this is to name-mangle the
return type into the generated C function names. That is a little more
than a weekend project.

Arno


On 8/6/12 11:03 PM, Kensuke Matsuzaki wrote:
> Hi,
> 
> I tried to convert scala program, but segmentation fault occurred.
> Does xmlvm2c support method overloading by return type?
> 
> A .class file has two method.
> * public int call();
> * public java.lang.Object call();
> 
> Generated callee .c source file has only "int call()",
> but caller uses "java.lang.Object call()".
> 
> * test code *
> package test {
> import java.util.concurrent.Callable;
> 
> class Hoge extends Callable[Int] {
>    def call() = 1
> }
> 
> object Test {
>    def callAndPrint(c: Callable[_]) {
>      System.out.println(c.call());
>    }
>    def main(args: Array[String]) {
>      callAndPrint(new Hoge);
>    }
> }
> }
> 
> * result of javap -c *
> Compiled from "Test.scala"
> public class test.Hoge extends java.lang.Object implements java.util.concurrent.Callable,scala.ScalaObject{
> public int call();
>    Code:
>     0:	iconst_1
>     1:	ireturn
> 
> public java.lang.Object call();
>    Code:
>     0:	aload_0
>     1:	invokevirtual	#11; //Method call:()I
>     4:	invokestatic	#17; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
>     7:	areturn
> 
> public test.Hoge();
>    Code:
>     0:	aload_0
>     1:	invokespecial	#23; //Method java/lang/Object."<init>":()V
>     4:	return
> 
> }
> 
> Compiled from "Test.scala"
> public final class test.Test$ extends java.lang.Object implements scala.ScalaObject{
> public static final test.Test$ MODULE$;
> 
> public static {};
>    Code:
>     0:	new	#9; //class test/Test$
>     3:	invokespecial	#12; //Method "<init>":()V
>     6:	return
> 
> public void callAndPrint(java.util.concurrent.Callable);
>    Code:
>     0:	getstatic	#20; //Field java/lang/System.out:Ljava/io/PrintStream;
>     3:	aload_1
>     4:	invokeinterface	#27,  1; //InterfaceMethod java/util/concurrent/Callable.call:()Ljava/lang/Object;
>     9:	invokevirtual	#33; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
>     12:	return
> 
> public void main(java.lang.String[]);
>    Code:
>     0:	aload_0
>     1:	new	#43; //class test/Hoge
>     4:	dup
>     5:	invokespecial	#44; //Method test/Hoge."<init>":()V
>     8:	invokevirtual	#46; //Method callAndPrint:(Ljava/util/concurrent/Callable;)V
>     11:	return
> 
> }
> 

Hi,

I tried to convert scala program, but segmentation fault occurred.
Does xmlvm2c support method overloading by return type?

A .class file has two method.
* public int call();
* public java.lang.Object call();

Generated callee .c source file has only "int call()",
but caller uses "java.lang.Object call()".

* test code *
package test {
import java.util.concurrent.Callable;

class Hoge extends Callable[Int] {
  def call() = 1
}

object Test {
  def callAndPrint(c: Callable[_]) {
    System.out.println(c.call());
  }
  def main(args: Array[String]) {
    callAndPrint(new Hoge);
  }
}
}

* result of javap -c *
Compiled from "Test.scala"
public class test.Hoge extends java.lang.Object implements java.util.concurrent.Callable,scala.ScalaObject{
public int call();
  Code:
   0:	iconst_1
   1:	ireturn

public java.lang.Object call();
  Code:
   0:	aload_0
   1:	invokevirtual	#11; //Method call:()I
   4:	invokestatic	#17; //Method scala/runtime/BoxesRunTime.boxToInteger:(I)Ljava/lang/Integer;
   7:	areturn

public test.Hoge();
  Code:
   0:	aload_0
   1:	invokespecial	#23; //Method java/lang/Object."<init>":()V
   4:	return

}

Compiled from "Test.scala"
public final class test.Test$ extends java.lang.Object implements scala.ScalaObject{
public static final test.Test$ MODULE$;

public static {};
  Code:
   0:	new	#9; //class test/Test$
   3:	invokespecial	#12; //Method "<init>":()V
   6:	return

public void callAndPrint(java.util.concurrent.Callable);
  Code:
   0:	getstatic	#20; //Field java/lang/System.out:Ljava/io/PrintStream;
   3:	aload_1
   4:	invokeinterface	#27,  1; //InterfaceMethod java/util/concurrent/Callable.call:()Ljava/lang/Object;
   9:	invokevirtual	#33; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V
   12:	return

public void main(java.lang.String[]);
  Code:
   0:	aload_0
   1:	new	#43; //class test/Hoge
   4:	dup
   5:	invokespecial	#44; //Method test/Hoge."<init>":()V
   8:	invokevirtual	#46; //Method callAndPrint:(Ljava/util/concurrent/Callable;)V
   11:	return

}
-- 
     松崎 憲介 (MATSUZAKI Kensuke)
  URL : http://www.kitec.co.jp/

> The fact that a class such as
> NSData has an alias (NSConcreteData) has to be added to advisor.xml.
> Look for a tag called <alias> for other examples. Once you've added
> this, run 'ant gen-xmlvm-ios'. Note that crossmobile can currently only
> parse 4.* API.

Thank you, it works.
-- 
      松崎 憲介 (MATSUZAKI Kensuke)
   URL : http://www.kitec.co.jp/

thanks for the fix. The new iOS API is handled differently. Instead of 
manually writing the Java skeletons and the C wrappers (as done in the 
old version), those files are now generated by parsing the original iOS 
Objective-C header files. This is done by a tool called crossmobile that 
you can find in xmlvm/trunk/crossmobile. In that project, look for a 
file called advisor.xml. This file contains 'hints' for the code 
generation of skeletons and wrappers. The fact that a class such as 
NSData has an alias (NSConcreteData) has to be added to advisor.xml. 
Look for a tag called <alias> for other examples. Once you've added 
this, run 'ant gen-xmlvm-ios'. Note that crossmobile can currently only 
parse 4.* API.

Arno


On 7/22/12 11:49 PM, Kensuke Matsuzaki wrote:
> NSData.dataWithBytes returns instance of NSConcreteData.
> So create_wrapping_c_object goes to infinite loop.
> Now I'm using attached workaround.
>
> Do you have any idea about this ?
>
> Thank you.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Xmlvm-developers mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-developers
>

NSData.dataWithBytes returns instance of NSConcreteData.
So create_wrapping_c_object goes to infinite loop.
Now I'm using attached workaround.

Do you have any idea about this ?

Thank you.
-- 
     松崎 憲介 (MATSUZAKI Kensuke)
  URL : http://www.kitec.co.jp/

Sorry of the following message double posts, as I sent it the first time 
from the wrong email account:

I am following up on a post in XMLVM-Users regarding improper releasing 
of CGBitmapInfoRef and other CFType objects.  Arno noted that the call 
to CFRelase in CFType.finalize() was commented out (and he wasn't sure 
why), presumably leading to such objects never being freed.

I tracked this down, and it seems to go back to a change to UIGraphics 
in Rev 2118 by ppoley, about 9 months back.  In that rev, he/she added 
an explicit call to CGContextRelease in UIGraphics.popContext(), and 
then REMOVED the corresponding call to CFRelease in CFType.finalize().

While I imagine that works well for that specific case, it seems to 
cause a more general problem in that (best I can tell) derived CFType 
objects, including CGBitmapInoRefs, etc., are never freed.

The obvious solution would be to simply uncomment the call to CFRelease 
in CFType.finalize(), but I fear that this may cause the CGContextRef in 
UIGraphics.popContext() to be double-released (probably raising an 
exception?).  Since I don't have a good understanding of why ppoley made 
this change in the first place, I am a bit apprehensive about making any 
changes.

On a related note, how does one obtain write access to SVN?  I am still 
in the beginning stages of figuring out XMLVM, so I don't anticipate 
making any major changes.  But it would be nice to be able to commit 
simple changes -- e.g. implementing a new function or two -- into the 
trunk.

JR

-- 
J.R. Schmidt
WebMO, LLC

On 6/24/12 4:31 AM, Panayotis Katsaloulis wrote:
> Dear all,
>
> I think there is a problem with some android tutorials/demos.
> I spotted two of such problems when updating the build scripts to support unicode property files.
> The problems were also in the 2290 version of the repository, before committing any changes.
>
> -- 1 --
>
> The project tutorial/android/widget fails to compile under target Xcode, while others like tutorial/android/helloworld/prog compiles (and runs) just fine.

Some time ago we began to add tutorials for both iOS and Android. For 
the Android tutorials we didn't want to constrain ourselves with 
limitations in XMLVM. For that reason several Android tutorials cannot 
be cross-compiled to iOS at the moment. Look at 
xmlvm/tutorial/doc/overview.xml and check tag <xmlvm-status> to see if 
an Android tutorial app can be cross-compiled or not.

>
> -- 2 --
>
>
> Another case is also for the project demo/android/afireworks
> Here the procedure fails with this error (which has nothing to do with the previous error):
>
> -xproject-create:
>       [echo] Creating Xcode project with the Objective C backend.
>       [java] [06/24/12 05:21:37.271]    ERROR: InputProcessFactory: Could not find input resource: /Users/teras/Works/Development/Mobile/SDK/CrossMobile/xmlvm.new/demo/android/afireworks/bin-android2iphone
>       [java] [06/24/12 05:21:37.272]    ERROR: XmlvmProcessor: No inputs to process.
>       [java] [06/24/12 05:21:37.272]    ERROR: Sub-Process for processing android iphone compat lib has failed.
>       [java] [06/24/12 05:21:37.272]    ERROR: Processing Phase 2 not successful. See error messages above for details.
>       [java] [06/24/12 05:21:37.272]    ERROR: Something went wrong during processing.
>
> Here it seems that the pipeline has changed somehow.

You may have noticed that the ACL (Android Compat Lib) has been 
refactored to differentiate between device-independent parts 
(xmlvm/src/acl/android) and device-dependent implementations 
(xmlvm/src/acl/ios and xmlvm/src/acl/wp7). We updated build.xml but I 
guess we didn't do this for the templates. Another note: I'm not sure if 
aFireworks still works with the Objective-C backend.

Arno

Dear all,

I think there is a problem with some android tutorials/demos.
I spotted two of such problems when updating the build scripts to support unicode property files.
The problems were also in the 2290 version of the repository, before committing any changes.

-- 1 --

The project tutorial/android/widget fails to compile under target Xcode, while others like tutorial/android/helloworld/prog compiles (and runs) just fine.

I don't know if these projects fully worked in the past, from the command line, or if these used to work through Eclipse, but in any case they do not work now.

Here is the error log:
[mkdir] Created dir: /Users/teras/Works/Development/Mobile/SDK/CrossMobile/xmlvm.new/tutorial/android/widgets/build/classes
    [javac] Compiling 2 source files to /Users/teras/Works/Development/Mobile/SDK/CrossMobile/xmlvm.new/tutorial/android/widgets/build/classes
    [javac] /Users/teras/Works/Development/Mobile/SDK/CrossMobile/xmlvm.new/tutorial/android/widgets/src/org/xmlvm/tutorial/android/widgets/WidgetActivity.java:28: cannot find symbol
    [javac] symbol  : class DatePicker
    [javac] location: package android.widget
    [javac] import android.widget.DatePicker;
    [javac]                      ^
    [javac] /Users/teras/Works/Development/Mobile/SDK/CrossMobile/xmlvm.new/tutorial/android/widgets/src/org/xmlvm/tutorial/android/widgets/WidgetActivity.java:30: cannot find symbol
    [javac] symbol  : class Spinner
    [javac] location: package android.widget
    [javac] import android.widget.Spinner;
    [javac]                      ^

.... 
and so on

By printing the classpath, it shows that it is using ../../../dist/xmlvm.jar  which used to be enough 



-- 2 --


Another case is also for the project demo/android/afireworks
Here the procedure fails with this error (which has nothing to do with the previous error):

-xproject-create:
     [echo] Creating Xcode project with the Objective C backend.
     [java] [06/24/12 05:21:37.271]    ERROR: InputProcessFactory: Could not find input resource: /Users/teras/Works/Development/Mobile/SDK/CrossMobile/xmlvm.new/demo/android/afireworks/bin-android2iphone
     [java] [06/24/12 05:21:37.272]    ERROR: XmlvmProcessor: No inputs to process.
     [java] [06/24/12 05:21:37.272]    ERROR: Sub-Process for processing android iphone compat lib has failed.
     [java] [06/24/12 05:21:37.272]    ERROR: Processing Phase 2 not successful. See error messages above for details.
     [java] [06/24/12 05:21:37.272]    ERROR: Something went wrong during processing.

Here it seems that the pipeline has changed somehow.

Hello all!

I've found that the current ObjC implementation of WeakReference had a serious memory management problem.
To solve this issue was not easy, but I managed to create a trick to get over it.
The solution is found in SVN commit 2181

Now, I know that the ObjC backend is practically obsolete.
The solution though is more or less  generic and has to do with deallocation of objects outside the scope of the garbage collector.
So I thought I should share this knowledge with you, in order for the C backend to be as accurate and memory consistent as the ObjC backend.

Hi Guys,
I wanted to inform you about what we've been working on for quite a while now http://www.codenameone.com/
Under the hood the iOS VM is based on XMLVM (a slightly older version which we replicated in our SVN).

We essentially take a radically different approach to WORA 
leveraging years of work we did on Blackberry, Android & J2ME 
portability to restore the idea of WORA in combination with a SaaS 
(Software as a Service) build environment simplifying the usage of 
device build toolchains. Essentially we make programming mobile devices 
easy and we are aiming for VB level ease of use... 

Thanks allot for your efforts on XMLVM and I hope you find our product useful & interesting.
Best Regards,
Shai.
Shai Almog,   
Codename One:Write Once Run Everywhere Mobile Apps.

On 08 Μαρ 2012, at 2:37 π.μ., Panayotis Katsaloulis wrote:

> Hello all!
> 
> There is a "problem" with the current launch of an iOS application.
> 
> Right now we are using selector
> applicationDidFinishLaunching:
> 
> This selector has been already "deprecated" and leads to some problems with the "openURL" mechanism.
> 
> Instead; the docs highly suggest that the application delegate should implement the selector
> application:didFinishLaunchingWithOptions:
> 
> I know that this might break the source code of all applications, but probably it is something that we should do.



Here is a proposed patch - what do you think?
http://xmlvm-reviews.appspot.com/212002

Hello all!

There is a "problem" with the current launch of an iOS application.

Right now we are using selector
applicationDidFinishLaunching:

This selector has been already "deprecated" and leads to some problems with the "openURL" mechanism.

Instead; the docs highly suggest that the application delegate should implement the selector
application:didFinishLaunchingWithOptions:

I know that this might break the source code of all applications, but probably it is something that we should do.

On 2/1/12 11:51 AM, Alexandre Almeida wrote:
> 1- To use XMLVM, do I have to start my Android Java Development from the
> beginning using your iOS Java Classes?

You can use XMLVM in one of two ways: (1) write a native iOS app in Java 
using XMLVM's Java API (in package org.xmlvm.iphone.*). (2) write a 
vanilla Android app (using only Android API) and cross-compiling this to 
iOS. (1) only targets iOS and has nothing to do with Android, but it is 
very mature and we already have a lot of API coverage. (2) only supports 
certain Android API (you can see the API XMLVM supports in 
xmlvm/src/android2iphone). If you want to cross-compile to iOS, you have 
to restrict yourself to the API that is supported by XMLVM.

Arno

On 2/1/12 11:51 AM, Alexandre Almeida wrote:
> 1- To use XMLVM, do I have to start my Android Java Development from the
> beginning using your iOS Java Classes?

You can use XMLVM in one of two ways: (1) write a native iOS app in Java 
using XMLVM's Java API (in package org.xmlvm.iphone.*). (2) write a 
vanilla Android app (using only Android API) and cross-compiling this to 
iOS. (1) only targets iOS and has nothing to do with Android, but it is 
very mature and we already have a lot of API coverage. (2) only supports 
certain Android API (you can see the API XMLVM supports in 
xmlvm/src/android2iphone). If you want to cross-compile to iOS, you have 
to restrict yourself to the API that is supported by XMLVM.

Arno