Stefan, Would you please create a Jira ticket? This will give your issue more visibility and one location with ALL the information needed in the future.
Gary On Fri, Feb 4, 2022, 09:49 Stefan Reich <stefan.reich.maker.of....@googlemail.com.invalid> wrote: > Will you look at that. BCEL's verifier actually checks for this > (Pass3aVerifier.java): > > public void visitLDC(final LDC ldc) { > indexValid(ldc, ldc.getIndex()); > final Constant c = constantPoolGen.getConstant(ldc.getIndex()); > if (c instanceof ConstantClass) { > addMessage("Operand of LDC or LDC_W is CONSTANT_Class '"+c+"' - > this is only supported in JDK 1.5 and higher."); > } > else{ > if (! ( c instanceof ConstantInteger || > c instanceof ConstantFloat || > c instanceof ConstantString ) ) { > constraintViolated(ldc, > "Operand of LDC or LDC_W must be one of CONSTANT_Integer, > CONSTANT_Float or CONSTANT_String, but is '"+c+"'."); > } > } > } > > It generates just a warning though, not an actual error. > > I quickly checked out LDC.java to see if I can submit a PR, but I think I > don't know enough about BCEL to actually do it. I'll leave it to the > experts. > > Greetings > > On Fri, 4 Feb 2022 at 15:37, Stefan Reich < > stefan.reich.maker.of....@googlemail.com> wrote: > > > Update: They changed it in Java 5. ClassGen.setMajor(49) + > > ClassGen.setMinor(0) works. > > > > On Fri, 4 Feb 2022 at 15:26, Stefan Reich < > > stefan.reich.maker.of....@googlemail.com> wrote: > > > >> Mystery solved, ladies and gentlemen... > >> > >> It was... > >> > >> the byte code version. BCEL outputs version 45.3 by default (JDK 1.1). > >> There were multiple changes to the class file format spec since then. > >> > >> Specifically, they must have allowed ldc to load .class objects directly > >> at some point after JDK 1.1. In fact, I distinctly remember the > >> Class.forName shenanigans that javac produced back then instead of the > >> direct ldc. > >> > >> Apparently the Java verifier is so strict it judges the class file > >> according to its version number and disallows the new version of ldc in > a > >> class file written for JDK 1.1. > >> > >> BCEL doesn't check for this though and outputs a broken class file. > >> Changing this might be a good idea. > >> > >> Unfortunately I couldn't find documentation on when the byte code spec > >> change happened. Does anyone know? > >> > >> Neither did I find anything in the HotSpot verifier sources > >> < > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/verifier.cpp > > > >> which is odd to me. No mention of a JDK version there. Only in > >> clasfileparser.cpp > >> < > https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/classFileParser.cpp > > > >> but didn't find the issue in question there either. I'm by no means an > >> expert in the JDK C++ source though. > >> > >> Cheers > >> Stefan > >> > >> On Thu, 3 Feb 2022 at 08:32, Romain Manni-Bucau <rmannibu...@gmail.com> > >> wrote: > >> > >>> Hi, > >>> > >>> Maybe a bit ot of topic but did you check with asm (using classreader > for > >>> ex) if it is readable for it? Javap in verbose mode is hard to read > >>> humanly > >>> (and not verbosel does not mean much) so an issue can still be hidden. > >>> > >>> Romain Manni-Bucau > >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog > >>> <https://rmannibucau.metawerx.net/> | Old Blog > >>> <http://rmannibucau.wordpress.com> | Github < > >>> https://github.com/rmannibucau> | > >>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > >>> < > >>> > https://www.packtpub.com/application-development/java-ee-8-high-performance > >>> > > >>> > >>> > >>> Le jeu. 3 févr. 2022 à 01:42, Stefan Reich > >>> <stefan.reich.maker.of....@googlemail.com.invalid> a écrit : > >>> > >>> > I'm mainly curious how it's possible that everything looks completely > >>> > normal in javap (checked a dozen times), but the class verifier > >>> complains > >>> > anyway? Something has to be different. Is there a way to dig deeper > >>> into a > >>> > class file? > >>> > > >>> > Greetings > >>> > > >>> > On Wed, 2 Feb 2022 at 23:14, Stefan Reich < > >>> > stefan.reich.maker.of....@googlemail.com> wrote: > >>> > > >>> > > Hmm, no change with latest version. > >>> > > > >>> > > I did "git clone https://github.com/apache/commons-bcel.git" and > >>> "mvn > >>> > > package". > >>> > > > >>> > > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ javac -cp > >>> > > bcel-6.6.0-SNAPSHOT.jar MakeBadClassFile.java > >>> > > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java -cp > >>> > > bcel-6.6.0-SNAPSHOT.jar:. MakeBadClassFile > >>> > > Now please try: java BadClassFile > >>> > > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ java BadClassFile > >>> > > Error: Unable to initialize main class BadClassFile > >>> > > Caused by: java.lang.VerifyError: (class: BadClassFile, method: > main > >>> > > signature: ([Ljava/lang/String;)V) Illegal type in constant pool > >>> > > stefan@lenovo-ThinkPad-X220:~/dev/classreftest$ > >>> > > > >>> > > On Wed, 2 Feb 2022 at 22:59, Gary Gregory <garydgreg...@gmail.com> > >>> > wrote: > >>> > > > >>> > >> You should try the latest from git master. > >>> > >> > >>> > >> Gary > >>> > >> > >>> > >> On Wed, Feb 2, 2022, 15:41 Stefan Reich > >>> > >> <stefan.reich.maker.of....@googlemail.com.invalid> wrote: > >>> > >> > >>> > >> > Hi again, > >>> > >> > > >>> > >> > actual problem this time... > >>> > >> > > >>> > >> > I think I am doing everything right... Decompilation in javap -v > >>> looks > >>> > >> > just like it should. But I get a VerifyError... I'm using JDK > 17. > >>> Full > >>> > >> > program attached. Please advice, thank you :) > >>> > >> > > >>> > >> > # javac -cp bcel-6.5.0.jar MakeBadClassFile.java > >>> > >> > # java -cp bcel-6.5.0.jar:. MakeBadClassFile > >>> > >> > # java BadClassFile > >>> > >> > Error: Unable to initialize main class BadClassFile > >>> > >> > Caused by: java.lang.VerifyError: (class: BadClassFile, method: > >>> main > >>> > >> > signature: ([Ljava/lang/String;)V) Illegal type in constant pool > >>> > >> > > >>> > >> > > >>> > >> > > >>> --------------------------------------------------------------------- > >>> > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>> > >> > For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >> > >>> > > > >>> > > > >>> > > >> > >> > > >