Here is where we stand today: - I fixed bugs where the JVM specification types data as "u2" (unsigned 2 bytes, range 0 to 65535) but we used to read these items as signed shorts so we "lost" values from 32768 to 65535 or we read them as negative values. Amazingly this did not cause tests to fail, which does not say much for our test coverage but these would be hard to find without specially crafted class files. - On Java8, the previously failing test VerifyJavaMathTestCase.testBigDecimal() passes but fails differently than it did when run on Java 11 or above. I only enabled the test on Java 8. - VerifyJavaUtilTestCase still fails to verify all its classes. - VerifyJavaHomesTestCase still has tons of failures
I might not hold up releasing 6.7.0 too long since these issues must have existed for a long time. Gary On Thu, Nov 17, 2022 at 10:53 AM Mark Roberts <mar...@cs.washington.edu> wrote: > > I will try to take a look at this later today. > > Mark > > -----Original Message----- > From: Gary D. Gregory [mailto:ggreg...@apache.org] > Sent: Thursday, November 17, 2022 7:14 AM > To: dev@commons.apache.org > Subject: Re: [BCEL] Invalid test or bug? > > More specifically, javap says: > > 21: invokevirtual #68 // Method > "[B".clone:()Ljava/lang/Object; > > So calling a method on an array with invokevirtual is ok and we have a bug. > > Thoughts? > > Gary > > On 2022/11/17 14:45:41 "Gary D. Gregory" wrote: > > Hm, I'm thinking bug when I see javap output like: > > > > #68 = Methodref #901.#902 // > > "[B".clone:()Ljava/lang/Object; > > > > Thoughts? > > > > Gary > > > > On 2022/11/17 13:04:32 "Gary D. Gregory" wrote: > > > Actually: VerifyJavaMathTestCase and VerifyJavaUtilTestCase > > > > > > Gary > > > > > > On 2022/11/17 13:00:21 "Gary D. Gregory" wrote: > > > > Hi All & Mark Roberts: > > > > > > > > I added JavaMathTestCase as a disabled test as it fails. > > > > > > > > Is this a legal test to try or do we have a bug? > > > > > > > > Gary > > > > > > > > ------------------------------------------------------------------ > > > > --- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
