From: Gergely K. <ger...@ma...> - 2010-07-17 11:28:10
|
Hi, 2010/7/17 Arno Puder <ar...@pu...> > > I wanted to comment on your comment. :-) There is never the 'optimal' > solution as you have pointed out. I recently came across this Java code > that someone tried to cross-compile: > > ... = new Stack<String>() { ...override toString() }; > > This doesn't work with our way of defining a category to NSMutableArray > because this Cocoa class cannot be subclassed! > Actually, in the old patch http://xmlvm-reviews.appspot.com/18002 I had the beginnings of a solution for this, look at java_util_Vector and java_util_List and java_util_list_internal_ListProxy. The trick is to use dynamic proxies and categories: implement the List, Map, ... etc. interfaces as categories, just like we do it now. However, use a dynamic proxy to define the actual ArrayList, LinkedList ... etc. classes, which behind the scene use the NSMutable* classes. We use this solution in our own application, because we are subclassing Vector. There is one extra optimization bit that I thought of, but did not implement yet: In the proxy init method it could check whether the classname being instantiated is a standard class. if yes, then it could simply return the standard NSMutable* object instead of itself. With this optimization, in most cases the applications would still use the standard NSMutable* classes without the additional overhead of the NSProxy. Unfortunately I won't have time to submit this patch in the next few weeks, so if anyone has the time and would like to jump in, I would be very glad. Best Regards, Gergely > > Anyways, I wanted to make one more point I didn't mention in my original > reply. Apart from compiling OpenJDK we are also working on a new code > generation backend for C/C++. Eventually I would like to deprecate the > Objective-C backend for two reasons: first of all C/C++ is much more > portable across different smartphone platforms. Objective-C only works > on the iPhone, so with a C/C++ backend we can more easily target other > smartphones in the future. Note that iPhone also supports C/C++. > > Second reason: Java is a statically typed language and Objective-C is a > dynamically typed language. When cross-compiling a statically typed > language to a dynamically typed language, you cannot do very many > optimizations. Since we have this information on the Java side, it would > be possible to map many Java methods to simple C functions whose > invocation would be much more runtime efficient than a dynamic method > dispatch in Objective-C. > > Well, this is ongoing work and won't happen in quite some time. But I do > believe it is the right way to go. > > Arno > > > On 7/12/10 10:33 AM, Panayotis Katsaloulis wrote: > > > > On 11 Ιουλ 2010, at 2:47 μ.μ., Arno Puder wrote: > > > >> … > >> We are currently working on cross-compiling the original JRE classes > >> from OpenJDK. For one, it would give us instant 100% compatibility and > >> the issues you have described would also be resolved. Note that this is > >> ongoing work and will take some time to complete. > >> > >> Arno > > > > > > I have a comment on this. > > I think that even if it is useful and "quick", direct using of java > objects found in the JDK is not a good idea. > > JDK is optimized for various versions, situations and platforms, and uses > many objects from many other packages. > > Moreover most of the library is written in JAVA itself (and for a good > reason). > > > > At least for the iOS port I believe that this is not an optimum solution. > Most calls can be directly mapped to obj-c selectors and there is no need to > implement them just to keep 100% java compatibility. I believe the pathway > that was followed up to now, to map as much methods as possible and > implement anew only tiny bits, is the best approach. > > > > Panayotis > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > -- Kis Gergely MattaKis Consulting Email: ger...@ma... Web: http://www.mattakis.com Phone: +36 70 408 1723 Fax: +36 27 998 622 |