CALLJ. classpath and arguments

[JOSE L MARTINEZ-AVIAL]

Hello,

    I'm using jbase 5.11, and I'm trying to use CALLJ for Java routines. I've been able to call a simple routine as follows:

// PickBasic

    CALLJ "mytestclass", "$mystaticmethod2", 'TONY' SETTING ret ON ERROR
        err = SYSTEM(0)
        DISPLAY "ERROR ":err
    END
    DISPLAY ret

 // Java

    public static String mystaticmethod2(String s) {
        System.out.println("mystaticmethod2 ");
        return "test";
    }

but I have two issues I would like to address:

  1) The classpath needs to be defined before starting jbase. If I set it or change it during the jbase session, it has no effect. Is there any way I do this? Ideally I would like to set the classpath just before calling CALLJ.

  2) The only arguments/return objects possible seem to be String. Is there any way to pass multiple arguments, or an array of Strings? Is there any way it can return something an array of Strings, mapped to a dynamic array, or similar?

Thanks

JL

[Daniel Klein]

1) In the main/parent program, do a PUTENV('CLASSPATH=whatever') then EXECUTE @IM:'k':program_that_does_CALLJ

2) Think 'multi-value': pass the arguments as a dynamic array.

--
--
IMPORTANT: T24/Globus posts are no longer accepted on this forum.
 
To post, send email to jB...@googlegroups.com
To unsubscribe, send email to jBASE-un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en

---
You received this message because you are subscribed to the Google Groups "jBASE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jbase+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jim Idle]

If you want to do anything more complex, then it is better to write your own JNI C routine and call that. I never really liked the CALLJ thing.

But why would you not be able to set the classpath until the CALLJ is executed. You may want to review your architecture if you have to do this. Apart from anything else, that is quite a security hole you will be digging. 

You could also do things the other way around and write a JNI that calls your jBC routine(s) and is the application controller. 

--