Problem with running C execuable from Java

Hello Buddies, I am trying to call a C code from a java GUI (use rt.exec)in a jar. The C code was compiled in the Cygwin (a linux-like envrionment for PC). The C executable runs fine in Cygwin and DOS command line, but if I run it through java GUI (launched from DOS), the final results are incorrect (no error reporting at executing), for example, taking an image file as input, the output image file (after some processing) will have extremely large or small values at all points except those of having value "0" (I mean: the correct outputs from command line and incorrect outputs from Java GUI have same value ("0") at all "0" output points). The Java GUI is just an interface used to generate a parameter file for the C code as an input parameter file, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after manual inputs) for command line run use. I mean there is no any difference for the inputs between java GUI and command line run. It looks somewhat like a little/big_endian issue, but really got no clue of this problem. I use java 1.5.0_09. Any help is greatly appreciated.

Comments

  • : Hello Buddies, I am trying to call a C code from a java GUI (use rt.exec)in a jar. The C code was compiled in the Cygwin (a linux-like envrionment for PC). The C executable runs fine in Cygwin and DOS command line, but if I run it through java GUI (launched from DOS), the final results are incorrect (no error reporting at executing), for example, taking an image file as input, the output image file (after some processing) will have extremely large or small values at all points except those of having value "0" (I mean: the correct outputs from command line and incorrect outputs from Java GUI have same value ("0") at all "0" output points). The Java GUI is just an interface used to generate a parameter file for the C code as an input parameter file, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after manual inputs) for command line run use. I mean there is no any difference for the inputs between java GUI and command line run. It looks somewhat like a little/big_endian issue, but really got no clue of this problem. I use java 1.5.0_09. Any help is greatly appreciated.
    :

    Could you put some more effort into wording things clearly? It is difficult to understand what you are trying to say.

    What you could do is break that into two sections or paragraphs. Limit the first to the facts and then explain your reasoning and guesses in the second part.

    What are the facts? Where precisely is the problem? If it all comes down to an inability to call an executable from Java, why are you giving all these details about images and that you are using a GUI? If the problem is processing images, why pick a title "Problem with running C execuable from Java"?

    What do you mean by "end points" or any of these "points" in an image? Are you referring to the image's dimensions? Are they dots in the image when it is rendered?



  • [b][red]This message was edited by Roboom at 2007-3-8 8:42:39[/red][/b][hr]
    : : Hello Buddies, I am trying to call a C code from a java GUI (use rt.exec)in a jar. The C code was compiled in the Cygwin (a linux-like envrionment for PC). The C executable runs fine in Cygwin and DOS command line, but if I run it through java GUI (launched from DOS), the final results are incorrect (no error reporting at executing), for example, taking an image file as input, the output image file (after some processing) will have extremely large or small values at all points except those of having value "0" (I mean: the correct outputs from command line and incorrect outputs from Java GUI have same value ("0") at all "0" output points). The Java GUI is just an interface used to generate a parameter file for the C code as an input parameter file, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after manual inputs) for command line run use. I mean there is no any difference for the inputs between java GUI and command line run. It looks somewhat like a little/big_endian issue, but really got no clue of this problem. I use java 1.5.0_09. Any help is greatly appreciated.
    : :
    :
    : Could you put some more effort into wording things clearly? It is difficult to understand what you are trying to say.
    :
    : What you could do is break that into two sections or paragraphs. Limit the first to the facts and then explain your reasoning and guesses in the second part.
    :
    : What are the facts? Where precisely is the problem? If it all comes down to an inability to call an executable from Java, why are you giving all these details about images and that you are using a GUI? If the problem is processing images, why pick a title "Problem with running C execuable from Java"?
    :
    : What do you mean by "end points" or any of these "points" in an image? Are you referring to the image's dimensions? Are they dots in the image when it is rendered?
    :
    :
    :
    :
    Sorry for the confusion. Ok, let me reword it and hope it will be clearer.

    Facts: I have an executable built from C code in Cygwin, which implements some processing of HDF format file (most of the cases, do conversions of map projection or file format, this means resampling of original data). When I run this executable in Cygwin environment or a DOS prompt in command line, it runs fine (an input parameter file is needed, the parameter file is generated by Java Gui, we'll talk about it later. The command line run looks like this: $xxx -p parameterfile or in DOS C:XXXxxx.exe -p parameterfile).

    But when I tried to run the executable through a Java GUI, everything looked normal (no any errors were reported) except that the output file was not correct after I checked its contents. The corrupted data only occurred to those binary data their values are not zero.

    The Java GUI is just an interface used to generate a parameter file for the C code as an argument, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after enter some parameters needed by C executable) for later command line run use. If I run the executable from the Java GUI, after entering needed parameters I'll click a "run" button in the GUI to start the executable directly (the param. file is implicitly saved for the run's use).

    The C code runs fine on linux, solaris and SGI command line, also works well from Sun Sparc Java GUI, only not good from PC (WIndows XP Pro, HP/Compaq).

    I doubted that it may be a problem related to big_endian/little_endian, but got no any clue to solve the problem.

    Thanks for your time.



  • : [b][red]This message was edited by Roboom at 2007-3-8 8:42:39[/red][/b][hr]
    : : : Hello Buddies, I am trying to call a C code from a java GUI (use rt.exec)in a jar. The C code was compiled in the Cygwin (a linux-like envrionment for PC). The C executable runs fine in Cygwin and DOS command line, but if I run it through java GUI (launched from DOS), the final results are incorrect (no error reporting at executing), for example, taking an image file as input, the output image file (after some processing) will have extremely large or small values at all points except those of having value "0" (I mean: the correct outputs from command line and incorrect outputs from Java GUI have same value ("0") at all "0" output points). The Java GUI is just an interface used to generate a parameter file for the C code as an input parameter file, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after manual inputs) for command line run use. I mean there is no any difference for the inputs between java GUI and command line run. It looks somewhat like a little/big_endian issue, but really got no clue of this problem. I use java 1.5.0_09. Any help is greatly appreciated.
    : : :
    : :
    : : Could you put some more effort into wording things clearly? It is difficult to understand what you are trying to say.
    : :
    : : What you could do is break that into two sections or paragraphs. Limit the first to the facts and then explain your reasoning and guesses in the second part.
    : :
    : : What are the facts? Where precisely is the problem? If it all comes down to an inability to call an executable from Java, why are you giving all these details about images and that you are using a GUI? If the problem is processing images, why pick a title "Problem with running C execuable from Java"?
    : :
    : : What do you mean by "end points" or any of these "points" in an image? Are you referring to the image's dimensions? Are they dots in the image when it is rendered?
    : :
    : :
    : :
    : :
    : Sorry for the confusion. Ok, let me reword it and hope it will be clearer.
    :
    : Facts: I have an executable built from C code in Cygwin, which implements some processing of HDF format file (most of the cases, do conversions of map projection or file format, this means resampling of original data). When I run this executable in Cygwin environment or a DOS prompt in command line, it runs fine (an input parameter file is needed, the parameter file is generated by Java Gui, we'll talk about it later. The command line run looks like this: $xxx -p parameterfile or in DOS C:XXXxxx.exe -p parameterfile).
    :
    : But when I tried to run the executable through a Java GUI, everything looked normal (no any errors were reported) except that the output file was not correct after I checked its contents. The corrupted data only occurred to those binary data their values are not zero.
    :
    : The Java GUI is just an interface used to generate a parameter file for the C code as an argument, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after enter some parameters needed by C executable) for later command line run use. If I run the executable from the Java GUI, after entering needed parameters I'll click a "run" button in the GUI to start the executable directly (the param. file is implicitly saved for the run's use).
    :
    : The C code runs fine on linux, solaris and SGI command line, also works well from Sun Sparc Java GUI, only not good from PC (WIndows XP Pro, HP/Compaq).
    :
    : I doubted that it may be a problem related to big_endian/little_endian, but got no any clue to solve the problem.
    :
    : Thanks for your time.
    :
    :

    Are you generating a batch file and executing that or directly executing the executable?

    Are you using Java's Runtime class to run the program? Could you show this code?

    Have you tried using absolute paths to all your files? Maybe your program is looking in an unexpected directory for input and output files.






  • : : [b][red]This message was edited by Roboom at 2007-3-8 8:42:39[/red][/b][hr]
    : : : : Hello Buddies, I am trying to call a C code from a java GUI (use rt.exec)in a jar. The C code was compiled in the Cygwin (a linux-like envrionment for PC). The C executable runs fine in Cygwin and DOS command line, but if I run it through java GUI (launched from DOS), the final results are incorrect (no error reporting at executing), for example, taking an image file as input, the output image file (after some processing) will have extremely large or small values at all points except those of having value "0" (I mean: the correct outputs from command line and incorrect outputs from Java GUI have same value ("0") at all "0" output points). The Java GUI is just an interface used to generate a parameter file for the C code as an input parameter file, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after manual inputs) for command line run use. I mean there is no any difference for the inputs between java GUI and command line run. It looks somewhat like a little/big_endian issue, but really got no clue of this problem. I use java 1.5.0_09. Any help is greatly appreciated.
    : : : :
    : : :
    : : : Could you put some more effort into wording things clearly? It is difficult to understand what you are trying to say.
    : : :
    : : : What you could do is break that into two sections or paragraphs. Limit the first to the facts and then explain your reasoning and guesses in the second part.
    : : :
    : : : What are the facts? Where precisely is the problem? If it all comes down to an inability to call an executable from Java, why are you giving all these details about images and that you are using a GUI? If the problem is processing images, why pick a title "Problem with running C execuable from Java"?
    : : :
    : : : What do you mean by "end points" or any of these "points" in an image? Are you referring to the image's dimensions? Are they dots in the image when it is rendered?
    : : :
    : : :
    : : :
    : : :
    : : Sorry for the confusion. Ok, let me reword it and hope it will be clearer.
    : :
    : : Facts: I have an executable built from C code in Cygwin, which implements some processing of HDF format file (most of the cases, do conversions of map projection or file format, this means resampling of original data). When I run this executable in Cygwin environment or a DOS prompt in command line, it runs fine (an input parameter file is needed, the parameter file is generated by Java Gui, we'll talk about it later. The command line run looks like this: $xxx -p parameterfile or in DOS C:XXXxxx.exe -p parameterfile).
    : :
    : : But when I tried to run the executable through a Java GUI, everything looked normal (no any errors were reported) except that the output file was not correct after I checked its contents. The corrupted data only occurred to those binary data their values are not zero.
    : :
    : : The Java GUI is just an interface used to generate a parameter file for the C code as an argument, if I want to run the C code in command line, I will run the java GUI first, generate and save the parameter file (after enter some parameters needed by C executable) for later command line run use. If I run the executable from the Java GUI, after entering needed parameters I'll click a "run" button in the GUI to start the executable directly (the param. file is implicitly saved for the run's use).
    : :
    : : The C code runs fine on linux, solaris and SGI command line, also works well from Sun Sparc Java GUI, only not good from PC (WIndows XP Pro, HP/Compaq).
    : :
    : : I doubted that it may be a problem related to big_endian/little_endian, but got no any clue to solve the problem.
    : :
    : : Thanks for your time.
    : :
    : :
    :
    : Are you generating a batch file and executing that or directly executing the executable?
    :
    : Are you using Java's Runtime class to run the program? Could you show this code?
    :
    : Have you tried using absolute paths to all your files? Maybe your program is looking in an unexpected directory for input and output files.
    :
    :
    Thank you.

    Yes, I start the Java GUI from a DOS batch file.
    Yes, I use Java's Runtime class to run the program.
    As far as I know, I am using absolute paths to all my input and output files, environ variables, and temporary files.

    Batch file:

    @echo off

    rem *****************
    rem * heg.bat *
    rem *****************

    set MRTDATADIR=c:HEGv2.7HEGHEG_Windata

    set MRTBINDIR=c:HEGv2.7HEGHEG_Winin

    set PGSHOME=c:HEGv2.7HEGHEG_WinTOOLKIT_MTD

    set HEGUSER=D1357

    rem Run the Java GUI.
    rem Change the java.exe path to reflect the directory structure on your machine.
    rem Quotes are only necessary to handle blank spaces in the pathnames.

    "c:Program FilesJavajre1.5.0_09injava.exe" -DHEGUSER=D1357 -classpath "c:HEGv2.7HEGHEG_WininHEG.jar" heg.HEGDriver

    ---------------------------------------
    Java code (not HEGDriver class) calling C executable:


    package heg;


    import java.util.Vector;

    import java.io.InputStream;
    import java.io.BufferedReader;
    import java.io.IOException;
    import java.io.InputStreamReader;

    import javax.swing.JOptionPane;



    public class HEGRunConversion
    {

    public HEGRunConversion()
    {
    }

    public int createParameters(Vector runInfo, String fileName, int typeFlag)
    {
    HEGBuildParameters buildParams = new HEGBuildParameters();
    int retVal = 0;

    if ((typeFlag == HEGConstants.HEG_MISR_GRID) || (typeFlag == HEGConstants.HEG_IS_GRID) ||
    (typeFlag == HEGConstants.HEG_IS_GRID_SUBSAMPLE))
    {
    retVal = buildParams.makeGridParameterFile(runInfo,fileName,typeFlag);
    }
    else
    {
    retVal = buildParams.makeSwathParameterFile(runInfo,fileName);
    }

    if (retVal == HEGConstants.HEG_FAIL)
    {
    JOptionPane.showMessageDialog(null,"Error creating paramters file: " + fileName,
    "HEG Error",JOptionPane.ERROR_MESSAGE);
    retVal = 0;
    }

    return retVal;
    }

    public void runConversion(HEGStatusDialog statusDialog,int typeFlag)
    {

    final HEGStatusDialog myStatusDialog = statusDialog;
    final int myFlag = typeFlag;

    statusDialog.showStatusDialog();
    Thread t = new Thread(new Runnable()
    {
    public void run()
    {

    final Runtime rt = Runtime.getRuntime();
    String hdrFilename = null;
    String toRun = null;
    Process p;
    try
    {
    String localUser = System.getProperty("HEGUSER");
    if (myFlag == HEGConstants.HEG_IS_GRID)
    {
    p = rt.exec(...);
    toRun = new String(...);
    }
    else if (myFlag == HEGConstants.HEG_MISR_GRID)
    {
    p = rt.exec(HEGConstants.HEG_CURRENT_PATH + HEGConstants.HEG_GDTIF +
    " -p " + (HEGConstants.HEG_MISR_FILE + "_" + localUser));
    toRun = new String(HEGConstants.HEG_GDTIF);
    }

    /*** ABOVE BLOCK IS MY INTERESTS ***/

    else if (myFlag == HEGConstants.HEG_IS_GRID_SUBSAMPLE)
    {
    p = rt.exec(...);
    toRun = new String(...);
    }
    else
    {
    p = rt.exec(...);
    toRun = new String(...);
    }
    }
    catch (java.io.IOException ie)
    {
    JOptionPane.showMessageDialog(null,"ERROR: " + toRun + " not found.",
    "HEG Error",JOptionPane.ERROR_MESSAGE);
    return;
    }

    final Process proc = p;

    Thread outThread = new Thread(new Runnable()
    {
    public void run()
    {
    myStatusDialog.setKillFlag(false);
    InputStream is = proc.getInputStream();
    BufferedReader br = new BufferedReader(new InputStreamReader(is));
    char[] buffer = new char[10];
    for (;;)
    {
    if (myStatusDialog.getKillFlag() == true)
    {
    myStatusDialog.setKillFlag(false);
    myStatusDialog.displayStatus("

    PROCESS KILLED BY USER....");
    proc.destroy();
    break;
    }
    int numread = 0;
    try
    {
    numread = br.read(buffer,0,10);
    if (numread < 0)
    {
    break;
    }
    myStatusDialog.displayStatus(new String(buffer,0,numread));
    }
    catch (IOException ie)
    {
    System.out.println("ie exception point is " + ie);
    }
    }
    }
    }); //end of Thread outThread

    outThread.start();

    Thread errThread = new Thread(new Runnable()
    {
    public void run()
    {

    InputStream is = proc.getErrorStream();
    BufferedReader br = new BufferedReader(new InputStreamReader(is));
    char[] buffer = new char[10];
    for (;;)
    {
    try
    {
    int numread = br.read(buffer,0,10);
    if (numread < 0)
    {
    break;
    }

    myStatusDialog.displayStatus(new String(buffer,0,numread));
    }
    catch (IOException ie)
    {
    System.out.println("last ie is " + ie);
    }
    }
    }
    });//end of Thread errThread
    errThread.start();

    } //end of the first "public void run()" function
    }); //end of Thread t

    t.start();

    }

    private void complain(String title, String text)
    {
    /*
    JOptionPane msg = new JOptionPane(text);
    JDialog dialog = msg.createDialog(this,title);
    dialog.show();
    */
    }
    }



Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories