tcljava-user

Re: [tcljava-user] jacl 1.3.1 regexp

[Tanzer, T. <tro...@am...>]

=20
I know nothing of of WAS and sa4was, but another option is to avoid
using regexp at all to parse XML and use an XML parser. As mentioned,
the TclXML package isn't ported yet, but writing a wrapper around the
apache xml handlers is relatively simple.  I have a simple
implementation using the org.xml.sax package.  I just extend the
DefaultHandler class, and implement the methods I need to send the event
contents to a tcl procedure (very much like the tclxml API - I actually
reuse the handlers from my tclxml apps).  It doesn't look that hard to
more or less implement nearly the same API as tclxml has for SAX
parsing, but I've never needed anything beyond start/char/end events,
and I stopped there.  =20

[tcljava-user] Returning generics to TclBlend

[Tanzer, T. <tro...@am...>]

I'm not sure if this belongs here or on the developer list, but here is
my problem.  We have a library of functions written in Java, and access
the libraries using TclBlend.  When those functions return a specific
class of Java object, we can use them in the tcl scripts and call
methods on them and all works fine.  However, when those functions
return generics (we are using Java 1.5), the TclBlend shell is confused.
I can access the type of the object, but TclBlend sees it as only
java.lang.Object, and only allows Object methods on it until I cast it.


For example:

Case 1) Java method returns an object of Type1

> set oTest [$oFactory getType1]
> $oTest getElementValue ToolName
Tool42

Case 2) Java method returns a generic (in this case, a Type1 object)

> set oTest [$oFactory2 getType1]
> $oTest getElementValue ToolName
no accessible method "getElementValue" in class java.lang.Object
> puts "[$oTest getClass]"
Type1
> set oTest2 [java::cast Type1 $oTest]
> $oTest2 getElementValue ToolName
Tool42

So, I can access the class type on the Tcl side, and work around this on
the Tcl side by casting to the correct object type.  Is there anything I
could do on the Java side (outside of not using generics) that would
eliminate the need to cast the return to the correct type on the Tcl
side?

Re: [tcljava-user] Returning generics to TclBlend

[Mo D. <mo...@mo...>]

Tanzer, Troy wrote:
> I'm not sure if this belongs here or on the developer list, but here is
> my problem.  We have a library of functions written in Java, and access
> the libraries using TclBlend.  When those functions return a specific
> class of Java object, we can use them in the tcl scripts and call
> methods on them and all works fine.  However, when those functions
> return generics (we are using Java 1.5), the TclBlend shell is confused.
> I can access the type of the object, but TclBlend sees it as only
> java.lang.Object, and only allows Object methods on it until I cast it.
>
> So, I can access the class type on the Tcl side, and work around this on
> the Tcl side by casting to the correct object type.  Is there anything I
> could do on the Java side (outside of not using generics) that would
> eliminate the need to cast the return to the correct type on the Tcl
> side?
>   

Hi troy

My understanding of how Java implements generics is that the compiler 
creates compiled code
that does the upcast behind the scenes. It may be possible to implement 
this type of functionality
in TclJava, but it is not implemented now. So, doing the upcast is 
needed currently.

You may be able to work around this issue by creating a util Java method 
that returns the objects
you create already upcasted to the specific type. For example, if a 
container contained String
objects, you could create a method that would have the String return 
type. This method would
get an element out of a container and cast it to String in Java code. 
You would then invoke
this method from Tcl code and your Tcl code would not need to know 
anything about generics.

You might also want to look into a Tcl util method that would examine 
the contents of a container
and do the upcast action via java::cast for you. Another option would be 
to modify Jacl itself,
that might take a bit longer but would be better for everyone in the 
long run, assuming you
were interested in making the changes and donating them to the project. 
For example, you
might want to take a look at the new java::for command that I added to 
1.4.0, it supports
iteration over objects that support the generics API.

cheers
Mo DeJong