tcljava-dev — discuss implementation and post patches here

Re: [tcljava-dev] Why tclblend is not stubs-aware?

[David D. <dav...@ve...>]

Hi, Georgios and Mo -
   I realize I am coming quite late to this party, but I have a request 
for each of you :

Georgios - would you be willing to post your patches to TclBlend 1.4.0 
(or .1, if you've updated them).  Like you, I find that I want to load 
TclBlend into an active TCL interpreter, but have little or no interest 
in loading TCL or TclBlend into a JVM.  If I'm in a JVM, I'll use JACL.

Mo, let me start by saying how impressed I am with the work on JACL and 
TclBlend - these are great!  My request for you would be to think about 
how there could be a version of TclBlend that can only be loaded into a 
TCL interpreter, never into a JVM.  I'd be willing to help work on this, 
since I'm the one asking.  Would it be as simple as (a) coming up with a 
third product name and (b) using Georios' patch as the build process?  
I'm suggesting having a new name and separate build process to emphasize 
that this other thing and TclBlend really are different beasts for 
different purposes.  It might even be possible to modify the source base 
so that the part that continues to be called TclBlend only loads into a JVM.
  
   I also have a question about the Tcl stubs issue.  It seems to me 
that we could solve this problem with the canonical extra level of 
indirection : the TclBlend build process creates a generic TclBlend 
shared library whose only functions are to

(a) Look up in a configuration file which specific 'real' TclBlend and 
Tcl libraries to load; and

(b) Provide the support necessary to interface the specific JVM that is 
running with the specific TclBlend that is (will be?) running.  This 
could be implemented as a whle suite of libraries supporting the various 
JVM and TclBlend interfaces, with some plumbing to connect the two.

The 'real' TclBlend library would be stubs aware, but need not know 
which JVM or TCL it is talking to.  The 'interface' libraries could be 
specifically tailored to individual combinations of JVM / TCL / 
TclBlend, but only one (or a few) would need to be built for any given user.
  
   Thanks!
  
      David

[tcljava-dev] Safe interpreter object creation ?

[Mallick C. <mal...@gm...>]

Hi
I have created safe interpreter in tcl.lang.MyClass.java  as below

Interp interp = InterpSlaveCmd.create(interpMaster,
TclString.newInstance("slave-1"),
true);  the interp object I use it further.

This works as long as the jacl.jar/tcljava.jar are loaded by same class
loader , but my requirement has changed such that my jacl/tcljava jars are
loaded by different classloader than the tcl.lang.MyClass loading. So now i
get error

java.lang.IllegalAccessError: tried to access class
tcl.lang.InterpSlaveCmdfrom class
tcl.lang.MyClass


Is there any other way to create safe interp object which I can use further
??

I will thankful for any help on this regard

Regards
Mallick

Re: [tcljava-dev] package unknown - looking for pkgIndex.tcl in the java classpath

[Christian B. <chr...@lf...>]

Hello,

any thoughts on the patch idea? Did anyone experience problems? If you 
find the idea useful, I'll be happy to send a "real" patch (diff) for 
tclPkgUnknown.

Greetings,

Christian

Christian Brensing wrote:
> Hello,
>
> I have written for a project a patch for tclPkgUnknown that allows 
> loading a jar bundled package (or any other package available in the 
> classpath) with a root pkgIndex.tcl using 'package require foo'. It's 
> implemented by looking first for root classpath resources named 
> 'pkgIndex.tcl' and sourcing them via 'source -url' (it uses the 
> commands from the java package). The patch itself is a procedure named 
> jaclPkgUnknown which delegates to the standard tclPkgUnknown found in 
> init.tcl for scanning the auto_path directories as well. You can use 
> the classpath loading by specifying this proc as the package unknown 
> script. The proc is as follows:
>
> # jaclPkgUnknown --
> #
> #   Tcl/Java specific procedure for the "package unknown" function. It is
> #   invoked when a package that's needed can't be found. It scans 
> first the
> #   current thread's ContextClassLoader looking for root resources named
> #   pkgIndex.tcl and sources any such resources that are found to 
> setup the
> #   package database. Subsequently it calls the standard unknown 
> procedure
> #   'tclPkgUnknown' which scans the auto_path directories as well.
> #
> # Arguments:
> #   name        Name of desired package. Not used.
> #   version     Version of desired package. Not used.
> #   exact       Either "-exact" or omitted. Not used.
>
> proc jaclPkgUnknown {name version {exact {}}} {
>    package require java
>      global dir
>      if {[info exists dir]} {
>        set save_dir $dir
>    }
>      # Looking for /pkgIndex.tcl via the the thread's ContextClassLoader
>    set tccl [[java::call Thread currentThread] getContextClassLoader]
>    set urls [$tccl getResources pkgIndex.tcl]
>    while {[$urls hasMoreElements]} {
>        set url [[$urls nextElement] toString]
>        if {[string first "file:" $url] == 0} {
>            # Extract the path from the file url and set dir to its parent
>            set filename [string range $url 5 [string length $url]]
>            set dir [file dirname $filename]
>        } elseif {[string first "jar:file:" $url] == 0} {
>            # Set dir to a root resource location
>            set dir "resource:/"
>        } else {
>            tclLog "can't read package index from url \"$url\": 
> protocol not supported"
>            continue
>        }
>              if [catch {source -url $url} msg] {
>            error "error reading package index file from url \"$url\": 
> $msg"
>        }
>    }
>      # Delegate to standard unknown procedure
>    tclPkgUnknown $name $version $exact
>      if {[info exists save_dir]} {
>        set dir $save_dir
>    } else {
>        unset dir
>    }
> }
>
> The proc doesn't function if the sourced pkgIndex.tcl (found in a jar 
> file) uses file globbing since dir is set to resource:/.
>
> I hope the patch will be useful.
>
> Greetings from Munich,
>
> Christian
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>   

[tcljava-dev] package unknown - looking for pkgIndex.tcl in the java classpath

[Christian B. <chr...@lf...>]

Hello,

I have written for a project a patch for tclPkgUnknown that allows 
loading a jar bundled package (or any other package available in the 
classpath) with a root pkgIndex.tcl using 'package require foo'. It's 
implemented by looking first for root classpath resources named 
'pkgIndex.tcl' and sourcing them via 'source -url' (it uses the commands 
from the java package). The patch itself is a procedure named 
jaclPkgUnknown which delegates to the standard tclPkgUnknown found in 
init.tcl for scanning the auto_path directories as well. You can use the 
classpath loading by specifying this proc as the package unknown script. 
The proc is as follows:

# jaclPkgUnknown --
#
#   Tcl/Java specific procedure for the "package unknown" function. It is
#   invoked when a package that's needed can't be found. It scans first the
#   current thread's ContextClassLoader looking for root resources named
#   pkgIndex.tcl and sources any such resources that are found to setup the
#   package database. Subsequently it calls the standard unknown procedure
#   'tclPkgUnknown' which scans the auto_path directories as well.
#
# Arguments:
#   name        Name of desired package. Not used.
#   version     Version of desired package. Not used.
#   exact       Either "-exact" or omitted. Not used.

proc jaclPkgUnknown {name version {exact {}}} {
    package require java
   
    global dir
   
    if {[info exists dir]} {
        set save_dir $dir
    }
   
    # Looking for /pkgIndex.tcl via the the thread's ContextClassLoader
    set tccl [[java::call Thread currentThread] getContextClassLoader]
    set urls [$tccl getResources pkgIndex.tcl]
    while {[$urls hasMoreElements]} {
        set url [[$urls nextElement] toString]
        if {[string first "file:" $url] == 0} {
            # Extract the path from the file url and set dir to its parent
            set filename [string range $url 5 [string length $url]]
            set dir [file dirname $filename]
        } elseif {[string first "jar:file:" $url] == 0} {
            # Set dir to a root resource location
            set dir "resource:/"
        } else {
            tclLog "can't read package index from url \"$url\": protocol 
not supported"
            continue
        }
       
        if [catch {source -url $url} msg] {
            error "error reading package index file from url \"$url\": $msg"
        }
    }
   
    # Delegate to standard unknown procedure
    tclPkgUnknown $name $version $exact
   
    if {[info exists save_dir]} {
        set dir $save_dir
    } else {
        unset dir
    }
}

The proc doesn't function if the sourced pkgIndex.tcl (found in a jar 
file) uses file globbing since dir is set to resource:/.

I hope the patch will be useful.

Greetings from Munich,

Christian

Re: [tcljava-dev] Pre-Release Jacl/Tcl Blend 1.4.1 release available for testing

[Tom P. <tpo...@ny...>]

On Thu, Sep 13, 2007 at 04:47:17PM -0700, Mo DeJong wrote:

> I want to hear from a couple
> of developers to make sure there are no gotchas in the release.

I've been using the recent CVS code for quite a while, and
did another recent build from yesterday (very latest from CVS).  
So far so good.  Jacl only, in my case.  It is the engine that 
drives my Aejaks project.

"Make it so".

-- 
Tom Poindexter
tpo...@ny...

[tcljava-dev] Pre-Release Jacl/Tcl Blend 1.4.1 release available for testing

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

Greetings

The 1.4.1 release of Jacl and Tcl Blend is almost ready. This release 
includes only bug fixes and
will represent the stable version of both Jacl and Tcl Blend going 
forward. This release includes a
pre-compiled binary version for both Jacl and Tcl Blend. The new Tcl 
Blend binary includes
pre-compiled versions of Tcl, Tk, the Thread package, Tcl Blend, and JDK 
1.4.2 rev 15.

I am going to make these files available off my website for about a 
week, so if some of you developers
could download 1 or more of these packages, test them out, and post a 
note to this list indicating your
results, that would be great. I will push these to SourceForge soon, but 
I want to hear from a couple
of developers to make sure there are no gotchas in the release.

http://www.modejong.com/tcljava/handoff/jacl1.4.1.tar.gz
http://www.modejong.com/tcljava/handoff/jacl141.zip
http://www.modejong.com/tcljava/handoff/jaclBinary141.zip

http://www.modejong.com/tcljava/handoff/tclBlend1.4.1.tar.gz
http://www.modejong.com/tcljava/handoff/tclBlend141.zip
http://www.modejong.com/tcljava/handoff/tclBlend141Binary.zip (26 megs)

thanks much
Mo DeJong

Re: [tcljava-dev] tcl interpr from eclipse plug-in

[ivan l. <iva...@gm...>]

Hello Patrick. You have asked to email you the plugin, so here is a simple
one. It's a HelloWorld template example with my (non working) lines added to
'run' method of the SampleAction class. Once again, this works in the java
application wich runs in the same workspace but does not in the plugin. I'm
sure there's a logical explanation for this behavior but I'm still new in
this and I'm obviously missing something..

Ivan Letvencuk
Novi Sad, 15.08.2007.



On 09/08/07, Patrick Finnegan <fin...@gm...> wrote:
>
>
>
> On 09/08/07, ivan letvencuk <iva...@gm...> wrote:
> >
> > Hello Patrick, thanks for interestining in my problem.. :) My English is
> > little crazy, hope you don't mind..
> >
> > I'm writing plug-in for Eclipse 3.3 in Java. The concrete problem is
> > next:
> >
> >    - I have a String that represents tcl script.
> >    - that script sets some variable with some text
> >    - and that text is input parameter for (for example)
> > org.eclipse.swt.Button.setText(text);
> >
> > I have installed Java jdk 1.6.0 and added jacl.jar and tcljava.jar into.
> >
> > As I said before, I wrote a simple example (in a simple Java project)
> > and everything worked like I expected but when I put the same portion of
> > code into plug-in (Java plug-in project) there is tcl/lang/TclException
> > too.
> >
> >
> > If you don't understand something that I wrote, let me know and I'll use
> > some other english words... :)
>
>
> Email me the plugin.
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
>

Re: [tcljava-dev] tcl interpr from eclipse plug-in

[Patrick F. <fin...@gm...>]

On 09/08/07, ivan letvencuk <iva...@gm...> wrote:
>
> Hello Patrick, thanks for interestining in my problem.. :) My English is
> little crazy, hope you don't mind..
>
> I'm writing plug-in for Eclipse 3.3 in Java. The concrete problem is next:
>
>
>    - I have a String that represents tcl script.
>    - that script sets some variable with some text
>    - and that text is input parameter for (for example)
> org.eclipse.swt.Button.setText(text);
>
> I have installed Java jdk 1.6.0 and added jacl.jar and tcljava.jar into.
>
> As I said before, I wrote a simple example (in a simple Java project) and
> everything worked like I expected but when I put the same portion of code
> into plug-in (Java plug-in project) there is tcl/lang/TclException too.
>
>
> If you don't understand something that I wrote, let me know and I'll use
> some other english words... :)


Email me the plugin.

Re: [tcljava-dev] tcl interpr from eclipse plug-in

[ivan l. <iva...@gm...>]

Hello Patrick, thanks for interestining in my problem.. :) My English is
little crazy, hope you don't mind..

I'm writing plug-in for Eclipse 3.3 in Java. The concrete problem is next:

   - I have a String that represents tcl script.
   - that script sets some variable with some text
   - and that text is input parameter for (for example)
org.eclipse.swt.Button.setText(text);

I have installed Java jdk 1.6.0 and added jacl.jar and tcljava.jar into.

As I said before, I wrote a simple example (in a simple Java project) and
everything worked like I expected but when I put the same portion of code
into plug-in (Java plug-in project) there is tcl/lang/TclException too.


If you don't understand something that I wrote, let me know and I'll use
some other english words... :)



On 09/08/07, Patrick Finnegan <fin...@gm...> wrote:
>
>
>
> On 09/08/07, ivan letvencuk <iva...@gm...> wrote:
> >
> > Hello!
> >
> > Is it possible to work with Tcl Interpr within a plugin? When I make a
> > simple java project in Eclipse that contains something like:
> >
> > Interpr i = new Interp();
> > try {
> >    interp.eval("puts hello!");
> > } catch (TclException ex) {
> >     // Handle Tcl exceptions here ...
> > }
> >
> > everything works just fine but when I try to do the same thing from my
> > plug-in, tcl/lang/TclException occurs.
> > Can anyone tell me why?
> >
> > Ivan
>
>
> Which plugin?    Java or Tcl?
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> tcljava-dev mailing list
> tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcljava-dev
>
>

Re: [tcljava-dev] tcl interpr from eclipse plug-in

[Patrick F. <fin...@gm...>]

On 09/08/07, ivan letvencuk <iva...@gm...> wrote:
>
> Hello!
>
> Is it possible to work with Tcl Interpr within a plugin? When I make a
> simple java project in Eclipse that contains something like:
>
> Interpr i = new Interp();
> try {
>    interp.eval("puts hello!");
> } catch (TclException ex) {
>     // Handle Tcl exceptions here ...
> }
>
> everything works just fine but when I try to do the same thing from my
> plug-in, tcl/lang/TclException occurs.
> Can anyone tell me why?
>
> Ivan


Which plugin?    Java or Tcl?

[tcljava-dev] tcl interpr from eclipse plug-in

[ivan l. <iva...@gm...>]

Hello!

Is it possible to work with Tcl Interpr within a plugin? When I make a
simple java project in Eclipse that contains something like:

Interpr i = new Interp();
try {
   interp.eval("puts hello!");
} catch (TclException ex) {
    // Handle Tcl exceptions here ...
}

everything works just fine but when I try to do the same thing from my
plug-in, tcl/lang/TclException occurs.
Can anyone tell me why?

Ivan

Re: [tcljava-dev] SubstCmd

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

Justin Ryan wrote:
> I'm having a problem with the subst command, in which the java version
> differs from the c version. In the C Tcl:
>
> % set str "Hello\rWorld\r"
> World
> % puts [string length $str]
> 12
> % puts [string length [subst $str] ]
> 12
>
> You can see that the \r stays in the string. While in Jacl:
>
> % set str "Hello\rWorld\r"
> World
> % puts [string length $str]
> 12
> % puts [string length [subst $str] ]
> 10
>   

Justin, thanks for reporting this bug. It has now been fixed in the CVS.

> Is there a reason that so many of the jacl/tcljava classes don't
> define themselves as public classes? If a specific class shouldn't be
> extended then it could be defined as final.
>   
The Jacl implementation assumes that end users are not going to be 
extending classes inside
the tcl.lang package.

cheers
Mo DeJong

[tcljava-dev] SubstCmd

[Justin R. <ju...@ha...>]

I'm having a problem with the subst command, in which the java version
differs from the c version. In the C Tcl:

% set str "Hello\rWorld\r"
World
% puts [string length $str]
12
% puts [string length [subst $str] ]
12

You can see that the \r stays in the string. While in Jacl:

% set str "Hello\rWorld\r"
World
% puts [string length $str]
12
% puts [string length [subst $str] ]
10

If you delve into the string, it's missing the \r characters on Jacl.
There's an explicit line in SubstCmd.java that excludes this
character.  The comment nearby says that it might not be compatible on
a Mac. I can't say either way if it incompatible with the Mac, but I
can say for sure that it's incompatible with Tcl. Does anyone know why
this bit was added? Can it be removed?

I use subst for variable substitution on string passed into me, and I
can't have it missing characters.  My work around was to rewrite the
subst command, but since SubstCmd has package private privileges, I
couldn't just extend it. I had to copy and paste from SubstCmd.java.
Is there a reason that so many of the jacl/tcljava classes don't
define themselves as public classes? If a specific class shouldn't be
extended then it could be defined as final.

justin

Re: [tcljava-dev] Building tclblend 1.4.0 under windows with mingw...

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

Georgios Petasis wrote:
> I have the impression that the included libjvm.dll.a didn't work in my 
> case (mingw - ActiveTcl), and I created
> my own. This is why I wanted to know how the file in the original 
> distribution was built (and if the procedure
> I followed to re-create it was wrong :-))

See:

http://www.inonit.com/cygwin/jni/invocationApi/archive.html

>>  You will likely
>> run into issues trying to run a tclblend.dll with the Active State 
>> binary as this is not a supported
>> configuration. The tclblend.dll you build needs to be run with the Tcl 
>> release it was compiled against.
>>   
> If I only stick into creating a JVM from Tcl (and never do the 
> opposite - load Tcl from Java)
> will I still have problems? ( I am using a tclblend version that uses 
> stubs :-) with ActiveTcl/JDK 5)
It does not matter. What you need to do is load the Tcl Blend dll into 
the version of Tcl that it was compiled
agains. Otherwise, you may run into issues. The Tcl Blend configure 
script checks for these kinds of problems
to keep you from making mistakes. If the ActiveTcl binary is compiled 
without threads, then you
will run into crashes sooner or later. Mixing and matching binaries with 
Tcl Blend is not a good idea, you
should use Tcl Blend with the version of Tcl it was compiled for.

Mo

Re: [tcljava-dev] Why tclblend is not stubs-aware?

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

Georgios Petasis wrote:
>>   
> I see. I am using tclblend for only loading Java from Tcl, and this is 
> why I never noticed any problems
> with the stubs-enabled version. I never cross my mind that tclblend 
> can be used to load Tcl from
> Java. How is this accomplished in Java? You somehow load the tclblend 
> dll and a Tcl interp
> gets also created?
You write a Java file that imports tcl.lang and creates an Interp. Java 
will load the Interp class and that will
load tclblend.dll and also tcl84.dll in the init code for the Interp 
class. You just need to make sure
the CLASSPATH and the PATH are setup correctly and it will just work.

Mo DeJong

Re: [tcljava-dev] Please help in loading a class...

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

Georgios Petasis wrote:
> I am using the Sun JDK. I think that it is more an "access" problem 
> (i.e. restriction due to private members), than
> the fact that the class it is not found due to the classpath.
Yes, this message indicates that the access permissions on the class 
don't allow it to be used. The class or method
needs to be public.

Mo

Re: [tcljava-dev] Please help in loading a class...

[Georgios P. <pet...@ya...>]

I am using the Sun JDK. I think that it is more an "access" problem 
(i.e. restriction due to private members), than
the fact that the class it is not found due to the classpath. In my 
classpath, I have put all used JAR files that are specific
to the application, but no path that relates to the JVM. I am using the 
same path as when I run the app from the command
line. From the command line it runs. From tclblend I cannot start it :-(

The intresting think is that I can run classes from the application that 
get called from the class that starts the app, but not the
class itself. Also, can anyone propose any sun JVM jar files I need to 
put in the classpath to run graphical applications?
(Tclblend 1.3.x didn't need such paths from the JVM, does version 1.4.0 
needs such paths?)

Regards,

George


O/H Patrick Finnegan ??????:
> On Tuesday 13 March 2007 07:19, Georgios Petasis wrote:
>   
>> Hi all,
>>
>> I am using tclblend 1.4.0 to load JVM from Tcl. However, when I try to
>> load a specific class I got an error:
>>
>> java::call {enrichment.EnrichmentManager$Test3} main
>> Class "enrichment.EnrichmentManager.Test3" is not accessible
>>
>>     
>
> Have you built the classpath inside the script?  
>
> # build tcl classpath
>
> append x $drive/IBM/WebSphereMQ/Java/lib/com.ibm.mq.jar\;
> append x $drive/IBM/WebSphereMQ/Tools/Java/base\;
> append x $drive/IBM/WebSphereMQ/Java/lib/com.ibm.mqjms.jar\;
> append x $drive/IBM/WebSphereMQ/Tools/Java/jms\;
> append x $drive/IBM/WebSphereMQ/Java/lib/com.ibm.mqbind.jar\;
>
> set env(TCL_CLASSPATH) $x
>
> puts "\nTCL_CLASSPATH = [ array get env TCL_CLASSPATH ]\n"
>
> Have you imported the required classes?  
>
> # import required classes 
>    java::import com.ibm.mq.jms.MQQueueConnectionFactory
>    java::import com.ibm.mq.jms.services.ConfigEnvironment
>    java::import com.ibm.mq.jms.JMSC
>    java::import com.ibm.mq.jms.MQQueueSession
>    java::import com.ibm.mq.jms.MQQueueSender
>
>    # instanciate MQQueueConnectionFactoryI object.
>    set MQQueueConnectionFactoryI [ java::new MQQueueConnectionFactory ]
>
> Patrick.
>
>   

Re: [tcljava-dev] Please help in loading a class...

[Patrick F. <pfi...@oz...>]

On Tuesday 13 March 2007 07:19, Georgios Petasis wrote:
> Hi all,
>
> I am using tclblend 1.4.0 to load JVM from Tcl. However, when I try to
> load a specific class I got an error:
>
> java::call {enrichment.EnrichmentManager$Test3} main
> Class "enrichment.EnrichmentManager.Test3" is not accessible
>

Have you built the classpath inside the script?  

# build tcl classpath

append x $drive/IBM/WebSphereMQ/Java/lib/com.ibm.mq.jar\;
append x $drive/IBM/WebSphereMQ/Tools/Java/base\;
append x $drive/IBM/WebSphereMQ/Java/lib/com.ibm.mqjms.jar\;
append x $drive/IBM/WebSphereMQ/Tools/Java/jms\;
append x $drive/IBM/WebSphereMQ/Java/lib/com.ibm.mqbind.jar\;

set env(TCL_CLASSPATH) $x

puts "\nTCL_CLASSPATH = [ array get env TCL_CLASSPATH ]\n"

Have you imported the required classes?  

# import required classes 
   java::import com.ibm.mq.jms.MQQueueConnectionFactory
   java::import com.ibm.mq.jms.services.ConfigEnvironment
   java::import com.ibm.mq.jms.JMSC
   java::import com.ibm.mq.jms.MQQueueSession
   java::import com.ibm.mq.jms.MQQueueSender

   # instanciate MQQueueConnectionFactoryI object.
   set MQQueueConnectionFactoryI [ java::new MQQueueConnectionFactory ]

Patrick.

[tcljava-dev] Please help in loading a class...

[Georgios P. <pet...@ya...>]

Hi all,

I am using tclblend 1.4.0 to load JVM from Tcl. However, when I try to
load a specific class I got an error:

java::call {enrichment.EnrichmentManager$Test3} main
Class "enrichment.EnrichmentManager.Test3" is not accessible

The same happens with java::new:

java::new {enrichment.EnrichmentManager$Test3}
Class "enrichment.EnrichmentManager.Test3" is not accessible

I also tried:

set dir $creole_BOEMIE_CoordinationDemo_home/Enrichment/enrichment
set fd [open "$dir/EnrichmentManager\$Test3.class" r]
fconfigure $fd -translation binary
set data [read $fd]
close $fd
set class [java::defineclass $data]
set object [$class newInstance]
java.lang.IllegalAccessException: Class tcl.lang.reflect.PkgInvoker can
not access a member of class enrichment.EnrichmentManager$Test3 with
modifiers ""

The class I try to load looks like:

static class EnrichmentManager$Test3
{

     public static void main(String args[])  {
         ...
     }

     EnrichmentManager$Test3()   {
     }
}


Is this due to the constructor that is not public?
Any help will be welcomed, as my Java knowledge is limited :-)

Regards,

George

Re: [tcljava-dev] Building tclblend 1.4.0 under windows with mingw...

[Georgios P. <pet...@ya...>]

O/H Mo DeJong ??????:
> Georgios Petasis wrote:
>   
>> Hi all,
>>
>> I tried to build tclblend 1.4.0 under windows with mingw, and there is
>> something I didn't
>> understand during the building process: how is tclblend linked with the
>> jvm.dll.
>>
>> I downloaded the sources, configured and build everything required (i.e.
>> following
>> http://wiki.tcl.tk/9993), abd the build went ok. However, I didn't
>> understood how
>> the library libjvm.dll.a (inside win directory) has been built. It is
>> included in the sources, but I couldn't
>> get it to work under ActiveTcl, untill I re-build it my self.
>>   
>>     
> The libjvm.dll.a file is used when liking only in the case where the 
> jvm.lib file that comes with the
> JDK fails to work. Some jvm.lib files from some vendors don't work with 
> gcc, so the workaround
> is needed in those cases. But, once tclblend.dll is linked, this file is 
> no longer needed.
I have the impression that the included libjvm.dll.a didn't work in my 
case (mingw - ActiveTcl), and I created
my own. This is why I wanted to know how the file in the original 
distribution was built (and if the procedure
I followed to re-create it was wrong :-))
>  You will likely
> run into issues trying to run a tclblend.dll with the Active State 
> binary as this is not a supported
> configuration. The tclblend.dll you build needs to be run with the Tcl 
> release it was compiled against.
>   
If I only stick into creating a JVM from Tcl (and never do the opposite 
- load Tcl from Java)
will I still have problems? ( I am using a tclblend version that uses 
stubs :-) with ActiveTcl/JDK 5)

Regards,

George

Re: [tcljava-dev] Why tclblend is not stubs-aware?

[Georgios P. <pet...@ya...>]

O/H Mo DeJong ??????:
> Georgios Petasis wrote:
>   
>> Hi all,
>>
>> I am a user of tclblend, and I tried to compile the new tclblend 1.4.0
>> for windows with JDK 5.0 using msys.
>> What I noticed, is that tclblend does not use stubs, and thus is linked
>> directly to a specific version of the tcl dll.
>>   
>>     
> Tcl Blend does not use stubs because there is no way to bootstrap when 
> loading Tcl into
> a Java process. The stubs feature works well when Tcl loads a C 
> extension, but Tcl Blend also
> supports loading both Tcl and Tcl Blend dlls into an existing JVM 
> process (started via java.exe).
> A specific tclblend.dll is tied to a specific Tcl release and a specific 
> JVM release.
>   
I see. I am using tclblend for only loading Java from Tcl, and this is 
why I never noticed any problems
with the stubs-enabled version. I never cross my mind that tclblend can 
be used to load Tcl from
Java. How is this accomplished in Java? You somehow load the tclblend 
dll and a Tcl interp
gets also created?

Regards,
George

Re: [tcljava-dev] Building tclblend 1.4.0 under windows with mingw...

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

Georgios Petasis wrote:
> Hi all,
>
> I tried to build tclblend 1.4.0 under windows with mingw, and there is
> something I didn't
> understand during the building process: how is tclblend linked with the
> jvm.dll.
>
> I downloaded the sources, configured and build everything required (i.e.
> following
> http://wiki.tcl.tk/9993), abd the build went ok. However, I didn't
> understood how
> the library libjvm.dll.a (inside win directory) has been built. It is
> included in the sources, but I couldn't
> get it to work under ActiveTcl, untill I re-build it my self.
>   
The libjvm.dll.a file is used when liking only in the case where the 
jvm.lib file that comes with the
JDK fails to work. Some jvm.lib files from some vendors don't work with 
gcc, so the workaround
is needed in those cases. But, once tclblend.dll is linked, this file is 
no longer needed. You will likely
run into issues trying to run a tclblend.dll with the Active State 
binary as this is not a supported
configuration. The tclblend.dll you build needs to be run with the Tcl 
release it was compiled against.

I hope that helps
Mo DeJong

Re: [tcljava-dev] Why tclblend is not stubs-aware?

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

Georgios Petasis wrote:
> Hi all,
>
> I am a user of tclblend, and I tried to compile the new tclblend 1.4.0
> for windows with JDK 5.0 using msys.
> What I noticed, is that tclblend does not use stubs, and thus is linked
> directly to a specific version of the tcl dll.
>   
Tcl Blend does not use stubs because there is no way to bootstrap when 
loading Tcl into
a Java process. The stubs feature works well when Tcl loads a C 
extension, but Tcl Blend also
supports loading both Tcl and Tcl Blend dlls into an existing JVM 
process (started via java.exe).
A specific tclblend.dll is tied to a specific Tcl release and a specific 
JVM release.

cheers
Mo DeJong

[tcljava-dev] Building tclblend 1.4.0 under windows with mingw...

[Georgios P. <pet...@ya...>]

Hi all,

I tried to build tclblend 1.4.0 under windows with mingw, and there is
something I didn't
understand during the building process: how is tclblend linked with the
jvm.dll.

I downloaded the sources, configured and build everything required (i.e.
following
http://wiki.tcl.tk/9993), abd the build went ok. However, I didn't
understood how
the library libjvm.dll.a (inside win directory) has been built. It is
included in the sources, but I couldn't
get it to work under ActiveTcl, untill I re-build it my self.
(I used reimp available from
http://mywebpage.netscape.com/yongweiwu/reimp_new.zip)
How was the original libjvm.dll.a in the sources built? Using the same tool?

George

[tcljava-dev] Why tclblend is not stubs-aware?

[Georgios P. <pet...@ya...>]

Hi all,

I am a user of tclblend, and I tried to compile the new tclblend 1.4.0
for windows with JDK 5.0 using msys.
What I noticed, is that tclblend does not use stubs, and thus is linked
directly to a specific version of the tcl dll.
Why is that? I have been using stubs-enabled versions of tclblend 1.3.x
for quite some time, without any problems.
Is there a specific reason that stubs are not used by tclblend? (I.e. a
known bug?)

I modified slightly the sources of tclblend 1.4.0 to use stubs, and
while I have not tested yet, doing
'package require java' under ActiveTcl 8.4.14 at least works and the
package seems to be loaded.
So, why not to enable stubs support in tclblend by default?

George