RFR(S): JDK-8133180 - [TESTBUG] runtime/SharedArchiveFile/SharedStrings.java failed with WhiteBox.class : no such file or directory

[Mikhailo Seledtsov]

Jiangli,

  Thank you for a quick reply.

I have updated the webrev accordingly:
    http://cr.openjdk.java.net/~mseledtsov/8133180.01/

Testing:
     - ran the test with b75 (internal and openjdk)
     - ran the "easy reproducer" discussed in a bug
         rm -Rf JT* test
         jtreg //hs-rt/hotspot/test/testlibrary_tests/ctw/JarDirTest.java
         jtreg 
//hs-rt/hotspot/test/runtime/SharedArchiveFile/SharedStrings.java
     - RBT of CDS tests - in progress

Thank you,
Misha

On 8/28/2015 2:48 PM, Jiangli Zhou wrote:
> Hi Misha,
>
> Your proposal sounds good.
>
> Thanks,
> Jiangli
>
>> On Aug 28, 2015, at 12:38 PM, Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com> wrote:
>>
>> Hi Jiangli,
>>
>> I am back to this task after working on other stuff.
>> As I started experimenting with your suggestions, I have found one potential problem.
>> The fallback strategy that you suggest could create an ambiguity.
>>
>> For instance, there may be cases where both @build+ClassFileInstaller and @compile is used. The CFI will place classes in the current working directory, aka ".", where is @compile will place them under JTwork/../currentTest/classes/..
>> In such cases, the test author will probably need to create 2 jars, one for classes in the local directory, and another for classes in the "@compile", and may want to be explicit what goes where, instead of JarBuilder trying to guess and leading to possible ambiguity and confusion.
>>
>> The key to solving this problem is to never assume the location of classes produced by @build. If using @build, the classes MUST be copied to the "." using ClassFileInstaller, since @build does not guarantee the presence of these classes in a specific location. Perhaps, the best solution here is to require all classes used by the JarBuilder to be in the "." directory, and require the test author to use ClassFileInstaller when necessary. In such cases, if the class is not in the test's current directory, the error will become obvious immediately instead of under some occasional conditions in the test system. It will also greatly simplify the tests and will make them more robust.
>>
>> Please let me know comments/objections on such approach.
>>
>> Thank you,
>> Misha
>>
>>
>> On 8/17/2015 6:18 PM, Mikhailo Seledtsov wrote:
>>> Hi Jiangli,
>>>
>>> Thank you for your suggestion; it should make testing more robust.
>>> I will try your suggestion; if I do not see any undesired side effects I will rerun full testset and re-submit the updated review.
>>>
>>> Thank you,
>>> Misha
>>>
>>> On 8/14/2015 5:43 PM, Jiangli Zhou wrote:
>>>> Hi Misha,
>>>>
>>>> I have one suggestion. Instead of searching either the ‘work’ or ‘classes’  directory depending on the ‘classesInWorkDir’ argument, how about searching both directories? So the BasicJarBuilder.build() method would use the ‘classes’ directory first, then try the ‘work’ directory if the file cannot be found in ‘classes'. That might be a more robust solution.
>>>>
>>>> Thanks,
>>>> Jiangli
>>>>
>>>> On Aug 14, 2015, at 2:22 PM, Mikhailo Seledtsov <mikhailo.seledtsov at oracle.com> wrote:
>>>>
>>>>> Please review this fix to the CDS test bug. See the comments in the bug for details.
>>>>>
>>>>>     JBS: https://bugs.openjdk.java.net/browse/JDK-8133180
>>>>>     Webrev: http://cr.openjdk.java.net/~mseledtsov/8133180.00/
>>>>>     Testing:
>>>>>         - ran the reproducer discussed in the bug description
>>>>>             rm -Rf JT* test
>>>>>             jtreg /media/data3/hg/9/work01/hs-rt/hotspot/test/testlibrary_tests/ctw/JarDirTest.java
>>>>>             jtreg /media/data3/hg/9/work01/hs-rt/hotspot/test/runtime/SharedArchiveFile/SharedStrings.java
>>>>>
>>>>>         - ran the CDS tests in concurrent mode
>>>>>         - running CDS tests via multi-platform build-and-test system
>>>>>             (in progress)
>>>>>
>>>>> Thank you,
>>>>> Misha