RFR: 8159523. Fix tests depending on absence of -limitmods in VM arguments.

Alexandre (Shura) Iline alexandre.iline at oracle.com
Tue Mar 7 01:27:07 UTC 2017


Hi,

Could you please review the suggested fox for: https://bugs.openjdk.java.net/browse/JDK-8159523

There has been a bit of discussion on jigsaw-dev, but it perhaps make sense to include core-libs-dev.

There have been some fixes since the review was published, so we are now at revision #4:
http://cr.openjdk.java.net/~shurailine/8159523/webrev.04/

The background for this fix is sufficiently captured in the original e-mail:
> 1. An attempt was made to enhance jdk.testlibrary.ProcessTools class to support some filtering java and VM options. That implementation came out really overloaded (check executeModularTest(...) in [1]).
> 2. It was suggested that a builder API could be introduced instead. “toolbox” classes from langtools test library were suggested as a start [2].
> 3. Further on, it was agreed that the classes need to be copied into the JDK test library rather than updated in place or somehow else shared between langtools and jdk test libraries.

Quite recently the suggested improvement was discussed with a few folks from hotspot team where the same or a similar implementation could be reused. I am CCing Igor and Dima to comment.

Thank you

Shura


> Hi,
> 
> Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8159523
> 
> To recap what has happened in the past.
> 
> 1. An attempt was made to enhance jdk.testlibrary.ProcessTools class to support some filtering java and VM options. That implementation came out really overloaded (check executeModularTest(...) in [1]).
> 2. It was suggested that a builder API could be introduced instead. “toolbox” classes from langtools test library were suggested as a start [2].
> 3. Further on, it was agreed that the classes need to be copied into the JDK test library rather than updated in place or somehow else shared between langtools and jdk test libraries.
> 
> I have started porting a few tasks (JavaTask, JavacTask and JarTask) only to realize that there are many questions which may cause design discussions. So, instead, I have rolled back to one class (JavaTask) and the superclasses. If the design is acceptable, more tasks could be added as needed.
> 
> The webrev: http://cr.openjdk.java.net/~shurailine/8159523/webrev.01
> 
> Thank you.
> 
> Shura
> 
> [1] http://cr.openjdk.java.net/~shurailine/8159523/webrev.00/test/lib/testlibrary/jdk/testlibrary/ProcessTools.java.sdiff.html
> 
> [2] http://hg.openjdk.java.net/jdk9/jdk9/langtools/file/8e9e1a2373a4/test/tools/lib/toolbox



More information about the core-libs-dev mailing list