RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles
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. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080524 WEBREV: http://cr.openjdk.java.net/~igerasim/8080524/00/webrev/ Sincerely yours, Ivan
Looks ok to me Ivan. Is this required for JDK 9 also ? If not, please add 9-na label. Approved. Regards, Sean. On 24/06/2015 19:11, 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.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080524 WEBREV: http://cr.openjdk.java.net/~igerasim/8080524/00/webrev/
Sincerely yours, Ivan
Thanks Seán! Added 9-na and noreg labels. Sincerely yours, Ivan On 24.06.2015 23:47, Seán Coffey wrote:
Looks ok to me Ivan. Is this required for JDK 9 also ? If not, please add 9-na label.
Approved.
Regards, Sean.
On 24/06/2015 19:11, 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.
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080524 WEBREV: http://cr.openjdk.java.net/~igerasim/8080524/00/webrev/
Sincerely yours, Ivan
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
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. 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
On 25/06/2015 11:29, 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. Are these the same dangling references that are listed in 8u's make/data/checkdeps/refs.allowed? It wasn't possible to get these issues fixed in 8u but they have been addressed in 9.
Separately, I hope that this section from TEST.groups will eventually go away in 9. -Alan
On 25.06.2015 15:58, Alan Bateman wrote:
On 25/06/2015 11:29, 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. Are these the same dangling references that are listed in 8u's make/data/checkdeps/refs.allowed? It wasn't possible to get these issues fixed in 8u but they have been addressed in 9.
Yes. This is it! Would it make sense then to simply skip jsse.jar when executing the test in compact[12]? I guess It should be possible to determine that by checking the properties profile.compact1 and profile.compact2 aren't nulls. Sincerely yours, Ivan
Separately, I hope that this section from TEST.groups will eventually go away in 9.
-Alan
On 25/06/2015 14:08, Ivan Gerasimov wrote:
Yes. This is it! Would it make sense then to simply skip jsse.jar when executing the test in compact[12]? I guess It should be possible to determine that by checking the properties profile.compact1 and profile.compact2 aren't nulls.
There aren't any defined properties for when running with a compact profile but you could look in the top-level release file or check for specific classes. It might not be worth it though and excluding it as you originally proposed might be okay. -Alan
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
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
participants (4)
-
Alan Bateman
-
David Holmes
-
Ivan Gerasimov
-
Seán Coffey