Menu
▾
▴
xmlvm-users
|
From: Sal <sv...@gm...> - 2011-01-20 16:28:29
|
Hi there, Just starting with XMLVM - I'm wondering, which is the best / most mature iphone development path now? Objective-C or the C target? Or are they fairly identical? Particularly I'm just looking for UI components and general Java support (basic inheritance, language features, maybe some reflection.) Thanks much in advance!! - Sal |
|
From: Panayotis K. <pan...@pa...> - 2011-01-20 20:06:09
|
On Jan 20, 2011, at 6:28 PM, Sal wrote: > Hi there, > > Just starting with XMLVM - I'm wondering, which is the best / most mature iphone development path now? Objective-C or the C target? Or are they fairly identical? > > Particularly I'm just looking for UI components and general Java support (basic inheritance, language features, maybe some reflection.) > > Thanks much in advance!! > > - Sal The ObjC path. It still has some issues (which probably won't be fixed), but in general is more than mature. If something is supported at all with iPhone API, it is for sure supported under ObjC. But this backend is now obsolete. The C backend, although it is the primary target right now, it is far from being as feature full as ObjC. |
|
From: Sal <sv...@gm...> - 2011-01-20 20:37:15
|
Thanks for the help - Just a few more questions: I tried to build from SVN and compile the test app: /xmlvm/src/test/iphone/org/xmlvm/test/iphone/widgets/button/UIButtonTest.java But executing on the iphone simulator seems to throw a lot of runtime errors. Am I doing anything wrong or should this work? Are there any other functional iphone UI test apps that I can try? I'm willing to fix issues and submit patches, just wanted to ping the list before I started. Also what about 'core' Java features? Like general language stuff: arrays, reflection, inheritance, etc. Is ObjC target still superior or is the C platform further ahead? And what do you recommend going forward - hack on the ObjC target or should I try to make some of the C target UI components to work? I noticed in SVN the C target has some defined iphone UI elements already. Thanks much in advance for your help!! On Thu, Jan 20, 2011 at 3:05 PM, Panayotis Katsaloulis < pan...@pa...> wrote: > > On Jan 20, 2011, at 6:28 PM, Sal wrote: > > > Hi there, > > > > Just starting with XMLVM - I'm wondering, which is the best / most mature > iphone development path now? Objective-C or the C target? Or are they > fairly identical? > > > > Particularly I'm just looking for UI components and general Java support > (basic inheritance, language features, maybe some reflection.) > > > > Thanks much in advance!! > > > > - Sal > > The ObjC path. > It still has some issues (which probably won't be fixed), but in general is > more than mature. > If something is supported at all with iPhone API, it is for sure supported > under ObjC. > But this backend is now obsolete. > > The C backend, although it is the primary target right now, it is far from > being as feature full as ObjC. > > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
|
From: Panayotis K. <pan...@pa...> - 2011-01-20 21:19:59
|
On Jan 20, 2011, at 10:37 PM, Sal wrote: > Thanks for the help - Just a few more questions: > > I tried to build from SVN and compile the test app: > > /xmlvm/src/test/iphone/org/xmlvm/test/iphone/widgets/button/UIButtonTest.java The specified application is only for internal xmlvm test. Please have a look at the demos instead. |
|
From: Tomas V. <tom...@gm...> - 2011-01-21 09:36:22
|
I've been using XMLVM for a while now and I just wanted to say that I'm very impressed. Inheritance and arrays work but I haven't used reflection. Anonymous classes works too but I'm not sure how useful that is.. I went the Obj-C path and it works very well, I've added a class and some methods that wasn't implemented and it was fairly straightforward (mostly copy-paste and looking at similar classes). I've also played a bit with plugins to see how easy it would be to use 3rd party libraries and it works well too. -- Quand on veut un mouton, c'est la preuve qu'on existe |
|
From: Panayotis K. <pan...@pa...> - 2011-01-21 11:09:51
|
On 21 Ιαν 2011, at 11:35 π.μ., Tomas Vestelind wrote: > I've been using XMLVM for a while now and I just wanted to say that I'm very impressed. Inheritance and arrays work but I haven't used reflection. Just a note: there is some serious issues with arrays and ObjC backend. A possible fix is on the way, though |
|
From: Tomas V. <tom...@gm...> - 2011-01-21 12:09:44
|
Ok, what is the issue? I mean, I've only done basic things and so far it works.. 2011/1/21 Panayotis Katsaloulis <pan...@pa...> > > On 21 Ιαν 2011, at 11:35 π.μ., Tomas Vestelind wrote: > > > I've been using XMLVM for a while now and I just wanted to say that I'm > very impressed. Inheritance and arrays work but I haven't used reflection. > > Just a note: there is some serious issues with arrays and ObjC backend. > A possible fix is on the way, though > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > -- Quand on veut un mouton, c'est la preuve qu'on existe |
|
From: Panayotis K. <pan...@pa...> - 2011-01-21 12:21:00
|
On 21 Ιαν 2011, at 2:09 μ.μ., Tomas Vestelind wrote: > Ok, what is the issue? I mean, I've only done basic things and so far it works.. The problem is in more advance usage, like the System.arraycopy or the array produced by NSData etc. For basic usage the implementation is all right. |
|
From: Tomas V. <tom...@gm...> - 2011-01-21 14:07:21
|
I see. When I say that these features work I just mean no obvious bugs when I used them. Overall I'm very impressed with how most things just work and I program like I was programming Java and not Obj-C. But, I feel like I'm not contributing so much to the discussion. I just wanted to share my experience as another XMLVM beginner. Best regards, Tomas 2011/1/21 Panayotis Katsaloulis <pan...@pa...> > > On 21 Ιαν 2011, at 2:09 μ.μ., Tomas Vestelind wrote: > > > Ok, what is the issue? I mean, I've only done basic things and so far it > works.. > > The problem is in more advance usage, like the System.arraycopy or the > array produced by NSData etc. > > For basic usage the implementation is all right. -- Quand on veut un mouton, c'est la preuve qu'on existe |
|
From: Arno P. <ar...@pu...> - 2011-01-21 16:31:13
|
what Panayotis meant to say is that the C backend is not yet ready for prime time, so we suggest you use the Objective-C backend for now. Once the C backend is the default, it will be more complete than the Objective-C counterpart. The C backend (already today) can cross-compile Apache Harmony (a J2SE implementation). The Objective-C backend cannot do this because it can't handle certain kinds of polymorphisms in Java. You can take a look at src/test/PolymorphismTest that cannot be compiled by the Objective-C backend. Then we have integrated a full Garbage Collector in the C backend. The Objective-C backend still relies on reference counting and it happens *very* quickly that your application contains a cycle in the data structure and therefore leaks memory. These are just two things where the new backend is superior. We are making good progress with the C backend. All of our internal iPhone demos almost work. Next we make the Android Compat Lib cross-compile with the C backend. Once that works, we are ready to switch to the new backend. Arno On 1/21/11 6:06 AM, Tomas Vestelind wrote: > I see. > > When I say that these features work I just mean no obvious bugs when I > used them. Overall I'm very impressed with how most things just work and > I program like I was programming Java and not Obj-C. > > But, I feel like I'm not contributing so much to the discussion. I just > wanted to share my experience as another XMLVM beginner. > > Best regards, > Tomas > > 2011/1/21 Panayotis Katsaloulis <pan...@pa... > <mailto:pan...@pa...>> > > > On 21 Ιαν 2011, at 2:09 μ.μ., Tomas Vestelind wrote: > > > Ok, what is the issue? I mean, I've only done basic things and so > far it works.. > > The problem is in more advance usage, like the System.arraycopy or > the array produced by NSData etc. > > For basic usage the implementation is all right. > > > > -- > Quand on veut un mouton, c'est la preuve qu'on existe > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > > > > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users |
|
From: Panayotis K. <pan...@pa...> - 2011-01-21 19:40:21
|
On Jan 21, 2011, at 6:31 PM, Arno Puder wrote: > he Objective-C backend still relies on > reference counting and it happens *very* quickly that your application > contains a cycle in the data structure and therefore leaks memory. These > are just two things where the new backend is superior. I have a question with the GC. There are some selectors in iOS which return an autoreleased object. This is not really the problem. The problem is if this object is released later on, for example after an animation cycle. I can't think right now of a working test example, but I'd like to hear how well the GC behaves in such mixed situations. Right now, what I do with the ObjC backend is to manually retain this object and release it when I know that I don't need it anymore. (and I think this is not a bug of ObjC, it is the way these asynchronous object manipulation works) |
|
From: Arno P. <ar...@pu...> - 2011-01-21 19:46:54
|
On 1/21/11 11:40 AM, Panayotis Katsaloulis wrote:
>
> On Jan 21, 2011, at 6:31 PM, Arno Puder wrote:
>
>> he Objective-C backend still relies on
>> reference counting and it happens *very* quickly that your application
>> contains a cycle in the data structure and therefore leaks memory. These
>> are just two things where the new backend is superior.
>
>
> I have a question with the GC.
>
> There are some selectors in iOS which return an autoreleased object. This is not really the problem.
> The problem is if this object is released later on, for example after an animation cycle.
> I can't think right now of a working test example, but I'd like to hear how well the GC behaves in such mixed situations.
As an example, here is how it is done for [UIButton buttonWithType:...]:
JAVA_OBJECT org_xmlvm_iphone_UIButton_buttonWithType___int(JAVA_INT n1)
{
if (!__TIB_org_xmlvm_iphone_UIButton.classInitialized)
__INIT_org_xmlvm_iphone_UIButton();
//XMLVM_BEGIN_WRAPPER[org_xmlvm_iphone_UIButton_buttonWithType___int]
NSAutoreleasePool* p = [[NSAutoreleasePool alloc] init];
UIButton* objcBtn = [UIButton buttonWithType: (UIButtonType) n1];
[objcBtn retain];
[p release];
JAVA_OBJECT b = __NEW_org_xmlvm_iphone_UIButton();
org_xmlvm_iphone_UIControl_INTERNAL_CONSTRUCTOR(b, objcBtn);
return b;
//XMLVM_END_WRAPPER
}
You are right: so-called convenience methods in Cocoa place the
newly-created object automatically in the autorelease pool. You can see
above that we create a temporary autorelease pool that we release again
immediately. When the GC reclaims the C version of UIButton, it will
call a finalizer (the __DELETE_* functions) that will do a 'release' in
the wrapped Objective-C UIButton.
Arno
|
|
From: Panayotis K. <pan...@pa...> - 2011-01-21 20:25:52
|
On Jan 21, 2011, at 9:46 PM, Arno Puder wrote: > > You are right: so-called convenience methods in Cocoa place the > newly-created object automatically in the autorelease pool. You can see > above that we create a temporary autorelease pool that we release again > immediately. When the GC reclaims the C version of UIButton, it will > call a finalizer (the __DELETE_* functions) that will do a 'release' in > the wrapped Objective-C UIButton. Isn't expensive to have an autorelease pool for every possible convenience selector of ObjC? (not only constructors...) Apart from that, since there *are* times that GC won't collaborate perfectly with autoreleased objects (like the situation I mentioned before with delayed animations ), is there a "backup plan" in the C backend to handle and fine tune the current memory management? (i.e. by using something like retain/release) ? |
|
From: Arno P. <ar...@pu...> - 2011-01-21 21:10:48
|
On 1/21/11 12:25 PM, Panayotis Katsaloulis wrote: > > On Jan 21, 2011, at 9:46 PM, Arno Puder wrote: > >> >> You are right: so-called convenience methods in Cocoa place the >> newly-created object automatically in the autorelease pool. You can see >> above that we create a temporary autorelease pool that we release again >> immediately. When the GC reclaims the C version of UIButton, it will >> call a finalizer (the __DELETE_* functions) that will do a 'release' in >> the wrapped Objective-C UIButton. > > Isn't expensive to have an autorelease pool for every possible convenience selector of ObjC? > (not only constructors...) Autorelease pools are expensive, yes. Please note that we already do exactly the same thing in the Objective-C backend because the reference counting algorithm used there does not know about autorelease pools. So, this is not a specific problem of the C backend, but a general problem. > Apart from that, since there *are* times that GC won't collaborate perfectly with autoreleased objects (like the situation I mentioned before with delayed animations ), is there a "backup plan" in the C backend to handle and fine tune the current memory management? (i.e. by using something like retain/release) ? I don't know about the delayed animation API, but I'm sure it can be handled. It might also be possible to be more efficient with the creation of autorelease pools, but I first want to have a working C backend before starting with optimizations. Arno |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X