JDK-8253566 : clazz.isAssignableFrom will return false for interface implementors
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 15,16
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2020-09-22
  • Updated: 2020-11-11
  • Resolved: 2020-10-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15 JDK 16
15.0.2Fixed 16 b20Fixed
Related Reports
Relates :  
JDK-8238691 - C2: turn subtype check into macro node
Description
A DESCRIPTION OF THE PROBLEM :
I create an web application on tomcat server with spring framework and hibernate validation.
I have an interface which define method with javax.validation Annotations.

We use Hibernate-validation to check methods:
executableValidator.validateParameters(target, method, args);

see https://github.com/hibernate/hibernate-validator/blob/7987755f0617504b567f2a5a0437d8695659e4ce/engine/src/main/java/org/hibernate/validator/internal/metadata/aggregated/rule/MethodConfigurationRule.java#L73-L77

Sometime we will get the wrong result and a ConstraintDeclarationException is thrown.
I checked that all use same classloader. This also happen with debugger but if I evaluate toString for one of class the result will be correct.

With 14.0.2 I didn't see this behaviour. After Upgrade to jdk15 this will occurs often after restart the server.

 that implements i

REGRESSION : Last worked in version 14.0.2


FREQUENCY : often
Comments
Fix Request (15u) This fixes a new regression introduced in 15. The backport applies cleanly to 15u, passes tier{1,2} tests, new test fails without the patch, passes with it.
21-10-2020
Yes, this should be backported to 15.0.2.
13-10-2020
Changeset: f8603720 Author: Roland Westrelin <roland@openjdk.org> Date: 2020-10-08 09:33:42 +0000 URL: https://git.openjdk.java.net/jdk/commit/f8603720
08-10-2020
ILW = Wrong result with C2 compiled code (regression in JDK 15), rare case but reproducer available, -XX:+ExpandSubTypeCheckAtParseTime = HML = P2
29-09-2020
The submitter provided the sample at: https://github.com/MCMicS/openjdk-8253566
29-09-2020
Gunnar Morling asked me to reproduce it, and I can on modified hibernate-validator tests. Bisected it to JDK-8238691, which makes -XX:+ExpandSubTypeCheckAtParseTime a workaround. 52d46c314b0f9b46544695609d063ac89bcd5dd7 is the first bad commit commit 52d46c314b0f9b46544695609d063ac89bcd5dd7 Author: Roland Westrelin <roland@openjdk.org> Date: Fri Feb 14 10:31:34 2020 +0100 8238691: C2: turn subtype check into macro node Steps to reproduce: $ git clone https://github.com/gunnarmorling/hibernate-validator.git $ git checkout booleanoddity $ export JAVA_HOME=... (point to current jdk build, 16+ should build fine) $ export PATH=$JAVA_HOME/bin:$PATH $ mvn clean install -pl engine -am -Dcheckstyle.skip -Dforbiddenapis.skip Observe the exceptions: [ERROR] testInterfaceConfiguration(org.hibernate.validator.test.internal.xml.XmlMappingTest) Time elapsed: 0.001 s <<< FAILURE! java.lang.IllegalStateException: Cannot happen at org.hibernate.validator.test.internal.xml.XmlMappingTest.testInterfaceConfiguration(XmlMappingTest.java:101)
28-09-2020
The response from the submitter: I filled up one there: https://hibernate.atlassian.net/browse/HV-1801 Still try to reproduce it. I strip our application but if not all classes are loaded in classloader it works. ( ~ 3800 classes work, ~ 16000 classes fails)
28-09-2020
[~tongwan] I think this one will need someone in Hibernate to duplicate and narrow down the issue. Can you find out if the submitter has submitted a bug to Hibernate Validation that we can link too?
25-09-2020
The response from the submitter: We use v55 class files but changed only the runtime to Java15.
25-09-2020
"use AOP to validate parameters" suggests there might be byte code instrumentation in the picture. It would be useful to know if the Hibernate Validator and APO has been tested with JDK 15 and v59 class files.
25-09-2020
The response from the submitter: Currently cannot give more information. Try to reproduce it with Sample to share with you. My last insights are that this happens on windows and macos. On linux we couldn't reproduce this with our software. We only have an war artifact which raise this error but this is an comercial one which I cannot send you for test. Are there any Flags to set to enable more log which can help you to get more informations? But I can give some environment details: Windows 10 and macOS Catalina use Spring 5.2.9, Hibernate Validator 6.1.5, use AOP to validate parameters Runs on Tomcat 9.0.38 fails with jdk15-ea+16-681, jdk15+36-1562, 16-ea+16-712 Validate Parameters: > final Validator baseValidator = validator.unwrap(Validator.class); > final ExecutableValidator executableValidator = baseValidator.forExecutables(); > violations.addAll(executableValidator.validateParameters(target, method, args)); If I found any additional hints I will send this to you
24-09-2020
Does the submitter have any contacts with the Hibernate folks to help diagnose this one a bit further? It would be really useful to get this one narrowed down as have some idea whether this is a JDK, Hibernate, or other issue.
24-09-2020
More information from the submitter: I've attached from breakpoint at 'ParallelMethodsMustNotDefineParameterConstraints' the method 'isDefinedOnParallelType' returns true but the 'WorkspaceEditor.class.isAssignableFrom(WorkspaceEditorBean.class)' return also true which should lead to return 'isDefinedOnParallelType' to false. Still try to reproduce it with smaller sample
24-09-2020
Further information from the submitter: I've not found simple steps to reproduce it but I will try to create a sample application. Currently it happen with our product which is not available public. I can send you additional logs with the stacktrace. But I have an local environment with debugging enabled for this. Maybe an screensharing wolud be possible. Or are there any flags to enable verbose for 'isAssignableFrom'? If I stop in debugger and evaluate some expression it still works. I've used 15-ea16 for month but didn't saw this error. But with the release (Build 36) in 1 of 5 server restarts.
24-09-2020
Requested more details of reproducing the issue from the submitter.
23-09-2020