On 25/06/2015 8:29 PM, Ivan Gerasimov wrote:
Hi David!
The test fails when reading content of existing jsse.jar, which belongs
to compact3 profile.
When the test loads classes from this jar and tries to access their
fields, it hits the types that are not included in compact[12], thus
NoClassDefFoundError.
I'm not certain, if it is a bug that jsse.jar is referenced from
"sun.boot.class.path" when the application is run in compact[12] profiles.
To be clear here, jsse.jar belongs in compact1, however it has some
references to types that exist only in compact3 - hence when those
fields get processed we hit the bug when running on compact 1/2.
Only thing unclear now is why this is suddenly happening - has this test
never been run on the compact profiles before?
As to a fix ... I'm okay with excluding the test from running on compact
1/2, now I understand the problem.
Thanks,
David
Sincerely yours,
Ivan
On 25.06.2015 8:43, David Holmes wrote:
Hi Ivan,
On 25/06/2015 4:11 AM, Ivan Gerasimov wrote:
Hello!
This test fails when running on compact1 and compact2, since it tries to
access all the jars from "sun.boot.class.path".
The easiest approach would be to include it in the group, which requires
at least compact3.
Easy yes but is it correct? This is a basic core reflection test that
should be executable on any compact profile. There are three things
here that concern me:
a) why does boot.class.path include non-existent jar files?
b) why don't non-existent jar files simply increment the "skipped"
count, which is not considered a test failure?
c) what changed to make this start failing?
Thanks,
David
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080524
WEBREV: http://cr.openjdk.java.net/~igerasim/8080524/00/webrev/
Sincerely yours,
Ivan
