Subject: Re: Java Integration Changes... - msg#00044

Previous Message by Date: click to view message preview

RE: Java Integration Changes...

Hello, I would second this notion. I would like to be able to work against a RubyHash or Map at my choice. More so, if there were get(), getJava(), and getJavaRecur() methods for no coercion, top-level coercion, and full recursive coercion. With that we could have as much or as little coercion of objects as the programmer desires. This would bring a best of all worlds approach to the situation. -----Original Message----- From: jruby-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:jruby-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of David Corbin Sent: Sunday, April 17, 2005 6:54 PM To: jruby-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Jruby-user] Java Integration Changes... > 2. primitive_to_java now treats Array's and Hash's as primitives > and converts them to Java List's and Map's. As well as doing this, it > call primitive_to_java on all elements in the Array or Hash. This > means a Java caller getting back '[1,2,3]' will get a Java List of > three Long's. I could not see much harm in doing this (and Robert > specifically requested this feature) and it does seem intuitive. We > only call primitive_to_java in places where we know the receiver is > going to be a java instance. In these cases, it seems very unlikely > that the consumer is expecting a RubyArray or RubyHash instance. I wonder if a better solution might be to implement java.util.List on RubyArray, and have the various "data extraction methods" do the primitive_to_java call. Not only is this more efficient, but if the java method adds data to the List, it will affect the original. The same of course can be done for Hash. David ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jruby-user mailing list Jruby-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/jruby-user ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

Next Message by Date: click to view message preview

RE: Java Integration Changes...

Hello, I don't know if you like a fully working client application of not to demonstrate need. For now I will just speak of one that could be put in place. I think the need to the conversion in a more lazy fashion by choice is good as it gives us a choice in designing our programs. We can section off our need to evaluate latent information like an unused tab. But that would not sacrifice our ability to have any summary use of those data structures. Like if I have a list of 55,000 patients, each containing about 20 elements of data, and wanted to look up five, it would be so responsive to only evaluate on those five fully or a summary of only 55,000 strings (element index 0) for the name portion. That performance would propagate through many applications needing to receive this data. -----Original Message----- From: jruby-user-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:jruby-user-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Thomas E Enebo Sent: Monday, April 18, 2005 10:20 AM To: jruby-user@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Jruby-user] Java Integration Changes... ... There is another message about being able to convert as desired (no- conversion, shallow, recursive). I think we can come up with some special interface to control how we convert, but I would like to see a demonstrated need first. I think the common default behavior should make sure a Java caller sees Java instances. Most people will want this without having to provide extra code. If you have a java caller that is expecting jruby implementation instances then I think you may be inviting trouble (like someone changing the implementation of a class you depend on in the future). -Tom -- + http://www.tc.umn.edu/~enebo +---- mailto:enebo@xxxxxxx ----+ | Thomas E Enebo, Protagonist | "A word is worth a thousand | | | pictures" -Bruce Tognazzini | ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jruby-user mailing list Jruby-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/jruby-user ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click

Previous Message by Thread: click to view message preview

Re: Java Integration Changes...

I wonder if a better solution might be to implement java.util.List on RubyArray, and have the various "data extraction methods" do the primitive_to_java call. Not only is this more efficient, but if the java method adds data to the List, it will affect the original. The same of course can be done for Hash. i guess this is indeed a very important point eitherwise the contract for that method is broken in unexpected ways. <code type="java"> public interface Foo { void setValues(List _values); List getValues(); } </code> <code type="jruby"> include_class 'Foo' class FooImpl < Foo def initialize @values = [] end def getValues @values end def setValues(_values) @values = _values end end </code> <code type="jruby" comment="using FooImpl from jruby"> foo = FooImpl.new foo.values << 1 foo.values << 2 puts foo.values # prints 12 </code> <code type="java" comment="using FooImpl from java"> Foo foo = (Foo) somehowGetFooInstFromJRuby(); foo.getValues().add(1); foo.getValues().add(2); System.out.println(foo.getValues().toString()); #should print nothing </code> besides the fact that it is considered a good practice to return copies from a getter it is rarely used in java and i thing even less used in scripting languages. it also makes porting jruby code to java more time consuming. but i wont complain to much for today. ;-) for now i am content. great work! ciao robertj David ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Jruby-user mailing list Jruby-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/jruby-user ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Next Message by Thread: click to view message preview

Re: Java Integration Changes...

hi tom, Hmmm. Yeah, the copy-by-value behavior as a result of conversion will be a source of confusion over time. People will either: a. Be confused as in the example you provided b. Complain that it is innefficient or of course both ;-) As of today, I think I can let this stand as we were totally unable to work with lists or maps from java callers at all. I will take a stab at reviving my patch which made RubyArray implement List (as a substitute for the current patch). If the get/set routines perform conversions as appropriate we should be able to work with the original RubyArray instance (and have expected by-reference behavior). I just have to remind myself what problems existed the last time I tried this. If Array works, then I will also do Hash simliarly. this would be again one more step towards an easy twoway java/jruby integration. a worthwhile goal if i may so. There is another message about being able to convert as desired (no- conversion, shallow, recursive). I think we can come up with some special interface to control how we convert, but I would like to see a demonstrated need first. I think the common default behavior should make sure a Java caller sees Java instances. Most people will want this without having to provide extra code. every additional piece of code that is required to integrate both will put possible new users off. we should aim for sensible defaults which does not mean that the other request should never be done. it could of course be possible to register some instance transformers if needs to be, but there should be a default transformer that does a sensible transformation. of course there always will be "edge cases" where it is hard to define what a sensible default is. but i am sure for 90% of all cases it will be rather smooth. If you have a java caller that is expecting jruby implementation instances then I think you may be inviting trouble (like someone changing the implementation of a class you depend on in the future). that is certainly right but if you allow for explicit transformation everbody who does this must care for its own work. one possible way why one would indeed receive rather a RubyInstances instead of its java counterpart when returning to java is that one wants to extend the jruby runtime in jruby itself. ciao robertj ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click