`java.lang.IllegalArgumentException: Class name mismatch` in `ExtendedStackTraceElement` with OpenJDK builds

[nea]

Hi there

I am using Quasar with Vert.x and am currently facing an odd issue of difference between my local Windows dev environment (working) and my Debian server (not working).

The error I face is

SEVERE: java.lang.IllegalArgumentException: Class name mismatch: co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable, io.vertx.ext.sync.Sync$$Lambda$46/877335505
io.vertx.core.VertxException: java.lang.IllegalArgumentException: Class name mismatch: co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable, io.vertx.ext.sync.Sync$$Lambda$46/877335505

I really don't know where this is coming from. I am using Fiber handler from Vert.x, declared everything @Suspendable and have the difference of a working jar locally and the absolute same giving the written error.

In both cases I am using Quasar as javaagent

java -javaagent:C:\Users\xyz\.m2\repository\co\paralleluniverse\quasar-core\0.7.3\quasar-core-0.7.3-jdk8.jar

I already questioned on the Vert.x group if it could be a Vert.x issue (@see https://groups.google.com/d/msg/vertx/xCXDvZ3FxRY/Ucb7Vr0NAQAJ) but they also currently have no clue why I am hopping here to see if somebody might have an idea what I am doing wrong or missing atm.

On the server I have java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Locally its a little older java version "1.8.0_51" Java(TM) SE Runtime Environment (build 1.8.0_51-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

so not that much difference.

Thanks in advance for any pinpointing what might by my problem

[nea]

To give a little more stacktrace, this seems to be the cause for whatever reason:

Caused by: java.lang.IllegalArgumentException: Class name mismatch: co.paralleluniverse.strands.SuspendableUtils$VoidSuspendableCallable, io.vertx.ext.sync.Sync$$Lambda$47/543911223
        at co.paralleluniverse.common.util.ExtendedStackTraceElement.<init>(ExtendedStackTraceElement.java:50)
        at co.paralleluniverse.common.util.ExtendedStackTraceElement.<init>(ExtendedStackTraceElement.java:39)
        at co.paralleluniverse.common.util.ExtendedStackTrace$BasicExtendedStackTraceElement.<init>(ExtendedStackTrace.java:178)
        at co.paralleluniverse.common.util.ExtendedStackTraceClassContext.get(ExtendedStackTraceClassContext.java:54)
        at co.paralleluniverse.fibers.Fiber.checkInstrumentation(Fiber.java:1626)
        at co.paralleluniverse.fibers.Fiber.checkInstrumentation(Fiber.java:1618)
        at co.paralleluniverse.fibers.Fiber.verifySuspend(Fiber.java:1591)
        at co.paralleluniverse.fibers.Fiber.verifySuspend(Fiber.java:1586)
        at co.paralleluniverse.fibers.Fiber.park(Fiber.java:583)
        at co.paralleluniverse.fibers.Fiber.park(Fiber.java:587)
        at co.paralleluniverse.fibers.FiberAsync.run(FiberAsync.java:186)

[nea]

One additional note: I made an error, I am running

openjdk version "1.8.0_66-internal" OpenJDK Runtime Environment (build 1.8.0_66-internal-b01) OpenJDK 64-Bit Server VM (build 25.66-b01, mixed mode)

on the server.

[nea]

Ok, so an update (I cannot back away from this issue ^^):

As I found out that the Docker image was actually using openJDK, I changed it to really

java version "1.8.0_60" Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

now, and it works!

So, it really seems OpenJDK was the problem here. Does anybody know this issue?

Thanks (and sorry about any confusion)

[circlespainter]

Do you have any chance to try with latest 1.8.0_66-b17?

[nea]

Hi there

I was falling back to the Docker java:8 image which comes with build 1.8.0_66-internal-b01. I will try to setup an image later on.

Cheers

[nea]

Hi

I tried the different OpenJDK packages from the different Debian repos now and with all I faced the same issue, still with OpenJDK the error, with Oracle not.

Best

[circlespainter]

Thanks, I don't currently have OpenJDK builds installed but I'll have a try and look into this ASAP.

[nea]

Thanks a lot. No rush from my side as I have a solution for now with the Oracle JDK. But would be nice to find out what the problem seems to be here, of course.

Cheers

[darkwrat]

Hi! In my case this exception is caused by code like this:

@FunctionalInterface
public interface SuspendableConsumer<T> {
    void accept(T t) throws SuspendExecution;
}

public static <T> Consumer<T> rethrowConsumer(SuspendableConsumer<T> consumer) {
    return param -> {
        try {
            consumer.accept(param);
        } catch (SuspendExecution ex) {
            rethrow(ex);
        }
    };
}

private static <E extends Exception> void rethrow(Exception exception) throws E {
    //noinspection unchecked
    throw (E) exception;
}

I tried to use such code to be able to use methods that throw SuspendExecution in streams and lambdas. When using OpenJDK there is an IllegalArgumentException, but when using Oracle JDK it's just instrumentation verifier warnings. That means that issue still persists but may stay unseen when verify instrumentation is disabled.

Could you please possilbly clarify if there is a correct way to use methods with throws SuspendExecution declarations inside lambdas?

Here is an excerpt from stack trace that shows that stream internals stay uninstrumented, hope it helps!

at su.iota.backend.misc.SuspendableUtils.lambda$rethrowConsumer$1(su.iota.backend.misc.SuspendableUtils$SuspendableConsumer,java.lang.Object) (SuspendableUtils.java:43 bci: 113) at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(java.lang.Object) (ForEachOps.java:184 bci: 5) at java.util.stream.ReferencePipeline$2$1.accept (ReferencePipeline.java:175 bci: 21) at java.util.Iterator.forEachRemaining (Iterator.java:116 bci: 21) at java.util.Spliterators$IteratorSpliterator.forEachRemaining (Spliterators.java:1801 bci: 52) at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:481 bci: 32) at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:471 bci: 13) at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:151 bci: 3) at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:174 bci: 3) at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:234 bci: 88) at java.util.stream.ReferencePipeline.forEach (ReferencePipeline.java:418 bci: 6) at su.iota.backend.game.impl.MatchmakingServiceImpl.makeMatch (MatchmakingServiceImpl.java:53 bci: 129) ** at su.iota.backend.frontend.impl.FrontendServiceImpl.performPlayerAction (FrontendServiceImpl.java:130 bci: 210)

[candrews]

Fixed by https://github.com/puniverse/quasar/pull/207/

[circlespainter]

@nea Could you confirm by using a locally built Quasar 0.7.6-SNAPSHOT from master (or 0.7.0)?

[circlespainter]

@nea According to my tests this issue is fixed by #207 so I'm closing it (you can always reopen it).

[rvraaphorst]

It appears I'm having the same problem using quasar-core-0.7.7-jdk8 and OpenJDK Runtime Environment (build 1.8.0_131-b11) OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

[JuKu]

I have the same issue with vertx, but with OracleJDK 9.