We Keep Coding

When I upgrade MatlabRuntime from 2019b to 2021b,I hava a proplem

When I upgrade MatlabRuntime from 2019b to 2021b and I hava a springboot service used matlab, I have a problem,I import newest javabulider.jar(2021b) into my springboot service, then I package and publish my service into server,then report an error,can someone help me,thank you
Caused by: java.lang.UnsatisfiedLinkError: Failed to find the required library libmwmclmcrrt.so.9.7 on java.library.path.
This library is typically installed along with MATLAB or the MATLAB Runtime. Its absence may indicate an issue with that installation or
the current path configuration, or a mismatch with the architecture of the Java interpreter on the path.
MATLAB Runtime version this component is attempting to use: 9.7.
Java interpreter architecture: glnxa64.
I need someone can help me

The message:
Failed to find the required library libmwmclmcrrt.so.9.7
Indicates that the application you are trying to execute was compiled with Matlab 2019b and that the corresponding MCR is not installed.

Error MVN clean install. Failed to release mocks. This should not happen unless you are using a third-part mock maker

Hi so i tried to build my project by running mvn clean install. Ideally, it'd build successfully since all my other team members can do so fine. It, however, says i'm running into test failures. This is the exact error log given:
Tests run: 22, Failures: 0, Errors: 22, Skipped: 0, Time elapsed: 0.739 sec <<< FAILURE! - in com.pic.resources.xxx() Time elapsed: 0.216 sec <<< ERROR!
org.mockito.exceptions.base.MockitoException:
Failed to release mocks
This should not happen unless you are using a third-part mock maker
at com.pic.resources.xxx.java:50)
Caused by: org.mockito.exceptions.base.MockitoException:
Mockito cannot mock this class: class com.pic.service.xxx.
If you're not sure why you're getting this error, please report to the mailing list.
Java : 1.8
JVM vendor name : AdoptOpenJDK
JVM vendor version : 25.242-b08
JVM name : OpenJDK 64-Bit Server VM
JVM version : 1.8.0_242-b08
JVM info : mixed mode
OS name : Mac OS X
OS version : 10.16
You are seeing this disclaimer because Mockito is configured to create inlined mocks.
You can learn about inline mocks and their limitations under item #39 of the Mockito class javadoc.
Underlying exception : org.mockito.exceptions.base.MockitoException: Could not modify all classes [class com.pic.service.xxx]
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: org.mockito.exceptions.base.MockitoException: Could not modify all classes [class com.pic.service.xxx]
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: java.lang.IllegalStateException:
Byte Buddy could not instrument all classes within the mock's type hierarchy
This problem should never occur for javac-compiled classes. This problem has been observed for classes that are:
- Compiled by older versions of scalac
- Classes that are part of the Android distribution
at com.pic.resources.xxx.setup(xxx.java:50)
Caused by: java.lang.SecurityException: class "com.bmc.auth.OnBehalfOfAuthenticationDetailsProvider"'s signer information does not match signer information of other classes in the same package
at
I have tried ALL the possible solutions i can think of
updated my JDK to 11 and changed the jdk version on intellij and pointed mvn to be to JDK 11
downgraded my JDK to 8 and did same step as 1) and added the right byte-buddy with an older version
upgraded to latest maven
cleared cache
used latest mockito version (then tried old mockito version and nothing happened)
running this in both intellij and the terminal didn't change anything. Even tried importing the right intellij settings. That didn't work
added byte-buddy dependency and made it the latest version
The only other possible cause of the problem is that I upgraded my Mac OS to Big Sur the other day and it screwed up my java run time, but I don't know if tht's a cause or not.

The underlying issue seems to be this:
java.lang.SecurityException: class "com.bmc.auth.OnBehalfOfAuthenticationDetailsProvider"'s signer information does not match signer information of other classes in the same package
It might be the case that you have a package-private type and sign your jars, this does not normally work as the type needs to be placed in the same package which breaks the signature.

Protobufs - 'supposed to be overridden by subclasses' exception

I've got a problem with Google Protocol Buffers. The java class compiled using protoc throws exceptions during conversion to byte array.
Here is the example code:
byte[] raw = pbCard.toByteArray();
// PbCard.Card is an instance of a protoc-generated class.
This results in an exception:
Exception in thread "main" java.lang.UnsupportedOperationException: This is supposed to be overridden by subclasses.
This kind of behaviour was diagnosed by many to be a problem with protoc versions. When using java classes generated using protoc < 2.5.0 and including a java library 2.5.0, this exception will be generated.
Links:
http://code.google.com/p/protobuf/issues/detail?id=493
error with serialization with protobuf
http://comments.gmane.org/gmane.comp.lib.protocol-buffers.general/9588
Protobuf 2.5.0 bug?
However, in my case both the protoc and java library are in version 2.5.0.
eipifi#vaio:~$ protoc --version
libprotoc 2.5.0
And the included jar:
eipifi#vaio:~$ sha1sum protobuf-java-2.5.0.jar
a10732c76bfacdbd633a7eb0f7968b1059a65dfa protobuf-java-2.5.0.jar
No older version of protobufs was ever present on my machine. All java classes were generated on this machine and were not moved from an older project.
What am I missing?
Thank you for your time.

Gradle and IntelliJ with mixed Java/Scala project and SDK 1.6

I am getting started with Gradle on a polyglot java/scala project. The java modules are legacy modules built using JDK 1.6 so I decided to have my build environment use the older JDK.
This has a very practical rationale. Code such as the following:
class X{
private int i;
<T extends X> void aMethod(T t){
int it = t.i;
}
}
will compile fine using JDK 1.6 but will break with JDK 1.7 with the following error:
error: i has private access in X
For this reason (although unhappily) I decided to stick to JDK 1.6 (we do have code that looks like that).
Now I created a brand new Gradle project (no dependency/build tool was used before) with two modules:
myApp
|---- common (java module)
|---- someService (depends on common)
| |---- service (scala module)
| |---- api (java client)
and set the java source and target compatibility to 1.6. If I build with gradle everything works fine, i.e., the build runs and the jars get build correctly (both java and scala), without any error.
Now I generated my IntelliJ project files using the 'idea' plugin. IntelliJ loads up the project correctly. Now when I try and build from IntelliJ (Ctrl + F9) I get the following:
Information: Modules "myApp", "someService", "common" were fully rebuilt due to project configuration/dependencies changes
Information: Compilation completed with 4 errors and 44 warnings in 2 sec
Information: 4 errors
Information: 44 warnings
Error: scala: warning: [options] bootstrap class path not set in conjunction with -source 1.6
Error: scala: 1 error
Error: scala: 43 warnings
Warning: scala: Some input files use unchecked or unsafe operations.
Warning: scala: Recompile with -Xlint:unchecked for details.
... (the warnings follow)
error: properties has private access in X
As you can see, I am now getting the JDK 1.7 error (although I'm compiling with 1.6) and the build fails. IntelliJ says there are 4 errors but I believe the root cause is just that one.
Now If I go and fix the code above as follows:
class X{
private int i;
<T extends X> void aMethod(T t){
// SDK 1.7: explicit downcast grants access to base private members
int it = ((X)t).i;
}
}
I get the following error:
scala: Error: org.jetbrains.jps.incremental.scala.remote.ServerException
java.lang.InternalError
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:838)
...
at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1305)
...
at sbt.classfile.Analyze$$anonfun$apply$8$$anonfun$sbt$classfile$Analyze$$anonfun$$processDependency$1$1.apply$mcV$sp(Analyze.scala:49)
...
at scala.collection.immutable.HashSet$HashSet1.foreach(HashSet.scala:153)
...
at sbt.compiler.AggressiveCompile.compile1(AggressiveCompile.scala:44)
at org.jetbrains.jps.incremental.scala.local.CompilerImpl.compile(CompilerImpl.scala:63)
...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
at java.lang.reflect.Method.invoke(Method.java:606)
at com.martiansoftware.nailgun.NGSession.run(Unknown Source)
Caused by: java.io.FileNotFoundException: /usr/lib/jvm/java-7-oracle/jre/lib/resources.jar
...
which I believe is caused by the fact that I uninstalled JDK 1.7 and installed JDK 1.6 and somewhere in the IntelliJ paths something is still pointing at the old JDK.
So I have two questions:
1. How to get rid of any reference to JDK 1.7 in IntelliJ?
2. How to get rid of the first error altogether without changing the code? I know this is possible because Gradle does it successfully.

Silly me! I had uninstalled JDK 7 without restarting IntelliJ so it was still pointing to some of the JDK 7 folders. This was a very odd experience!

"Bad major version" error when using Jasper-Reports on Websphere

When I try to fill a JasperReport in my Servlet running on Websphere 6.1 I get an UnsupportedClassVersionError: Bad major version at offset=6.
I guess that the compiled JasperReport has a different version (java 6?) than the jre on websphere can execute (which would be java 5), but I can not figure out why. Compiling the reports with maven or in the application (in the servlet) both leads to the error.
According to the demo which was provided with JasperReports, which also shows how to use it with Java 1.5, I added following config to the jasperreports.properties:
org.eclipse.jdt.core.compiler.source=1.5
org.eclipse.jdt.core.compiler.compliance=1.5
org.eclipse.jdt.core.compiler.codegen.TargetPlatform=1.5
But the error still exists.
The language used in the report is Java, so which compiler is the correct one to use? net.sf.jasperreports.engine.design.JRJdtCompiler or net.sf.jasperreports.engine.design.JRJavacCompiler?
Unfortunately, the documentation does not explain the difference between those two compilers...
Edit: so fare I have been using the JRJavacCompiler. With the JRJdtCompiler I get a NullPointer Exception:
java.lang.NullPointerException
at java.lang.Class.isAssignableFrom(Native Method)
at net.sf.jasperreports.engine.fill.JRFillTextField.getFormat(JRFillTextField.java:706)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluateText(JRFillTextField.java:394)
at net.sf.jasperreports.engine.fill.JRFillTextField.evaluate(JRFillTextField.java:368)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.evaluate(JRFillElementContainer.java:258)
at net.sf.jasperreports.engine.fill.JRFillBand.evaluate(JRFillBand.java:499)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:2036)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:760)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:270)
at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:128)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:946)
at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:864)
at net.sf.jasperreports.engine.fill.JRFiller.fillReport(JRFiller.java:84)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:624)
at net.sf.jasperreports.engine.JasperFillManager.fillReport(JasperFillManager.java:540)
at com.swissre.sod.jone.web.server.FileStreamingServlet.doGet(FileStreamingServlet.java:48)

It might be that you are using libraries in you application that are compiled in java 6.
You could check the MANIFEST information of your dependencies to find out more.