Recently, I was working on a remote project. The application can run in the local idea and the idea of remote colleagues. However, after the colleagues use Jenkins to package and deploy to the server, they start to report errors. The log error information is shown in the following figure:

This error is an error in the verification phase of class loading, which is related to bytecode. However, since it can be started locally, it is natural to think that the JDK version is different, resulting in bytecode incompatibility. After checking the JDK version, the versions of myself and my colleagues are 1.8.0 respectively_181 and 1.8.0_271, and 1.8.0 on the server_101 version.

Since the server version cannot be changed, we can only find a way to modify the code. After a careful look at the error information, we found the keywords invokedynamic and lamda. Lamda expression is a syntax sugar added by jdk8. The function is realized through invokedynamic instruction at runtime, so we modify the lamda expression in the code and replace it with implementation without lamda, After repackaging, it is placed on the server and runs successfully.

Note: the process of solving problems is actually much more troublesome. It has gone through a series of mental processes:

(1) At first, I suspected the JDK version. I thought that OpenJDK might be used on the server. After checking, I found that oraclejdk is also used on the server.

(2) After verifying that the server is not using openjdk, I began to suspect that it is the problem of lamda expression. This judgment is based on the knowledge learned in the book in-depth understanding of Java virtual machine, and I vaguely remember seeing lamda expression of 1.8 leading to other bug bloggers. In order to confirm this, I began to search on Baidu.

(3) Unfortunately, the imprecise search keywords (only using “bad type on operate stack”) made me take a big detour. Many people said that the reason for this error was the wrong version of the dependent library. It happened that my project also had a dependency problem on the public common package, so it was developed remotely, The version of the common package you selected when building your own environment is different from the version used by the other party, so many methods have been tried in this step, but they have not been solved.

(4) Finally, I went back to the lamda expression and found several questions about lamda and verifyerror on StackOverflow (link below), so I chose to modify the code to the implementation of non-lamda expression to solve the problem.

https://stackoverflow.com/questions/13219297/bad-type-on-operand-stack-using-jdk-8-lambdas-with-anonymous-inner-classes

https://stackoverflow.com/questions/30365106/reason-for-the-exception-java-lang-verifyerror-bad-type-on-operand-stack