JDK12 b14 java.lang.NoSuchFieldException: override about jboss-classfilewriter HOT 14 CLOSED

Immediate fix is to use setAccessible until things are locked down.

from jboss-classfilewriter.

The same problem also occurred in weld-core.
org/jboss/weld/util/bytecode/ClassFileUtils

from jboss-classfilewriter.

I see the same issue when when running WF build + TS on JDK 12 (WildFly Test Suite: Integration - Smoke) - org.jboss.as.test.smoke.webservices.WSTestCase

Caused by: java.lang.NoSuchFieldException: override
	at java.base/java.lang.Class.getDeclaredField(Class.java:2410)
	at [email protected]//org.jboss.classfilewriter.
                    ClassFile$1.run(ClassFile.java:392)

@stuartwdouglas @dmlloyd

https://github.com/jbossas/jboss-classfilewriter/blob/master/src/main/java/org/jboss/classfilewriter/ClassFile.java#L392

from jboss-classfilewriter.

Plus there are twelve Could not initialize class org.jboss.classfilewriter.ClassFile errors in smoke module.

Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.jboss.classfilewriter.ClassFile
	at [email protected]//org.jboss.as.ejb3.iiop.handle.SerializationHackProxy.proxy(SerializationHackProxy.java:55)
	at [email protected]//org.jboss.as.ejb3.iiop.handle.HandleDelegateImpl.<init>(HandleDelegateImpl.java:58)
	at [email protected]//org.jboss.as.ejb3.deployment.processors.IIOPJndiBindingProcessor.bindService(IIOPJndiBindingProcessor.java:108)
	at [email protected]//org.jboss.as.ejb3.deployment.processors.IIOPJndiBindingProcessor.deploy(IIOPJndiBindingProcessor.java:83)
	at [email protected]//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144)
	... 8 more

from jboss-classfilewriter.

@manovotn / @mkouba fyi:

The same problem also occurred in weld-core.
org/jboss/weld/util/bytecode/ClassFileUtils

from jboss-classfilewriter.

Thanks for the heads-up Rostislav, haven't checked JDK 12 and Weld quite yet.

from jboss-classfilewriter.

@stuartwdouglas @dmlloyd any chance you could look into this ? I know you are super busy ...

from jboss-classfilewriter.

Immediate fix is to use setAccessible until things are locked down.

You cannot use setAccessible for you will get an exception trying to invoke a protected method(defineClass()) on a CL. That's why Unsafe was used in the first place. Unless I am missing something, which might well be the case :)

from jboss-classfilewriter.

Until things are locked down, changing to use setAccessible works fine.
After things are locked down, it will be necessary to open packages but it will still provide something that works.
The current code doesn't work at all. It's a simple change.
// make both accessible
defineClass1.setAccessible(true);
defineClass2.setAccessible(true);

from jboss-classfilewriter.

That's what was there until 1.2.1.Final but was deliberately changed. I don't think we want to just revert that.

from jboss-classfilewriter.

At least within WildFly, we can use the ClassDefiner API in JBoss Modules to define classes without cheating or getting warnings, or worrying about getting locked out.

I'll try to get a patch going as soon as I can scrape a couple minutes together.

from jboss-classfilewriter.

@bstansberry @kabir if WF 16 going to tackle Java 12 ?
https://openjdk.java.net/projects/jdk/12/ - 2019/03/19 General Availability

btw there is already http://jdk.java.net/13/

from jboss-classfilewriter.

@rsvoboda If "tackle" means try and identify and work through issues running on 12, yes. If it means support it the way WF 15 supports 11, no. IMHO our goal should be to support the LTS JDK releases as soon as we can after they come out. If we can exceed that goal great, but that's just a bonus.

WildFly tracker for this is https://issues.jboss.org/browse/WFLY-11406

Also WF 16 will likely be out before JDK 12 goes GA.

from jboss-classfilewriter.

This was fixed with commit f084636

from jboss-classfilewriter.