Thanks David!
Then test will be excluded for now for jdk8u on compact1 and compact2
profiles.
Sincerely yours,
Ivan
On 30.06.2015 8:56, David Holmes wrote:
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
