[ https://issues.jboss.org/browse/ELY-1569?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1569: ------------------------------ Description: Reason why it was added may be fixed in OpenJDK already. David thinks so, but I was not able to find issue for that. Note, this was needed for older java 1.8 releases. So user with older java in use can experience problems with fixed Elytron. Must migrate to newer version of java. {code:java|title=X500PrncipalUtil} static { Class<?> x500Name = null; MethodHandle asX500PrincipalHandle = null; try { x500Name = Class.forName("sun.security.x509.X500Name", true, X500PrincipalUtil.class.getClassLoader()); asX500PrincipalHandle = MethodHandles.publicLookup().unreflect(x500Name.getDeclaredMethod("asX500Principal")); } catch (Throwable t) { /* * This is intended to be a best efforts optimisation, if it fails for ANY reason we don't support the optimisation * and resort to default behaviour. * * Throwing any Exception or Error from this static block results in a NoClassDefFoundError for any access to the * class and subsequently even the non-optimised scenario is unavailable. */ log.trace("X550Name.asX500Principal() is not available.", t); } X500_NAME_CLASS = x500Name; AS_X500_PRINCIPAL_HANDLE = asX500PrincipalHandle; } {code} Related hipchat discussion {noformat} David Lloyd·Apr-26 3:44 PM what JDK version? that's not really an error per se Darran Lofthouse·Apr-26 3:46 PM it's a feature ;-) David Lloyd·Apr-26 3:47 PM tbh it's probably not needed anymore; the original code there is 3 years old Martin Choma·Apr-26 3:48 PM java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) David Lloyd·Apr-26 3:48 PM I think the original issue was fixed in openjdk a while back Martin Choma·Apr-26 4:57 PM David, I can see the exception on the Oracle JDK 1.8.0_172 as well Darran Lofthouse·Apr-26 5:05 PM Is the optimisation provided by that class still beneficial? David Lloyd·Apr-26 5:11 PM it's required for older 1.8 releases note that it's a TRACE message though it's not an error, it's just indicating that the detection of the internal type failed so it won't be used I did previously get a directive that we need not support older 1.8 releases though so we could drop that code if desired this would be considered code cleanup, so it's not an enhancement and not a bug fix Martin Choma·Apr-26 5:20 PM "1.8 releases" you mean jboss-modules 1.8? and when searching internal type failed, which will be used then? Darran Lofthouse·Apr-26 5:22 PM If that type is not found and convert set to true we pass the name into the X500Principal constructor David Lloyd·Apr-26 5:24 PM no @MartinChoma I mean older Java 8 releases older versions of Java returned X500Name for certain certificate methods instead of X500Principal if you weren't ready for that, you can end up with an unexpected error condition Martin Choma·Apr-26 5:32 PM and now as jdk is fixed we can remove that workaround? David Lloyd·Apr-26 5:32 PM yes it should be safe Martin Choma·Apr-26 5:34 PM also for ibm jdk? David Lloyd·Apr-26 5:34 PM IBM never had the problem AFAIK Martin Choma·Apr-26 5:50 PM It would be nice if we know the JDK issue, but I can't find the one. {noformat} was: Reason why it was added may be fixed in OpenJDK already. David thinks so, but I was not able to find issue for that. Note, this was needed for older java 1.8 releases. So user with older java in use can experience problems with fixed Elytron. Must migrate to newer version of java. {code} static { Class<?> x500Name = null; MethodHandle asX500PrincipalHandle = null; try { x500Name = Class.forName("sun.security.x509.X500Name", true, X500PrincipalUtil.class.getClassLoader()); asX500PrincipalHandle = MethodHandles.publicLookup().unreflect(x500Name.getDeclaredMethod("asX500Principal")); } catch (Throwable t) { /* * This is intended to be a best efforts optimisation, if it fails for ANY reason we don't support the optimisation * and resort to default behaviour. * * Throwing any Exception or Error from this static block results in a NoClassDefFoundError for any access to the * class and subsequently even the non-optimised scenario is unavailable. */ log.trace("X550Name.asX500Principal() is not available.", t); } X500_NAME_CLASS = x500Name; AS_X500_PRINCIPAL_HANDLE = asX500PrincipalHandle; } {code} Related hipchat discussion {noformat} David Lloyd·Apr-26 3:44 PM what JDK version? that's not really an error per se Darran Lofthouse·Apr-26 3:46 PM it's a feature ;-) David Lloyd·Apr-26 3:47 PM tbh it's probably not needed anymore; the original code there is 3 years old Martin Choma·Apr-26 3:48 PM java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode) David Lloyd·Apr-26 3:48 PM I think the original issue was fixed in openjdk a while back Martin Choma·Apr-26 4:57 PM David, I can see the exception on the Oracle JDK 1.8.0_172 as well Darran Lofthouse·Apr-26 5:05 PM Is the optimisation provided by that class still beneficial? David Lloyd·Apr-26 5:11 PM it's required for older 1.8 releases note that it's a TRACE message though it's not an error, it's just indicating that the detection of the internal type failed so it won't be used I did previously get a directive that we need not support older 1.8 releases though so we could drop that code if desired this would be considered code cleanup, so it's not an enhancement and not a bug fix Martin Choma·Apr-26 5:20 PM "1.8 releases" you mean jboss-modules 1.8? and when searching internal type failed, which will be used then? Darran Lofthouse·Apr-26 5:22 PM If that type is not found and convert set to true we pass the name into the X500Principal constructor David Lloyd·Apr-26 5:24 PM no @MartinChoma I mean older Java 8 releases older versions of Java returned X500Name for certain certificate methods instead of X500Principal if you weren't ready for that, you can end up with an unexpected error condition Martin Choma·Apr-26 5:32 PM and now as jdk is fixed we can remove that workaround? David Lloyd·Apr-26 5:32 PM yes it should be safe Martin Choma·Apr-26 5:34 PM also for ibm jdk? David Lloyd·Apr-26 5:34 PM IBM never had the problem AFAIK Martin Choma·Apr-26 5:50 PM It would be nice if we know the JDK issue, but I can't find the one. {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)