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

[Mikhailo Seledtsov]

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
>