On Mon, 22 Mar 1999, schenck wrote:
I like the idea too but one could do the same thing using java::cast
and expr's ==. I guess the question is do people really need that
feature enough to add an extra command. The down side is
that there are more commands commands to learn. The upside is that
if {[java::compare $obj1 $obj2]} {
#do something
}
Would be a lot faster than
if {$obj1 == $obj2} {
# do something
}
in Jacl, but I think it would be slower in Tcl Blend.
Any thoughts.
later
mo
> I like the idea of having a java::compare method.
>
> Dan
>
> -----Original Message-----
> From: Moses DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 22, 1999 2:52 PM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: Tcl Blend copies return values
>
>
> 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/
>
>
> ----------------------------------------------------------------
> 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/
