xmlvm-users

[xmlvm-users] Supporting native methods + Apache Harmony Java Runtime implementation

[Gergely K. <ger...@ma...>]

Hi,

We are porting a fairly complex J2ME / Android application to IPhone using
XMLVM, and I had an idea to speed up the process. Instead of implementing
every necessary class from the Java Runtime by hand, I pulled in the Apache
Harmony runtime implementation from the Android platform and got to the
point where it compiles to Java Bytecode. Now XMLVM happily produces
cross-compiled Objective C code from it, but of course there are a number of
native methods that need to be implemented. XMLVM treats native methods
simply as abstract methods.

The idea is to change the XSL, so it generates a dummy body for the native
methods, probably throwing an UnsupportedOperationException() or something
similar.
Then for those classes that are actually used by us, we can go ahead and
implement the native methods using the nice "Categories" feature of
Objective-C, without the need to touch the generated source code.

Of course, we plan to use the hand optimized versions of those classes that
are available. For low-level classes, like threads, we plan to implement the
Thread class directly using NSThread. But there are many classes, that are
seldom used (exceptions) or are only interfaces, or simply they are not yet
available in a hand optimized version. In these cases we are able to fall
back to the cross-compiled version.

What do you think?

Would you be interested in this solution?

Best Regards,
Gergely

-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723

Re: [xmlvm-users] Supporting native methods + Apache Harmony Java Runtime implementation

[Markus H. <ma...@ti...>]

I would be interested in such a solution.

Combined with this: http://code.google.com/p/jnaerator/ we would have a full java environment with full access to all Objective/C frameworks.

Markus

Am 27.11.2009 um 02:38 schrieb Gergely Kis:

> Hi,
> 
> We are porting a fairly complex J2ME / Android application to IPhone using XMLVM, and I had an idea to speed up the process. Instead of implementing every necessary class from the Java Runtime by hand, I pulled in the Apache Harmony runtime implementation from the Android platform and got to the point where it compiles to Java Bytecode. Now XMLVM happily produces cross-compiled Objective C code from it, but of course there are a number of native methods that need to be implemented. XMLVM treats native methods simply as abstract methods.
> 
> The idea is to change the XSL, so it generates a dummy body for the native methods, probably throwing an UnsupportedOperationException() or something similar.
> Then for those classes that are actually used by us, we can go ahead and implement the native methods using the nice "Categories" feature of Objective-C, without the need to touch the generated source code.
> 
> Of course, we plan to use the hand optimized versions of those classes that are available. For low-level classes, like threads, we plan to implement the Thread class directly using NSThread. But there are many classes, that are seldom used (exceptions) or are only interfaces, or simply they are not yet available in a hand optimized version. In these cases we are able to fall back to the cross-compiled version.
> 
> What do you think?
> 
> Would you be interested in this solution?
> 
> Best Regards,
> Gergely
> 
> -- 
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma...
> Web: http://www.mattakis.com
> Phone: +36 70 408 1723
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Supporting native methods + Apache Harmony Java Runtime implementation

[Arno P. <ar...@pu...>]

Markus Heberling wrote:
> I would be interested in such a solution.
> 
> Combined with this: http://code.google.com/p/jnaerator/ we would have a 
> full java environment with full access to all Objective/C frameworks.

I looked at jnaerator a while ago. Again I'm personally a little divided 
over such an approach. The big appeal is certainly to get complete 
coverage very quickly. However, I find the jnaerator-generated Java 
binding "ugly". To be a little more specific what I mean by that: right 
now we take the (labor intensive) approach of custom-designing the Java 
API from the Objective-C counterpart. The benefit is a natural looking 
Java interface that you can still relate very easily to its original 
(which makes it easy to consult Apple's documentation). In some cases we 
have also made use of Java's strong-typedness: instead of passing an 
arbitrary selector for a delegate we have introduced strongly-typed Java 
interfaces which is much more in the spirit of the Java programming 
language.

Again there are pros and cons for either approach. Perhaps we can 
achieve the best of both worlds: first use jnaerator to generate the 
Java API and then create custom APIs for certain parts.

Anyone interested in doing a proof-of-concept with jnaerator? Ideally I 
would like to see a patch to XMLVM that integrates jnaerator and creates 
the Java API for a selected UIKit class. Any contenders?

Arno

Re: [xmlvm-users] Supporting native methods + Apache Harmony Java Runtime implementation

[Gergely K. <ger...@ma...>]

Hi,

2009/11/27 Markus Heberling <ma...@ti...>

> I would be interested in such a solution.
>
> Combined with this: http://code.google.com/p/jnaerator/ we would have a
> full java environment with full access to all Objective/C frameworks.
>
> This seems like a good idea to get high coverage of Objective-C frameworks
quickly. I don't see currently how much has to be changed in the jnaerator
code, and how will the performance compare to the manually written bindings.

Best Regards,
Gergely


-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723

Re: [xmlvm-users] Supporting native methods + Apache Harmony Java Runtime implementation

[Arno P. <ar...@pu...>]

certainly an interesting idea. I would caution against cross-compiling 
everything from Harmony. I haven't looked at their implementation but I 
would suspect that classes like String, ArrayList, HashMap are 
completely written in Java. Cross-compiling these would result in a 
severe performance penalty, that is why we currently map them (via 
categories) to their Objective-C counterparts (NSString, NSArray, 
NSDictionary). But I'm sure there are many other cases where 
cross-compiling Harmony would make a lot of sense.

Lets begin by discussing a JNI-like interface for Objective-C. That is 
something we need anyways at some point. Once we have that, we can 
discuss which parts of Harmony we cross-compile.

Anyone want to chip in with ideas regarding JNI for XMLVM?

Arno


Gergely Kis wrote:
> Hi,
> 
> We are porting a fairly complex J2ME / Android application to IPhone 
> using XMLVM, and I had an idea to speed up the process. Instead of 
> implementing every necessary class from the Java Runtime by hand, I 
> pulled in the Apache Harmony runtime implementation from the Android 
> platform and got to the point where it compiles to Java Bytecode. Now 
> XMLVM happily produces cross-compiled Objective C code from it, but of 
> course there are a number of native methods that need to be implemented. 
> XMLVM treats native methods simply as abstract methods.
> 
> The idea is to change the XSL, so it generates a dummy body for the 
> native methods, probably throwing an UnsupportedOperationException() or 
> something similar.
> Then for those classes that are actually used by us, we can go ahead and 
> implement the native methods using the nice "Categories" feature of 
> Objective-C, without the need to touch the generated source code.
> 
> Of course, we plan to use the hand optimized versions of those classes 
> that are available. For low-level classes, like threads, we plan to 
> implement the Thread class directly using NSThread. But there are many 
> classes, that are seldom used (exceptions) or are only interfaces, or 
> simply they are not yet available in a hand optimized version. In these 
> cases we are able to fall back to the cross-compiled version.
> 
> What do you think?
> 
> Would you be interested in this solution?
> 
> Best Regards,
> Gergely
> 
> -- 
> Kis Gergely
> MattaKis Consulting
> Email: ger...@ma... <mailto:ger...@ma...>
> Web: http://www.mattakis.com
> Phone: +36 70 408 1723
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xmlvm-users mailing list
> xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xmlvm-users

Re: [xmlvm-users] Supporting native methods + Apache Harmony Java Runtime implementation

[Gergely K. <ger...@ma...>]

Hi,

2009/11/27 Arno Puder <ar...@pu...>

>
> certainly an interesting idea. I would caution against cross-compiling
> everything from Harmony. I haven't looked at their implementation but I
> would suspect that classes like String, ArrayList, HashMap are completely
> written in Java. Cross-compiling these would result in a severe performance
> penalty, that is why we currently map them (via categories) to their
> Objective-C counterparts (NSString, NSArray, NSDictionary). But I'm sure
> there are many other cases where cross-compiling Harmony would make a lot of
> sense.
>
> I agree completely. In the original mail I mentioned NSThread as an
example. In fact I am planning to change the code generation process to only
include the classes from Harmony in the output that have no manually written
counterparts. Also, while as a first step I just copied all of Harmony, I
will most probably remove a large chunk of it that we don't use currently to
minimize the overhead.



> Lets begin by discussing a JNI-like interface for Objective-C. That is
> something we need anyways at some point. Once we have that, we can discuss
> which parts of Harmony we cross-compile.
>
>

> Anyone want to chip in with ideas regarding JNI for XMLVM?
>
My suggestion (as I wrote in the original mail) is to just use Objective-C
categories to write the necessary methods. A similar method is used in GWT
with JSNI. Of course there you write the Javascript code in comments inside
the Java classes, but here we have the power of ObjC and can separate the
native methods from the cross-compiled methods into separate files easily.


Best Regards,
Gergely

-- 
Kis Gergely
MattaKis Consulting
Email: ger...@ma...
Web: http://www.mattakis.com
Phone: +36 70 408 1723