Harmony
  1. Harmony
  2. HARMONY-6620

[jdktools] Unit tests to test the functionality of the javac/javaw binaries

    Details

    • Type: Test Test
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: JDK
    • Labels:
      None
    • Environment:
      Windows and Linux
    • Patch Info:
      Patch Available
    • Estimated Complexity:
      Moderate

      Description

      The ANT unit tests written for the jdktools binaries such as javac aren't flexible enough. i.e. if there is a test failure then the rest of the tests are skipped. Moreover, there aren't a lot of test scenarios created for these binaries.

      Added Unit tests to test the javac.exe and javaw.exe tools. This helps in providing a better analysis of these tools across different runtimes.

      1. 006_HARMONY_6620.patch
        22 kB
        Prashanth KS
      2. 006_HARMONY_6620.patch
        22 kB
        Prashanth KS
      3. 006_HARMONY_6620.patch
        22 kB
        Prashanth KS
      4. 005_HARMONY_6620.patch
        18 kB
        Prashanth KS
      5. TEST-org.apache.harmony.tests.tools.javac.binary.JavacBinTest.xml
        33 kB
        Prashanth KS
      6. 004_HARMONY_6620.patch
        28 kB
        Prashanth KS
      7. 003_HARMONY_6620.patch
        27 kB
        Prashanth KS
      8. 002_HARMONY_6620.patch
        20 kB
        Prashanth KS
      9. resources.zip
        4 kB
        Prashanth KS
      10. 001_HARMONY_6620.patch
        20 kB
        Prashanth KS

        Activity

        Hide
        Prashanth KS added a comment -

        Can someone commit this patch? Its been open for a long time.

        Show
        Prashanth KS added a comment - Can someone commit this patch? Its been open for a long time.
        Hide
        Prashanth KS added a comment -

        The patch 006_HARMONY_6620.patch got attached thrice, though I did it only once. Kindly use any one of the above.

        Show
        Prashanth KS added a comment - The patch 006_HARMONY_6620.patch got attached thrice, though I did it only once. Kindly use any one of the above.
        Prashanth KS made changes -
        Comment [ Have removed the test "JavawBinTest.testLaunch" as this requires some changes in the samsa launcher. Will create a separate JIRA for this.

        The other failure has been fixed and tested. Have added additional helper methods to test the presence of the javac and javaw executables. I understand that these helper methods can be aggregated in future. ]
        Prashanth KS made changes -
        Comment [ Have removed the test "JavawBinTest.testLaunch" as this requires some changes in the samsa launcher. Will create a separate JIRA for this.

        The other failure has been fixed and tested. Have added additional helper methods to test the presence of the javac and javaw executables. I understand that these helper methods can be aggregated in future. ]
        Prashanth KS made changes -
        Attachment 006_HARMONY_6620.patch [ 12457823 ]
        Hide
        Prashanth KS added a comment -

        Have removed the test "JavawBinTest.testLaunch" as this requires some changes in the samsa launcher. Will create a separate JIRA for this.

        The other failure has been fixed and tested. Have added additional helper methods to test the presence of the javac and javaw executables. I understand that these helper methods can be aggregated in future.

        Show
        Prashanth KS added a comment - Have removed the test "JavawBinTest.testLaunch" as this requires some changes in the samsa launcher. Will create a separate JIRA for this. The other failure has been fixed and tested. Have added additional helper methods to test the presence of the javac and javaw executables. I understand that these helper methods can be aggregated in future.
        Prashanth KS made changes -
        Attachment 006_HARMONY_6620.patch [ 12457822 ]
        Prashanth KS made changes -
        Attachment 006_HARMONY_6620.patch [ 12457821 ]
        Hide
        Mark Hindess added a comment -

        In order to be applied, the failures you mention need to be fixed. Specifically, on windows I see a failure for "JavacBinTest.test_nonExists" and "JavawBinTest.testLaunch". These need to be fixed so that the patch can be applied without breaking the test run for everyone.

        Show
        Mark Hindess added a comment - In order to be applied, the failures you mention need to be fixed. Specifically, on windows I see a failure for "JavacBinTest.test_nonExists" and "JavawBinTest.testLaunch". These need to be fixed so that the patch can be applied without breaking the test run for everyone.
        Hide
        Prashanth KS added a comment -

        I tested this patch (005_HARMONY_6620.patch) on Windows. Other than the test failures mentioned before, the other tests pass for me. So this patch can be applied. Please let me know if you need more information.

        Show
        Prashanth KS added a comment - I tested this patch (005_HARMONY_6620.patch) on Windows. Other than the test failures mentioned before, the other tests pass for me. So this patch can be applied. Please let me know if you need more information.
        Hide
        Mark Hindess added a comment -

        The tests pass for me. If you attach a patch that will also pass on windows then I should be able to apply it.

        Show
        Mark Hindess added a comment - The tests pass for me. If you attach a patch that will also pass on windows then I should be able to apply it.
        Hide
        Prashanth KS added a comment -

        Two failures that I see when I run this test are:

        ----------------------------------------------------------------------------------------------------------------------------------------------
        <testcase classname="org.apache.harmony.tests.tools.javac.binary.JavacBinTest" name="test_nonExists" time="0.703">
        <failure message="The output should contain "is missing" Error - "javac: file not found: no_this_test.java

        We expect an "is missing" message to be displayed (as per the ecj.jar output) but we see a "not found".
        ----------------------------------------------------------------------------------------------------------------------------------------------
        <testcase classname="org.apache.harmony.tests.tools.javaw.binary.JavawBinTest" name="testLaunch" time="0.031">
        <failure message="Failure message should contain "-dummy" Error "" Output "Harmony Java launcher
        Apache Harmony Launcher : (c) Copyright 1991, 2010 The Apache Software Foundation or its licensors, as applicable.
        java [-vm:vmdll -vmdir:dir -D... [-X...]] [args]

        We get the same output from the launcher, irrespective of the options supplied to the javaw. I guess this is known, but something to consider.
        ----------------------------------------------------------------------------------------------------------------------------------------------

        Show
        Prashanth KS added a comment - Two failures that I see when I run this test are: ---------------------------------------------------------------------------------------------------------------------------------------------- <testcase classname="org.apache.harmony.tests.tools.javac.binary.JavacBinTest" name="test_nonExists" time="0.703"> <failure message="The output should contain "is missing" Error - "javac: file not found: no_this_test.java We expect an "is missing" message to be displayed (as per the ecj.jar output) but we see a "not found". ---------------------------------------------------------------------------------------------------------------------------------------------- <testcase classname="org.apache.harmony.tests.tools.javaw.binary.JavawBinTest" name="testLaunch" time="0.031"> <failure message="Failure message should contain "-dummy" Error "" Output "Harmony Java launcher Apache Harmony Launcher : (c) Copyright 1991, 2010 The Apache Software Foundation or its licensors, as applicable. java [-vm:vmdll -vmdir:dir -D... [-X...] ] [args] We get the same output from the launcher, irrespective of the options supplied to the javaw. I guess this is known, but something to consider. ----------------------------------------------------------------------------------------------------------------------------------------------
        Prashanth KS made changes -
        Attachment 005_HARMONY_6620.patch [ 12457466 ]
        Hide
        Prashanth KS added a comment -

        Patch updated as per the changed build structure and the Support_Exec file. Please use the jars from the attached zip file.

        This patch applies to the 1.6 stream as well.

        Show
        Prashanth KS added a comment - Patch updated as per the changed build structure and the Support_Exec file. Please use the jars from the attached zip file. This patch applies to the 1.6 stream as well.
        Hide
        Hudson added a comment -

        Integrated in Harmony-1.5-head-linux-x86_64 #988 (See https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/988/)
        Create platform-specific tree to facilitate windows specific tests
        required for HARMONY-6620 (javaw test).

        Show
        Hudson added a comment - Integrated in Harmony-1.5-head-linux-x86_64 #988 (See https://hudson.apache.org/hudson/job/Harmony-1.5-head-linux-x86_64/988/ ) Create platform-specific tree to facilitate windows specific tests required for HARMONY-6620 (javaw test).
        Hide
        Hudson added a comment -

        Integrated in Harmony-select-1.5-head-linux-x86_64 #141 (See https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/141/)
        Create platform-specific tree to facilitate windows specific tests
        required for HARMONY-6620 (javaw test).

        Show
        Hudson added a comment - Integrated in Harmony-select-1.5-head-linux-x86_64 #141 (See https://hudson.apache.org/hudson/job/Harmony-select-1.5-head-linux-x86_64/141/ ) Create platform-specific tree to facilitate windows specific tests required for HARMONY-6620 (javaw test).
        Hide
        Mark Hindess added a comment -

        In r1022390 I refactored some code to provide a suitable Support_Exec.run() method and in r1022493 I created the necessary build structure to more sensibly support a windows only javaw test. Please update your patch. Thanks.

        Show
        Mark Hindess added a comment - In r1022390 I refactored some code to provide a suitable Support_Exec.run() method and in r1022493 I created the necessary build structure to more sensibly support a windows only javaw test. Please update your patch. Thanks.
        Hide
        Mark Hindess added a comment -

        It isn't ok. I still don't understand the windows subdirectory without also having a "common" subdirectory as is consistently the case with other modules.

        I also noticed - though this wasn't made clear in your submissions - that you seem to have just copied and pasted code (twice) from Support_Exec.java and modified it. It clearly makes more sense to make a helper class that can be use in both places (and hopefully more - since we obviously need to test other tools as well) rather than maintaining three copies of not quite identical code.

        As it turns out the instrument module has a Runtime.Exec helper too so I am hopeful we can combine these to come up with a combined support class. I will take a look at this.

        Show
        Mark Hindess added a comment - It isn't ok. I still don't understand the windows subdirectory without also having a "common" subdirectory as is consistently the case with other modules. I also noticed - though this wasn't made clear in your submissions - that you seem to have just copied and pasted code (twice) from Support_Exec.java and modified it. It clearly makes more sense to make a helper class that can be use in both places (and hopefully more - since we obviously need to test other tools as well) rather than maintaining three copies of not quite identical code. As it turns out the instrument module has a Runtime.Exec helper too so I am hopeful we can combine these to come up with a combined support class. I will take a look at this.
        Hide
        Prashanth KS added a comment -

        Mark, can you kindly apply this patch and commit it if this is ok? This has been open for quite some time

        Show
        Prashanth KS added a comment - Mark, can you kindly apply this patch and commit it if this is ok? This has been open for quite some time
        Prashanth KS made changes -
        Hide
        Prashanth KS added a comment -

        004_HARMONY_6620.patch - Patch file to resolve thread hangs
        TEST-org.apache.harmony.tests.tools.javac.binary.JavacBinTest.xml - Output of a test run with DRLVM

        Show
        Prashanth KS added a comment - 004_HARMONY_6620.patch - Patch file to resolve thread hangs TEST-org.apache.harmony.tests.tools.javac.binary.JavacBinTest.xml - Output of a test run with DRLVM
        Hide
        Prashanth KS added a comment -

        It looks like the locking mechanism is implemented in a different manner in the DRLVM. Also, the use of a wait() can cause threads to wait forever. The attached patch should be able to resolve any sort of hangs.

        The other observation I saw was the javac output (even when using DRLVM) for a non-existent file still prints "not found" in the output message. I am not sure where that message is being picked from. Please find the attached report that shows it. Possible that I maybe missing setting some system property.

        Show
        Prashanth KS added a comment - It looks like the locking mechanism is implemented in a different manner in the DRLVM. Also, the use of a wait() can cause threads to wait forever. The attached patch should be able to resolve any sort of hangs. The other observation I saw was the javac output (even when using DRLVM) for a non-existent file still prints "not found" in the output message. I am not sure where that message is being picked from. Please find the attached report that shows it. Possible that I maybe missing setting some system property.
        Hide
        Prashanth KS added a comment -

        Missed adding this comment during the code freeze timeframe.

        Other than the comment below, the rest of them have been addressed. I didn't do this because I didn't want to nest method calls. I also added a provision to monitor exit status.

        "Since all runExe callers call getProcessOutput why not have runExe
        take a displayOutput boolean and then return:

        { proc, getProcessOutput(proc, displayOutput), errBuf.toString() }

        "

        I see three different behaviors with DRLVM, IBM JDK and SUN JRE. The JavacBinTest.java test hangs with DRLVM but works on the other two JDKs properly. JavawBinTest.java hangs on IBM JDK, but works fine with the SUN JRE. I will examine this more deeply and get back with the necessary reports.

        I specifically created the tests in a windows dir because it is more visible to the developer, rather than the exclude files. Hope this is ok.

        Show
        Prashanth KS added a comment - Missed adding this comment during the code freeze timeframe. Other than the comment below, the rest of them have been addressed. I didn't do this because I didn't want to nest method calls. I also added a provision to monitor exit status. "Since all runExe callers call getProcessOutput why not have runExe take a displayOutput boolean and then return: { proc, getProcessOutput(proc, displayOutput), errBuf.toString() } " I see three different behaviors with DRLVM, IBM JDK and SUN JRE. The JavacBinTest.java test hangs with DRLVM but works on the other two JDKs properly. JavawBinTest.java hangs on IBM JDK, but works fine with the SUN JRE. I will examine this more deeply and get back with the necessary reports. I specifically created the tests in a windows dir because it is more visible to the developer, rather than the exclude files. Hope this is ok.
        Hide
        Mark Hindess added a comment -

        I was hoping to be able to commit this and fix the remaining problems myself but the test (org.apache.harmony.tests.tools.javac.binary.JavacBinTest) hangs for me on linux - leaving the completed javac process as a defunct process as the parent hasn't run waitpid.

        The windows only test should not be in a windows subdirectory since you went with the exclude list alternative.

        Which comments mentioned by me did you not address? And why?

        Show
        Mark Hindess added a comment - I was hoping to be able to commit this and fix the remaining problems myself but the test (org.apache.harmony.tests.tools.javac.binary.JavacBinTest) hangs for me on linux - leaving the completed javac process as a defunct process as the parent hasn't run waitpid. The windows only test should not be in a windows subdirectory since you went with the exclude list alternative. Which comments mentioned by me did you not address? And why?
        Tim Ellison made changes -
        Fix Version/s 5.0M15 [ 12315054 ]
        Prashanth KS made changes -
        Attachment 003_HARMONY_6620.patch [ 12453115 ]
        Hide
        Prashanth KS added a comment -

        Most of the comments mentioned by Mark have been addressed. Kindly apply the resources from the resources.zip. I will test the patch once this is committed.

        Show
        Prashanth KS added a comment - Most of the comments mentioned by Mark have been addressed. Kindly apply the resources from the resources.zip. I will test the patch once this is committed.
        Hide
        Prashanth KS added a comment -

        Yes. I got that point. When I ran this test against the Community build, it was passing. I knew something was wrong because the results were contradicting the tests results for the MainTest. I assumed that the exe's got just their output messages from a different source. I am rewriting the test cases based on the same to check for VM launch failures.

        I understand the point about the tests being valid in Harmony first.

        Show
        Prashanth KS added a comment - Yes. I got that point. When I ran this test against the Community build, it was passing. I knew something was wrong because the results were contradicting the tests results for the MainTest. I assumed that the exe's got just their output messages from a different source. I am rewriting the test cases based on the same to check for VM launch failures. I understand the point about the tests being valid in Harmony first.
        Hide
        Mark Hindess added a comment -

        Sorry, I don't understand? These tests are for harmony and harmony javac is just a wrapper around ecj.jar so for your test to pass on harmony ecj.jar must have the message you expect or it will never work? Ideally they should pass on both harmony and the RI but unless they pass on harmony I really don't think they are going to be much use?

        Show
        Mark Hindess added a comment - Sorry, I don't understand? These tests are for harmony and harmony javac is just a wrapper around ecj.jar so for your test to pass on harmony ecj.jar must have the message you expect or it will never work? Ideally they should pass on both harmony and the RI but unless they pass on harmony I really don't think they are going to be much use?
        Hide
        Prashanth KS added a comment -

        Please note that these tests are for the javac and javaw executables. So ecj.jar wouldn't be having those messages. Please find the output of the Sun JRE pasted below:

        C:\Documents and Settings\Administrator>java -version
        java version "1.6.0_21"
        Java(TM) SE Runtime Environment (build 1.6.0_21-b06)
        Java HotSpot(TM) Client VM (build 17.0-b16, mixed mode, sharing)

        C:\Documents and Settings\Administrator>javac dummy.java
        javac: file not found: dummy.java
        Usage: javac <options> <source files>
        use -help for a list of possible options

        As for the rest of the comments, I'll look into them and make corrections wherever required.

        Show
        Prashanth KS added a comment - Please note that these tests are for the javac and javaw executables. So ecj.jar wouldn't be having those messages. Please find the output of the Sun JRE pasted below: C:\Documents and Settings\Administrator>java -version java version "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Java HotSpot(TM) Client VM (build 17.0-b16, mixed mode, sharing) C:\Documents and Settings\Administrator>javac dummy.java javac: file not found: dummy.java Usage: javac <options> <source files> use -help for a list of possible options As for the rest of the comments, I'll look into them and make corrections wherever required.
        Hide
        Mark Hindess added a comment -

        You can either use the exclude lists - i.e. add the javaw test name to exclude files for non-windows platforms - or split the test sources in to common, unix, windows directories as has been done in for example classlib/modules/

        {auth,misc,nio}

        .

        To avoid going around this loop to many times I've reviewed the javac test in more detail. Some comments in no particular order.

        These tests do not pass on linux (or windows I'd assume) with the
        federated build.

        The test_nonExists method asserts that the error output contains the
        string "not found", but the output actually says:

        File no_this_test.java is missing

        Checking the ecj jar in the federated build I find:

        bash$ unzip -p target/hdk/jdk/lib/ecj-3.5.1.jar |grep 'not found'
        bash$ unzip -p target/hdk/jdk/lib/ecj-3.5.1.jar |grep 'is missing'
        Binary file (standard input) matches

        so I'm not sure where the "not found" message you are testing for
        might be coming from?

        Why is errOutput returned from runExe as a StringBuilder? I may be
        missing something but it looks like the callers only use
        errOutput.toString() - currently several times - when you could just
        return the string.

        getProcessOutput should take Process as the first argument not the
        Object since it only uses the Process element of the Object array.

        Since all runExe callers call getProcessOutput why not have runExe
        take a displayOutput boolean and then return:

        { proc, getProcessOutput(proc, displayOutput), errBuf.toString() }

        (Perhaps proc is no longer needed but perhaps you might also want to
        check the exit status on some tools?) I'd be a little tempted to
        trim the error output string too.

        Can you break up the assertTrue asserts? What you have at the moment
        is the junit equivalent of:

        if (A || B)

        { System.err.println("A or B is wrong"); ... }

        which is a pet hate of mine. For example (assuming errOutput is now
        a string for brevity!):

        assertTrue("The output should have " + testStr + " Error - " + errOutput,
        errOutput.contains(testStr) && toString().contains("is missing") );

        should become:

        assertTrue("The output should contain \"" + testStr + "\" Error - \""
        + errOutput + "\"",
        errOutput.contains(testStr));
        assertTrue("The output should contain \"is missing\" Error - \""
        + errOutput + "\"",
        errOutput.contains("is missing"));

        ditto for several other asserts.

        It might be better to consistently name variables such as "stdOut" and
        "errOutput". Those names seem rather confused. Perhaps "stdOut" and
        "stdErr"?

        Typical style for Harmony code tends to have the opening curly bracket
        of a method on the end of the line not on a line on its own.

        Rather than use a displayOutput boolean, it might be better to replace
        the asserts with something more verbose such as:

        if (!errOutput.contains(testStr))

        { System.err.println("Output: " + stdOut); System.err.println("Errors: " + errOutput); fail("The output should contain \"" + testStr + "\""); }

        so that if/when the test fails we get the information required to
        debug the failure - rather than having to rebuild the test.

        What is the benefit of writing the tests as:

        final String srcFile = RESOURCES + "Simple.java";
        final File f = new File(srcFile);
        final String testStr = f.getAbsolutePath();

        rather than:

        final String testStr = RESOURCES + "Simple.java";

        That is, don't create File objects and just use relative paths?
        Similarly for things like:

        final String classFile = f.getParent() + "
        Sample.class";
        final File clsFile = new File(classFile);

        which only works on windows - because of the '\' char - rather than:

        final File clsFile = new File(RESOURCES + "Sample.class");

        Please can you use four spaces rather than tabs as is typical
        Harmony style.

        Show
        Mark Hindess added a comment - You can either use the exclude lists - i.e. add the javaw test name to exclude files for non-windows platforms - or split the test sources in to common, unix, windows directories as has been done in for example classlib/modules/ {auth,misc,nio} . To avoid going around this loop to many times I've reviewed the javac test in more detail. Some comments in no particular order. These tests do not pass on linux (or windows I'd assume) with the federated build. The test_nonExists method asserts that the error output contains the string "not found", but the output actually says: File no_this_test.java is missing Checking the ecj jar in the federated build I find: bash$ unzip -p target/hdk/jdk/lib/ecj-3.5.1.jar |grep 'not found' bash$ unzip -p target/hdk/jdk/lib/ecj-3.5.1.jar |grep 'is missing' Binary file (standard input) matches so I'm not sure where the "not found" message you are testing for might be coming from? Why is errOutput returned from runExe as a StringBuilder? I may be missing something but it looks like the callers only use errOutput.toString() - currently several times - when you could just return the string. getProcessOutput should take Process as the first argument not the Object since it only uses the Process element of the Object array. Since all runExe callers call getProcessOutput why not have runExe take a displayOutput boolean and then return: { proc, getProcessOutput(proc, displayOutput), errBuf.toString() } (Perhaps proc is no longer needed but perhaps you might also want to check the exit status on some tools?) I'd be a little tempted to trim the error output string too. Can you break up the assertTrue asserts? What you have at the moment is the junit equivalent of: if (A || B) { System.err.println("A or B is wrong"); ... } which is a pet hate of mine. For example (assuming errOutput is now a string for brevity!): assertTrue("The output should have " + testStr + " Error - " + errOutput, errOutput.contains(testStr) && toString().contains("is missing") ); should become: assertTrue("The output should contain \"" + testStr + "\" Error - \"" + errOutput + "\"", errOutput.contains(testStr)); assertTrue("The output should contain \"is missing\" Error - \"" + errOutput + "\"", errOutput.contains("is missing")); ditto for several other asserts. It might be better to consistently name variables such as "stdOut" and "errOutput". Those names seem rather confused. Perhaps "stdOut" and "stdErr"? Typical style for Harmony code tends to have the opening curly bracket of a method on the end of the line not on a line on its own. Rather than use a displayOutput boolean, it might be better to replace the asserts with something more verbose such as: if (!errOutput.contains(testStr)) { System.err.println("Output: " + stdOut); System.err.println("Errors: " + errOutput); fail("The output should contain \"" + testStr + "\""); } so that if/when the test fails we get the information required to debug the failure - rather than having to rebuild the test. What is the benefit of writing the tests as: final String srcFile = RESOURCES + "Simple.java"; final File f = new File(srcFile); final String testStr = f.getAbsolutePath(); rather than: final String testStr = RESOURCES + "Simple.java"; That is, don't create File objects and just use relative paths? Similarly for things like: final String classFile = f.getParent() + " Sample.class"; final File clsFile = new File(classFile); which only works on windows - because of the '\' char - rather than: final File clsFile = new File(RESOURCES + "Sample.class"); Please can you use four spaces rather than tabs as is typical Harmony style.
        Hide
        Prashanth KS added a comment -

        Is there anything that needs to be done to make sure that these javaw tests work only on Windows and not on other platforms? And javac tests need to be run on all platforms.

        Show
        Prashanth KS added a comment - Is there anything that needs to be done to make sure that these javaw tests work only on Windows and not on other platforms? And javac tests need to be run on all platforms.
        Hide
        Mark Hindess added a comment -

        I don't see a need for our (community) jdk to include a javaw on unix platforms. The RI doesn't seem to include one. Why would we want one? What purpose would it serve?

        Therefore, the javaw tests should be windows only.

        If you want to do something different for your private builds then that is irrelevant to this JIRA.

        Show
        Mark Hindess added a comment - I don't see a need for our (community) jdk to include a javaw on unix platforms. The RI doesn't seem to include one. Why would we want one? What purpose would it serve? Therefore, the javaw tests should be windows only. If you want to do something different for your private builds then that is irrelevant to this JIRA.
        Hide
        Prashanth KS added a comment -

        For the example above, I was not using a community build. I was using an IBM JDK installed on Linux.
        I thought javaw tests can be run with IBM JDK , SUN JDK and then on a Harmony build for a comparitive analysis. That's the reason I wrote these tests. I ran all these tests on Windows.

        I am not aware that we dont have a "javaw" process for Unix flavours in the community build. I thought we would be having one, in par with the other JDKs. Kindly clarify the above.

        Show
        Prashanth KS added a comment - For the example above, I was not using a community build. I was using an IBM JDK installed on Linux. I thought javaw tests can be run with IBM JDK , SUN JDK and then on a Harmony build for a comparitive analysis. That's the reason I wrote these tests. I ran all these tests on Windows. I am not aware that we dont have a "javaw" process for Unix flavours in the community build. I thought we would be having one, in par with the other JDKs. Kindly clarify the above.
        Hide
        Mark Hindess added a comment -

        What build are you using, if I do a federated build like so:

        svn checkout https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk federated
        cd federated
        ant fetch-depends build
        find target -name javaw -print

        The find command finds no 'javaw' command. How does this work for you?

        Furthermore, there are two makefiles in:

        federated/classlib/modules/luni/src/main/native/launcher/windows

        one for java and one for javaw but in:

        federated/classlib/modules/luni/src/main/native/launcher/unix

        there is only a java one.

        Show
        Mark Hindess added a comment - What build are you using, if I do a federated build like so: svn checkout https://svn.apache.org/repos/asf/harmony/enhanced/java/trunk federated cd federated ant fetch-depends build find target -name javaw -print The find command finds no 'javaw' command. How does this work for you? Furthermore, there are two makefiles in: federated/classlib/modules/luni/src/main/native/launcher/windows one for java and one for javaw but in: federated/classlib/modules/luni/src/main/native/launcher/unix there is only a java one.
        Hide
        Prashanth KS added a comment -

        I misunderstood your comment. javaw is present in Linux as well and just called "javaw" with execute permissions. "javac" is named the same way.

        Here's an output from a Linux machine

        [root@wincorp11 bin]# ./javaw -version
        java version "1.5.0"
        Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20070511(SR5))
        IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426 (JIT enabled)
        J9VM - 20070420_12448_lHdSMR
        JIT - 20070419_1806_r8
        GC - 200704_19)
        JCL - 20070511

        Show
        Prashanth KS added a comment - I misunderstood your comment. javaw is present in Linux as well and just called "javaw" with execute permissions. "javac" is named the same way. Here's an output from a Linux machine [root@wincorp11 bin] # ./javaw -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20070511(SR5)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070426 (JIT enabled) J9VM - 20070420_12448_lHdSMR JIT - 20070419_1806_r8 GC - 200704_19) JCL - 20070511
        Hide
        Mark Hindess added a comment -

        I don't see how this patch addresses my previous comment:

        javaw.exe is windows only isn't it?

        Show
        Mark Hindess added a comment - I don't see how this patch addresses my previous comment: javaw.exe is windows only isn't it?
        Prashanth KS made changes -
        Attachment 002_HARMONY_6620.patch [ 12452256 ]
        Hide
        Prashanth KS added a comment -

        The .exe extension is not required. The Runtime.exec process searches for an executable corresponding to the name that is supplied to the exec call. This patch should make this test run on all platforms.

        Kindly use the resources from resources.zip

        Show
        Prashanth KS added a comment - The .exe extension is not required. The Runtime.exec process searches for an executable corresponding to the name that is supplied to the exec call. This patch should make this test run on all platforms. Kindly use the resources from resources.zip
        Hide
        Mark Hindess added a comment -

        javaw.exe is windows only isn't it?
        javac.exe is called javac on unix?

        Show
        Mark Hindess added a comment - javaw.exe is windows only isn't it? javac.exe is called javac on unix?
        Prashanth KS made changes -
        Field Original Value New Value
        Attachment 001_HARMONY_6620.patch [ 12451939 ]
        Attachment resources.zip [ 12451940 ]
        Hide
        Prashanth KS added a comment -

        001_HARMONY_6620.patch – Patch that has information on new and changed files to be added

        1) jdktools/modules/jdktools/src/test/java/org/apache/harmony/tests/tools/javac/binary/JavacBinTest.java

        2) jdktools/modules/jdktools/src/test/java/org/apache/harmony/tests/tools/javaw/binary/JavawBinTest.java

        3) jdktools/modules/jdktools/src/test/resources/Sample.java

        resources.zip – To be unzipped into the resources folder
        -------------------
        jdktools/modules/jdktools/src/test/resources/Dependency.jar
        jdktools/modules/jdktools/src/test/resources/Sample_resolved.jar
        jdktools/modules/jdktools/src/test/resources/Sample_unresolved.jar
        jdktools/modules/jdktools/src/test/resources/Simple.jar

        Show
        Prashanth KS added a comment - 001_HARMONY_6620.patch – Patch that has information on new and changed files to be added 1) jdktools/modules/jdktools/src/test/java/org/apache/harmony/tests/tools/javac/binary/JavacBinTest.java 2) jdktools/modules/jdktools/src/test/java/org/apache/harmony/tests/tools/javaw/binary/JavawBinTest.java 3) jdktools/modules/jdktools/src/test/resources/Sample.java resources.zip – To be unzipped into the resources folder ------------------- jdktools/modules/jdktools/src/test/resources/Dependency.jar jdktools/modules/jdktools/src/test/resources/Sample_resolved.jar jdktools/modules/jdktools/src/test/resources/Sample_unresolved.jar jdktools/modules/jdktools/src/test/resources/Simple.jar
        Prashanth KS created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Prashanth KS
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development