Heya
With JRuby 1.5 i’ve noticed that inspect() for java objects often is the
result of toString().
So for example the output of java.io.File.new("/path/to/file") is
“/path/to/file”, where it used to be “Java::JavaIo::File:0x7087e9bf”.
This is okay for most cases, but it gets really really weird if the
toString() returns an empty string. In my case that was a new File("")
which just didn’t produce any output with 1.5’s inspect() (it returned
“”, which is even less than “”.inspect).
I’m wondering what others say about this, I don’t want to say that the
new behavior is wrong.
Bisect “blames” 
the following commit:
commit f26816a48bef76948639094e7c9e01fa0260d092
Date: Sat Oct 24 16:59:27 2009 -0500
Improvements to JavaProxy-wrapped Java objects:
* Lazily allocate the inner JavaObject, so if we don't use it we never create it.
* Don't enter newly-constructed Objects into the proxy cache immediately.
Cheers
Reto
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hi!
2010/4/16 Reto Schüttel [email protected]:
Heya
With JRuby 1.5 i’ve noticed that inspect() for java objects often is the result of toString().
So for example the output of java.io.File.new(“/path/to/file”) is “/path/to/file”, where it used to be “Java::JavaIo::File:0x7087e9bf”. This is okay for most cases, but it gets really really weird if the toString() returns an empty string. In my case that was a new File(“”) which just didn’t produce any output with 1.5’s inspect() (it returned “”, which is even less than “”.inspect).
I’m wondering what others say about this, I don’t want to say that the new behavior is wrong.
I’m looking into this a bit; not sure why that commit would have
changed how it handles inspect.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Sun, Apr 18, 2010 at 2:20 PM, Charles Oliver N.
[email protected] wrote:
changed how it handles inspect.
Ok, the reason this changed is that the default “inspect” behavior is
to use the hashy inspect format whenever there are variables attached
to the object (internal or otherwise). In 1.4 and earlier, the wrapper
in which we stuff the Java object stored it using dataWrapStruct.
dataWrapStruct was changed a while ago (a year or more?) to use a
variable rather than a field on RubyObject, so that all objects in the
system wouldn’t need to be be 32-64 bits larger just for the few cases
that use dataWrapStruct. In 1.5, to improve the performance of Java
objects passing into Ruby, we don’t use dataWrapStruct anymore, so
there’s no variables, so there’s nothing to trigger the hashy inspect.
We could easily repair this by always having Java objects’ inspect
produce the hashy inspect, since that would match the old logic. Does
that seem ok?
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
On Sun, Apr 18, 2010 at 2:47 PM, Charles Oliver N.
[email protected] wrote:
We could easily repair this by always having Java objects’ inspect
produce the hashy inspect, since that would match the old logic. Does
that seem ok?
I went ahead with it since it’s pretty innocuous. The commit is on
master in 278ea78 and on jruby-1_5 branch in 6d7f6e9.
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Hi Charlie
Am 18.04.2010 um 21:47 schrieb Charles Oliver N.:
We could easily repair this by always having Java objects’ inspect
produce the hashy inspect, since that would match the old logic. Does
that seem ok?
Just using toString() isn’t that bad, but it was really confusing to me
when it just returned an empty string in some cases. To me inspect is a
last resort, if in doubt, I’ll add a raise foo.inspect and in cruby
you’ll always get a hint what foo could be – but never nothing.
So I think the old logic is slightly better, if somebody wants a better
inspect he/she can always implement one.
Thanks for your quick help!
Reto
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
the following commit: