Thanks for these comments.
On Jan 5, 2008 11:25 PM, Bill Dortch <
bill.dortch@...> wrote:
> This fails in your original case because the Java String is converted to a
> Ruby String when the constant is set. Ruby string values are stored as
> ByteLists (wrapping a byte array), and are divorced from the original Java
> string.
So to clarify, I'm thinking that when JRuby passes one of these
ByteLists back to java, it could call String.intern on it before
passing it. The following test passes. I suspect if we call intern()
on the ByteList copy, it would make the Swing calls succeed.
public class Main {
public static final String ORIGINAL="something";
public static void main(String[] args) {
char[] bytes = {'s','o','m','e','t','h','i','n','g'};
String copy = new String(bytes);
String interned = copy.intern();
assert(copy.equals(ORIGINAL));
assert(copy != ORIGINAL);
assert(interned == ORIGINAL);
}
}
The second case works because JavaField#static_value just wraps the
> original Java string in a JavaObject (low-level wrapper).
>
> JavaObject is likely to go away (or at least be re-purposed) post-1.1, so
> we'll need to be mindful of this use case. If we do the refactoring right,
> it should be possible to have an alternative String implementation for
> strings returned from Java that retains the original value (converting to
> ByteList only if necessary), which will make sense because in many (most?)
> cases, strings returned from Java are just going to be passed back in
> without further manipulation.
>
> -Bill
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
