This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

calling java from XDC Script issues

Hello,

It appears that my issues with calling java code form a loaded package is not wokring as well as I initially thought.

my original post is here: http://e2e.ti.com/support/embedded/tirtos/f/355/p/338143/1181180.aspx#1181180

When I tested that code, I used the following lines:

xdc.loadPackage('javautils');

var connection = java.sql.DriverManager.getConnection("jdbc:sqlite:test.db");

I got an error, but I assumed it was because the test.db file was missing. Now I have a real file, specified as a metaonly config value, and I am getting an error about there being no suitable driver. The driver jar file should be in the javautils package I created, as noted in the linked thread.

What is the best way to go about debugging this?

Is there a way to make XDC display the java class path?

Or find out which JRE it is using so I can install the driver jar there (non-ideal solution)?

  • Let me first explain how that all works.
    When you call xdc.loadPackage("javautils"), the function loadPackage() calls xdc.$$addJars() on the subdirectory 'java' of 'javautils'. The function $$addJars is really a Java function that invokes our actual class loader and adds jars to the classpath. The easiest way to find what's in there is to call xdc.$$addJars() without arguments. You'll get the list of jars that were added through $$addJars.

    You can also query the class loader through the common Java code, but that returns only few jars. I forgot why the discrepancy. I think that Java code might be reflecting what was the class path initially without taking into account any components added dynamically. Here is the code that you can add to your config script:
    var cl = java.lang.ClassLoader.getSystemClassLoader();
    var ar = cl.getURLs();
    for (var i =0; i < ar.length; i++) {
        print(ar[i]);
    }

  • I finally got around to adding the $$addJars after my loadPackage call on javautils, and the jars which should be loaded are there:

    /home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/services/intern/xsr/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/services/spec/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/services/intern/cmd/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/shelf/java/js.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/shelf/java/tar.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/rov/java/package.jar,/home/User/p4/prog/dev/DEV/program_common/rtsc_common/javautils_sqlite_jdbc/java/sqlite-jdbc-3.7.2.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/runtime/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/services/intern/gen/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/shelf/java/ecj.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/services/getset/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/services/global/java/package.jar,/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/shelf/java/antlr.jar,/home/User/p4/prog/dev/DEV/program_common/rtsc_common/javautils/java/SqlDatabaseSupport.jar


    But I am still getting an error, where java does not find the sqlite-jdbc-3.7.2.jar:

    js: "/home/User/p4/prog/dev/DEV/program_common/rtsc_common/prog/Maintenance/BITController.xs", line 154: No suitable driver
        "/home/User/p4/prog/dev/DEV/program_common/rtsc_common/prog/Maintenance/package.xs", line 19
    org.mozilla.javascript.WrappedException: Wrapped java.sql.SQLException: No suitable driver (/home/User/p4/prog/dev/DEV/program_common/rtsc_common/prog/Maintenance/BITController.xs#154)
        at org.mozilla.javascript.Context.throwAsScriptRuntimeEx(Context.java:1773)
        at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:183)
        at org.mozilla.javascript.NativeJavaMethod.call(NativeJavaMethod.java:247)
        at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
        at script.PackageClose(/home/User/p4/prog/dev/DEV/program_common/rtsc_common/prog/Maintenance/BITController.xs:154)
        at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
        at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
        at xdc.services.intern.xsr.Invoke.call(Invoke.java:92)
        at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
        at script.close(/home/User/p4/prog/dev/DEV/program_common/rtsc_common/prog/Maintenance/package.xs:19)
        at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
        at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
        at xdc.services.intern.xsr.Invoke.call(Invoke.java:92)
        at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
        at script.closePackages(/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/cfg/Main.xs:827)
        at script.runStringCfg(/home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/packages/xdc/cfg/Main.xs:229)
        at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
        at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
        at xdc.services.intern.xsr.Invoke.call(Invoke.java:130)
        at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
        at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
        at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
        at xdc.services.intern.xsr.Invoke.call(Invoke.java:130)
        at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
        at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
        at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
        at xdc.services.intern.xsr.Invoke.call(Invoke.java:92)
        at org.mozilla.javascript.Interpreter.interpretLoop(Interpreter.java:3330)
        at org.mozilla.javascript.Interpreter.interpret(Interpreter.java:2487)
        at org.mozilla.javascript.InterpretedFunction.call(InterpretedFunction.java:164)
        at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:398)
        at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3068)
        at org.mozilla.javascript.InterpretedFunction.exec(InterpretedFunction.java:175)
        at org.mozilla.javascript.Context.evaluateReader(Context.java:1135)
        at config.Shell.evaluateReader(Shell.java:846)
        at config.Shell.processReader(Shell.java:511)
        at config.Shell.processFile(Shell.java:570)
        at config.Shell.exec(Shell.java:780)
        at config.Shell.main(Shell.java:1413)
    Caused by: java.sql.SQLException: No suitable driver
        at java.sql.DriverManager.getConnection(DriverManager.java:545)
        at java.sql.DriverManager.getConnection(DriverManager.java:193)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:592)
        at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:161)

    And if I try to invoke the other jar I loaded (SqlDatabaseSupport.jar) I get another error:

    js: "/home/prog/p4/prog/dev/DEV/program_common/rtsc_common/prog/Maintenance/BITController.xs", line 155: TypeError: [JavaPackage xxx.yyy.prog.sql.progDatabase] is not a function, it is object.


    Here is line 155:

    var bitDatabase = new Packages.xxx.yyy.prog.sql.progDatabase(databaseFile);

  • The first error seems JDBC-specific. I don't really see anything in the error message that indicates that the JAR file sqlite-jdbc-3.7.2.jar is not found. There could be an underlying error caused by some class not being loaded, but it's hard to tell from that error message. Have you tried running that same setup from a pure Java environment without involving XDCscript?

    As for the second error, I have seen that before. It happens when a class cannot be loaded because it's not available, but also for other reasons, if you built the package with a newer version of Java than one used in XDCscript. XDCtools that you are using contains very old Java 5 JVM, so if your packages are built with Java 6 or 7, you could see such an error.

  • Ahh, the Java 5 JVM may very well be the issue for both of my problems. Is there a version of XDCtools which uses Java 7? And then is there going to be an issue if I upgrade to that version of XDC but keep BIOS at 6.34.01.14?

    Thanks!

  • Try setting the environment variable XDCTOOLS_JAVA_HOME to point to your version of JVM, for example
    XDCTOOLS_JAVA_HOME=C:\Program Files\Java\jre7
    or
    XDCTOOLS_JAVA_HOME=C:\Program Files\Java\jdk1.7.0_01\jre

    Then, run XDCtools from the same command window where you defined the variable. You may have to rename the directory 'jre' in XDCtools to something else, so it doesn't get in the way.

  • So I gave this a shot and it gave me the following error:

    /home/User/p4/tidsp/ti_rtsc/lin/xdctools_3_24_03_33/xs.x86U: error: can't create session manager: can't find a JVM; try setting the environment variable 'XDCTOOLS_JAVA_HOME' to the absolute path of any directory containing a SUN Java Runtime Environment (1.5 or greater) in a sub-directory named 'jre'.

    I'm running on Linux (CentOS 6.3). I renamed the xdc local jre directory, and set the environment variable with:

    export XDCTOOLS_JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.55.x86_64/jre

  • I have attempted pointing XDCtools to this version:

    $ java -version
    java version "1.7.0_55"
    OpenJDK Runtime Environment (rhel-2.4.7.1.el6_5-x86_64 u55-b13)
    OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)

    and this version:

    $ ./java -version
    java version "1.7.0_55"
    Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

    and I still get the same error.

    I was hoping that maybe it really wanted the SUN version, but apparently not...

  • Any Ideas on why xs can't create a sessions manager / find the JVM?


    I noticed in version 1.5 which is distributed with XDCtools had a javaws directory which 1.7 had lumped into bin. I added the directory and a symlink to the javaws binary. But I'm still getting the error.

    My low level knowledge of java is quite limited, and google is only helping so much.

    Thanks

  • I tried running the same experiment on windows: setting the environment variable and renaming the xdc jre folder.

    I end up getting the same error:

    c:\Users\user\Perforce\user_PC-user2_7549\tidsp\ti_rtsc\win\xdctools_3_24_03_33\xs.exe: error: can't create session manager: can't find a JVM; try setting the environment variable 'XDCTOOLS_JAVA_HOME' to the absolute path of any directory containing a SUN Java Runtime Environment (1.5 or greater) in a sub-directory named 'jre'.

  • I just installed a local version of java 1.5, and pointed XDCTools to that jre, and it is still giving me the same error?

    I must be missing something very simple here?

  • Can you add the option --d to your xs command line? That should give more info about the exact files that can't be found. It's possible that our mechanism of looking for JVM is not working for some JVM installations.

    If you are not typing the xs command line, but it gets generated by 'xdc', and the environment variable XDCOPTIONS=v, which will display each command line executed, and then you can copy, edit and run the xs command line. Just add '--d' right after 'xs'. 

  • After trying the --d I learned two things:

    1) I needed to point xdc to a 32bit JRE

    2) Then environment variable needed to be pointing to the directory containing the jre directory, not the jre directory itself

    Thanks!