xmlvm-users

[xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[<bar...@ao...>]

 

 I think that having java_util_ArrayList.m be a category on NSMutableArray is a clever use of categories, but wouldn't encapsulation generally be a more flexible option? One potential issue I see with the category approach is that since java_util_ArrayList.m and java_util_LinkedList.m are both categories on NSMutableArray, what happens if the client java code relies on checking the kind of the list using reflection? Won't java_util_ArrayList and java_util_LinkedList then be indistinguishable from each other at runtime?

The same goes for the other classes where categories are used: String, StringBuffer, HashMap/Set, URI/URL, etc.

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

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

there are always trait-offs when you map from one platform to another. 
The efficiency of using categories comes with the downside you've described.

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


On 7/7/10 7:31 PM, bar...@ao... wrote:
>
> I think that having java_util_ArrayList.m be a category on
> NSMutableArray is a clever use of categories, but wouldn't encapsulation
> generally be a more flexible option? One potential issue I see with the
> category approach is that since java_util_ArrayList.m and
> java_util_LinkedList.m are both categories on NSMutableArray, what
> happens if the client java code relies on checking the kind of the list
> using reflection? Won't java_util_ArrayList and java_util_LinkedList
> then be indistinguishable from each other at runtime?
>
> The same goes for the other classes where categories are used: String,
> StringBuffer, HashMap/Set, URI/URL, etc.
>
>
>
> ------------------------------------------------------------------------------
> 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

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[Paul P. <bay...@gm...>]

Regarding categories & cross-compiling the original JRE classes, I am trying
to implement:

wait()
wait(long)
notify()
notifyAll()

1) If cross-compiling the original JRE, we will of course still need to
implement the native methods, including java.lang.Object's wait/notify
2) Unfortunately my implementation of wait/notify requires me to keep some
state in java_lang_Object & I cannot do so since it is a category.  Is there
a way around this in XMLVM's current state?

I believe I have everything written out, although it's a theoretical
solution right now.  However, because I need member variables, I cannot try
it out without changing java_lang_Object to inherit from NSObject rather
than be a category.  That causes other issues though.  For example, many
XMLVM objects represented as categories of objective-c objects automatically
share the benefits of java_lang_Object without explicitly saying so, as
needed.  Using inheritance for java_lang_Object instead of categories
removes this currently necessary benefit.

Does anyone have any suggestions?  If we can get that working, implementing
Thread interruptions shouldn't be very difficult building upon this.

Thanks!
Paul Poley


On Sun, Jul 11, 2010 at 6:47 AM, Arno Puder <ar...@pu...> wrote:

>
> there are always trait-offs when you map from one platform to another.
> The efficiency of using categories comes with the downside you've
> described.
>
> 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
>
>
> On 7/7/10 7:31 PM, bar...@ao... wrote:
> >
> > I think that having java_util_ArrayList.m be a category on
> > NSMutableArray is a clever use of categories, but wouldn't encapsulation
> > generally be a more flexible option? One potential issue I see with the
> > category approach is that since java_util_ArrayList.m and
> > java_util_LinkedList.m are both categories on NSMutableArray, what
> > happens if the client java code relies on checking the kind of the list
> > using reflection? Won't java_util_ArrayList and java_util_LinkedList
> > then be indistinguishable from each other at runtime?
> >
> > The same goes for the other classes where categories are used: String,
> > StringBuffer, HashMap/Set, URI/URL, etc.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[Panayotis K. <pan...@pa...>]

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

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

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

Apple recently added something called Associative References that might 
help with what you need:
http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html

Arno


On 7/12/10 7:22 AM, Paul Poley wrote:
> Regarding categories & cross-compiling the original JRE classes, I am
> trying to implement:
>
> wait()
> wait(long)
> notify()
> notifyAll()
>
> 1) If cross-compiling the original JRE, we will of course still need to
> implement the native methods, including java.lang.Object's wait/notify
> 2) Unfortunately my implementation of wait/notify requires me to keep
> some state in java_lang_Object & I cannot do so since it is a category.
>   Is there a way around this in XMLVM's current state?
>
> I believe I have everything written out, although it's a theoretical
> solution right now.  However, because I need member variables, I cannot
> try it out without changing java_lang_Object to inherit from NSObject
> rather than be a category.  That causes other issues though.  For
> example, many XMLVM objects represented as categories of objective-c
> objects automatically share the benefits of java_lang_Object without
> explicitly saying so, as needed.  Using inheritance for java_lang_Object
> instead of categories removes this currently necessary benefit.
>
> Does anyone have any suggestions?  If we can get that working,
> implementing Thread interruptions shouldn't be very difficult building
> upon this.
>
> Thanks!
> Paul Poley
>
>
> On Sun, Jul 11, 2010 at 6:47 AM, Arno Puder <ar...@pu...
> <mailto:ar...@pu...>> wrote:
>
>
>     there are always trait-offs when you map from one platform to another.
>     The efficiency of using categories comes with the downside you've
>     described.
>
>     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
>
>
>     On 7/7/10 7:31 PM, bar...@ao... <mailto:bar...@ao...> wrote:
>      >
>      > I think that having java_util_ArrayList.m be a category on
>      > NSMutableArray is a clever use of categories, but wouldn't
>     encapsulation
>      > generally be a more flexible option? One potential issue I see
>     with the
>      > category approach is that since java_util_ArrayList.m and
>      > java_util_LinkedList.m are both categories on NSMutableArray, what
>      > happens if the client java code relies on checking the kind of
>     the list
>      > using reflection? Won't java_util_ArrayList and java_util_LinkedList
>      > then be indistinguishable from each other at runtime?
>      >
>      > The same goes for the other classes where categories are used:
>     String,
>      > StringBuffer, HashMap/Set, URI/URL, etc.
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------------
>      > This SF.net email is sponsored by Sprint
>      > What will you do first with EVO, the first 4G phone?
>      > Visit sprint.com/first <http://sprint.com/first> --
>     http://p.sf.net/sfu/sprint-com-first
>      >
>      >
>      >
>      > _______________________________________________
>      > xmlvm-users mailing list
>      > xml...@li...
>     <mailto: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://sprint.com/first> --
>     http://p.sf.net/sfu/sprint-com-first
>     _______________________________________________
>     xmlvm-users mailing list
>     xml...@li...
>     <mailto:xml...@li...>
>     https://lists.sourceforge.net/lists/listinfo/xmlvm-users
>
>

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[Paul P. <bay...@gm...>]

An associative reference looks to be just what I need.  I'm assuming it
works with at least the latest version of iOS 3 & not just 4.0 & beyond.

I suppose the best solution is to lazily create the reference only when
first needed, since most objects won't need it.  That will also not create
any overhead to existing functionality.

Thanks Arno!  I'll try that.

While still somewhat on topic, I need to throw an
IllegalMonitorStateException if the current thread is not the owner of the
object's monitor.  In Java, this is native code, and I am uncertain how to
check this in Objective-C.  Googling didn't help me much either.  Does
anyone know how to check in Objective-C?

Thanks!
Paul

On Mon, Jul 12, 2010 at 3:25 AM, Arno Puder <ar...@pu...> wrote:

>
> Apple recently added something called Associative References that might
> help with what you need:
>
> http://developer.apple.com/iphone/library/documentation/cocoa/Conceptual/ObjectiveC/Articles/ocAssociativeReferences.html
>
> Arno
>
>
> On 7/12/10 7:22 AM, Paul Poley wrote:
> > Regarding categories & cross-compiling the original JRE classes, I am
> > trying to implement:
> >
> > wait()
> > wait(long)
> > notify()
> > notifyAll()
> >
> > 1) If cross-compiling the original JRE, we will of course still need to
> > implement the native methods, including java.lang.Object's wait/notify
> > 2) Unfortunately my implementation of wait/notify requires me to keep
> > some state in java_lang_Object & I cannot do so since it is a category.
> >   Is there a way around this in XMLVM's current state?
> >
> > I believe I have everything written out, although it's a theoretical
> > solution right now.  However, because I need member variables, I cannot
> > try it out without changing java_lang_Object to inherit from NSObject
> > rather than be a category.  That causes other issues though.  For
> > example, many XMLVM objects represented as categories of objective-c
> > objects automatically share the benefits of java_lang_Object without
> > explicitly saying so, as needed.  Using inheritance for java_lang_Object
> > instead of categories removes this currently necessary benefit.
> >
> > Does anyone have any suggestions?  If we can get that working,
> > implementing Thread interruptions shouldn't be very difficult building
> > upon this.
> >
> > Thanks!
> > Paul Poley
> >
> >
> > On Sun, Jul 11, 2010 at 6:47 AM, Arno Puder <ar...@pu...
> > <mailto:ar...@pu...>> wrote:
> >
> >
> >     there are always trait-offs when you map from one platform to
> another.
> >     The efficiency of using categories comes with the downside you've
> >     described.
> >
> >     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
> >
> >
> >     On 7/7/10 7:31 PM, bar...@ao... <mailto:bar...@ao...> wrote:
> >      >
> >      > I think that having java_util_ArrayList.m be a category on
> >      > NSMutableArray is a clever use of categories, but wouldn't
> >     encapsulation
> >      > generally be a more flexible option? One potential issue I see
> >     with the
> >      > category approach is that since java_util_ArrayList.m and
> >      > java_util_LinkedList.m are both categories on NSMutableArray, what
> >      > happens if the client java code relies on checking the kind of
> >     the list
> >      > using reflection? Won't java_util_ArrayList and
> java_util_LinkedList
> >      > then be indistinguishable from each other at runtime?
> >      >
> >      > The same goes for the other classes where categories are used:
> >     String,
> >      > StringBuffer, HashMap/Set, URI/URL, etc.
> >      >
> >      >
> >      >
> >      >
> >
> ------------------------------------------------------------------------------
> >      > This SF.net email is sponsored by Sprint
> >      > What will you do first with EVO, the first 4G phone?
> >      > Visit sprint.com/first <http://sprint.com/first> --
> >     http://p.sf.net/sfu/sprint-com-first
> >      >
> >      >
> >      >
> >      > _______________________________________________
> >      > xmlvm-users mailing list
> >      > xml...@li...
> >     <mailto: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://sprint.com/first> --
> >     http://p.sf.net/sfu/sprint-com-first
> >     _______________________________________________
> >     xmlvm-users mailing list
> >     xml...@li...
> >     <mailto: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
>

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[Panayotis K. <pan...@pa...>]

On 12 Ιουλ 2010, at 11:10 μ.μ., Paul Poley wrote:

> An associative reference looks to be just what I need.  I'm assuming it works with at least the latest version of iOS 3 & not just 4.0 & beyond.
> 

It requires iOS 3.1 and above - and it is not supported at the simulator.
Of course there you don't really care so much of memory leaks, as with iPhone.


> I suppose the best solution is to lazily create the reference only when first needed, since most objects won't need it.  That will also not create any overhead to existing functionality.
> 

Have in mind that this solution actually retains the object - it is not just a weak reference.

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[Paul P. <bay...@gm...>]

Thanks for the info Panayotis.  I'm disappointed to hear associative
references don't work in the simulator.
To me, that means it's not a viable option for XMLVM, since using them would
stop allowing XMLVM to operate in the simulator entirely.

I will be sending out a somewhat lengthy email later with Java source code
included discussing changes around "@synchronized" so that I can implement
wait(), wait(long), notify() & notifyAll().  Unfortunately, it requires a
solution such as associative references that is more universal.  I'll
probably have to find an alternate solution to adding member variables to
java_lang_Object.

Thanks!
Paul Poley

2010/7/12 Panayotis Katsaloulis <pan...@pa...>

>
> On 12 Ιουλ 2010, at 11:10 μ.μ., Paul Poley wrote:
>
> > An associative reference looks to be just what I need.  I'm assuming it
> works with at least the latest version of iOS 3 & not just 4.0 & beyond.
> >
>
> It requires iOS 3.1 and above - and it is not supported at the simulator.
> Of course there you don't really care so much of memory leaks, as with
> iPhone.
>
>
> > I suppose the best solution is to lazily create the reference only when
> first needed, since most objects won't need it.  That will also not create
> any overhead to existing functionality.
> >
>
> Have in mind that this solution actually retains the object - it is not
> just a weak reference.
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

[Arno P. <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!

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

Re: [xmlvm-users] Using categories vs. encapsulation in Objective-C compat-lib

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

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