On Sun, 21 Mar 1999, Christopher Hylands wrote:
> Thanks, my little test case was bogus, it did not illustrate the
> bug that I was having.
>
> It turns out that the problem was somewhat more complex.
>
> In Ptolemy II, we have a Nameable interface which is implemented
> by a NamedObj class. A NamedList is a list of NamedObjs.
> The NamedList class has a method get(), which returns
> a Nameable Object.
>
> The problem was that when I upgraded to Tcl Blend 1.1,
> I needed to use java::cast to get back my original object
>
> Here, I create a NamedList and then prepend a NamedObj
>
> % set dir [java::new ptolemy.kernel.util.NamedList]
> java0x6
> % set n1 [java::new ptolemy.kernel.util.NamedObj "n1"]
> java0x7
> % $dir prepend $n1
>
> Now, when I get from the NamedList, I get a Nameable, which
> is not exactly the same as what I passed in.
>
> % set n1New [$dir get "n1"]
> java0x8
> % java::info class $n1New
> ptolemy.kernel.util.Nameable
> % java::info class $n1
> ptolemy.kernel.util.NamedObj
Right, the problem here is that == is Tcl's expr command is not the
same as == in Java. In Tcl's expr command, == does a string compare
of the two java object names (like java0x1 and java0x2). In Java,
the == operator will compare two objects to see if they are the
exact same object (same memory location, like pointer == in C).
Most of the time you will not see any diff as == will "seem" to
work as long as the object type is the same. This difference will
only show up if you compare two objects (which might be the same)
but are typed differently.
For example.
set s [java::new String hi]
set o [java::cast Object $s]
expr {$s == $o}
This will return 0 because "java0x1" is not the same string as "java0x2".
If we add
set s2 [java::cast String $o]
expr {$s == $s2}
That would return 1.
You could of course use the java equals() method on the class which may
or may not do a pointer compare (the equals method can be defined in a
sunclass). The problem with that approach is that it may not do a
java == pointer compare. Perhaps this means we should add a new
java::compare method that just does a == in Java code and returns the
result. Any thoughts on that?
> However, if I cast the return value to Nameable, then it does work!
>
> % set n1New2 [java::cast ptolemy.kernel.util.NamedObj [$dir get "n1"]]
> java0x7
> % set n1New2 [java::cast ptolemy.kernel.util.NamedObj [$dir get "n1"]]
> java0x7
> %
>
> Under Tcl Blend 1.0, the java::cast command did not exist, and
> it was not necessary. What I got back was exactly what I passed in.
>
> A couple of hints in general:
>
> 1) One of our group members pointed out that in general, if you plan
> on using a return value, then you should set a Tcl variable
>
> Here, everytime we call getPort, we get a new Object
> % $bar getPort output
> java0x3
> % $bar getPort output
> java0x4
>
> Here, the value is saved for us.
> % set p1 [$bar getPort output]
> java0x5
> % set p2 [$bar getPort output]
> java0x5
This brings up one of the "new features" of Jacl and Tcl Blend 1.2.2.
I have added a new java::autolock method that will keep objects from
getting removed when running in an interactive session. Scripts will
still need to assign things to variables but if you just want to
"try out" a bit of code you can turn auto locking on a the java objects
will not be garbage collected.
later
mo
> It seems that under Jacl, objects that are not saved to Tcl
> variables have very short lifetimes, whereas under Tcl Blend, I've
> seen objects persist for a little while before being garbage
> collected.
>
> 2) Really, what I wanted to do here was use the Object.equals()
> method to compare the value I pushed on to the list to the
> value I pulled back off. Instead, I was just comparing
> the java0x values, which is not the right thing to do.
>
> 3) java::info class is your friend :-)
>
> -Christopher
>
>
>
> --------
>
> On Thu, 18 Mar 1999, Christopher Hylands wrote:
>
> > It looks like Tcl Blend is returning a new value everytime I do a
> > get() on a LinkedList. This is confusing because Java returns the
> > same value that I passed in to the list
> >
> > In this simple Java class, I create a LinkedList, then add a
> > GregorianCalendar to the list. When I get the GregorianCalendar
> > object back from the List, it is a pointer to the same object as
> > what I passed in.
> >
> >
> > bash-2.02$ cat T.java
> > import java.util.*;
> > public class T {
> > static void main(String v[]) {
> > LinkedList l = new LinkedList();
> > GregorianCalendar cal = new java.util.GregorianCalendar();
> > l.add(0, cal);
> > System.out.println( (cal == l.get(0)));
> > }
> > }
> > bash-2.02$ javac T.java
> > bash-2.02$ java T
> > true
> >
> >
> > In this Tcl Blend 1.1.1 version with JDK1.2 under NT4, the java0x
> > value that I get back from the list is not the same as what I passed
> > in. Note that each time I call get, I get a different java0x value.
> > I believe that Under Tcl Blend 1.0, I got the same value as what I
> > passed in.
>
> Whoops, looks like you forgot to put a $ in front of that
> variable.
>
> Good:
> $l add 0 $cal
> Bad:
> $l add 0 cal
>
> That would explain your problem as the string "cal" would
> have gotten converted to a java.lang.String object.
>
> Here is my version which seems to work just fine.
>
>
> package require java
> set l [java::new java.util.LinkedList]
> set cal [java::new java.util.GregorianCalendar]
>
> $l add 0 $cal
>
> set tmpcal [java::cast java.util.GregorianCalendar [$l -noconvert get 0]]
>
> expr {$tmpcal == $cal}
>
> # returns 1
>
> later
> mo
>
> >
> > bash-2.02$ cat /tmp/t.tcl
> > set l [java::new java.util.LinkedList]
> > set cal [java::new java.util.GregorianCalendar]
> > $l add 0 cal
> > puts "[expr { $cal == [$l -noconvert get 0]}]"
> > puts "cal = $cal"
> > puts "\[$l get 0\] = [$l -noconvert get 0]"
> > puts "\[$l get 0\] = [$l -noconvert get 0]"
> > bash-2.02$
> >
> >
> > bash-2.02$ tclsh80
> > sourcing /users/cxh/tclshrc.tcl
> > % package require java
> > 1.1.1
> > % source /tmp/t.tcl
> > 0
> > cal = java0x2
> > [java0x1 get 0] = java0x4
> > [java0x1 get 0] = java0x5
> > %
> >
> > -Christopher
> >
> > ----------------------------------------------------------------
> > The TclJava mailing list is sponsored by WebNet Technologies.
> > To subscribe: send mail to [EMAIL PROTECTED]
> > with the word SUBSCRIBE as the subject.
> > To unsubscribe: send mail to [EMAIL PROTECTED]
> > with the word UNSUBSCRIBE as the subject.
> > To send to the list, send email to '[EMAIL PROTECTED]'.
> > A list archive is at: http://www.findmail.com/listsaver/tcldallas/
> >
> --------
>
----------------------------------------------------------------
The TclJava mailing list is sponsored by WebNet Technologies.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
A list archive is at: http://www.findmail.com/listsaver/tcldallas/
