MysqldResource isn't working with MacOS Catalina - java

Since upgrading my os to Mac Catalina,
I'm getting the following error when trying to run the following:
MysqldResource mysqldResource = new MysqldResource(uri); // Uri - temp db dir
mysqldResource.start("embedded-mysqld-thread-" + System.currentTimeMillis(), databaseOptions);
Looks like the source of the problem is with the dependency "mysql-connector-mxj-db-files" having binary files in 32bit format, while catalina stopped supporting it.
This is the error I'm getting:
Exception in thread "embedded-mysqld-thread-1574931580040" com.mysql.management.util.WrappedException: java.io.IOException: Cannot run program "/private/var/folders/l5/4ywgvbbj1kvgvrwxzp6dz82c0000gn/T/test_db_24166997810717/bin/mysqld": error=86, Bad CPU type in executable
at com.mysql.management.util.Exceptions.toRuntime(Exceptions.java:55)
at com.mysql.management.util.Exceptions$Block.exec(Exceptions.java:89)
at com.mysql.management.util.RuntimeI$Default.exec(RuntimeI.java:180)
at com.mysql.management.util.Shell$Default.run(Shell.java:140)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.io.IOException: Cannot run program "/private/var/folders/l5/4ywgvbbj1kvgvrwxzp6dz82c0000gn/T/test_db_24166997810717/bin/mysqld": error=86, Bad CPU type in executable
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
at java.lang.Runtime.exec(Runtime.java:620)
at com.mysql.management.util.RuntimeI$Default$1.inner(RuntimeI.java:177)
at com.mysql.management.util.Exceptions$Block.exec(Exceptions.java:86)
... 3 more
Caused by: java.io.IOException: error=86, Bad CPU type in executable
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:247)
at java.lang.ProcessImpl.start(ProcessImpl.java:134)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
... 6 more
Does anyone know of an alternative to mysql-connector-java or knows of a way to run the existing dependency on Mac OS Catalina?

For anyone who has the same issue on MacOS Catalina, you can follow the README.md in my repo (https://github.com/pengyue/mysql-connector-mxj-mac-os-catalina), which has the 64 bits executables for MacOS Catalina, and this improved connector works on Catalina.
To explain what I have done:
Download the 64 bits executables from MySQL to the folder 5-5-9
Add the platform mapping for 64 bits MacOS in platform-map.properties
Create a jar by using jar cvf mysql-connector-mxj-db-files-5.0.12.jar .
Replace the jar in your mvn settings folder ~/.m2/repository/mysql/mysql-connector-mxj-db-files/5.0.12/ with the jar you just created.
This solution works fine for my projects, Unfortunately I could not find a github for the mysql-connector-mxj, as it is deprecated and not maintainable anymore.
The other option is to use wix-embedded-mysql(https://github.com/wix/wix-embedded-mysql) instead of mysql-connector-mxj, but this probably requires some code changes in your projects.

Related

Where is libfreetype.so.6 in OpenJDK, I got an unsatisfiedLinkError when using a kaptcha jar

I run my program in suse 11 operation system. The JRE is OpenJDK 8u-191. The program runs smoothly except kaptcha for login. When I login the page will show me the kaptcha, but an exception occurs.
java.lang.UnsatisfiedLinkError: /usr/local/java8/jre-8u191/lib/amd64/libfontmanager.so: libfreetype.so.6: cannot open shared object file no such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
...
Is the libfreetype.so.6 in OpenJDK? I can't find it. Should I download the libfreetype.so.6 from internet?
This is part of libfreetype6 and you can find it here https://software.opensuse.org/package/libfreetype6

Error while submitting a job with Hadoop 2.6.0 on Windows

I'm working on a Java project running with Hadoop 0.20.1 and I'm trying to migrate to Hadoop 2.6.0. Once I've changed the corresponding Hadoop jar files in the project, I obtain the following error when submitting a job:
Exception in thread "main" java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO$Windows.access0(Ljava/lang/String;I)Z
at org.apache.hadoop.io.nativeio.NativeIO$Windows.access0(Native Method)
at org.apache.hadoop.io.nativeio.NativeIO$Windows.access(NativeIO.java:557)
at org.apache.hadoop.fs.FileUtil.canRead(FileUtil.java:977)
at org.apache.hadoop.util.DiskChecker.checkAccessByFileMethods(DiskChecker.java:187)
at org.apache.hadoop.util.DiskChecker.checkDirAccess(DiskChecker.java:174)
at org.apache.hadoop.util.DiskChecker.checkDir(DiskChecker.java:108)
at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.confChanged(LocalDirAllocator.java:285)
at org.apache.hadoop.fs.LocalDirAllocator$AllocatorPerContext.getLocalPathForWrite(LocalDirAllocator.java:344)
at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:150)
at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:131)
at org.apache.hadoop.fs.LocalDirAllocator.getLocalPathForWrite(LocalDirAllocator.java:115)
at org.apache.hadoop.mapred.LocalDistributedCacheManager.setup(LocalDistributedCacheManager.java:131)
at org.apache.hadoop.mapred.LocalJobRunner$Job.<init>(LocalJobRunner.java:163)
at org.apache.hadoop.mapred.LocalJobRunner.submitJob(LocalJobRunner.java:731)
at org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:536)
at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1296)
at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1293)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:1293)
I've read it could be a problem related to Hadoop binaries, but I've built them myself, placed them in "c:\hadoop\bin" and the environment variable HADOOP_HOME has the right value.
I'm running my project on Eclipse, on a machine with Windows 7 64 bits and Java 8.
Can anyone help me with this?
Thanks!
I've finally solved my problem. I had Java 8 32 bits installed instead of the 64 bits version. I installed the right version and Hadoop jobs submitted perfectly.

RNetLogo works on R3.1.1.0?

When I try to launch the RNetLogo from R using the function NLStart(). I get messages about java and the GUI does not open. I am using MacOsX 10.9.5 64-bit, NetLogo 5.1.0, and R 3.1.1.
> library(rJava)
> library(RNetLogo)
> nl.path <- "/Applications/NetLogo\ 5.1.0/NetLogo\ 5.1.0.app"
> NLStart(nl.path, nl.version=5, gui=FALSE)
java.lang.NoClassDefFoundError: org/nlogo/workspace/Controllable
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:249)
Caused by: java.lang.ClassNotFoundException
at RJavaClassLoader.findClass(RJavaClassLoader.java:383)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
... 2 more
After that I try with "JGR and Deducer and deducer extras”.
The code and errors are:
> install.packages(c("JGR","Deducer","DeducerExtras”))
> Sys.setenv(NOAWT=1)
> library(JGR)
> Sys.unsetenv("NOAWT")
> JGR()
When start JGR the code is:
Loading required package: JGR
Loading required package: rJava
Loading required package: JavaGD
Loading required package: iplots
starting httpd help server ... done
Loading required package: RNetLogo
Loading required package: DeducerExtras
Loading required package: Deducer
Loading required package: ggplot2
Use suppressPackageStartupMessages to eliminate package startup messages.
Loading required package: car
Loading required package: MASS
Attaching package: ‘Deducer’
Loading required package: irr
Loading required package: lpSolve
> nl.path<-"/users/Pabolo/Applications/NetLogo\ 5.1.0/NetLogo.jar"
> NLStart(nl.path)
Error on setwd(nl.path) : you can not change the working directory.
With nl.path be the path to the app dir.
There are some errors.
I running all these over JGR().
> nl.path<-"/Applications/NetLogo\ 5.1.0"
> NLStart(nl.path)
Warning: ch.randelshofer.quaqua.util.OSXPreferences failed to load /Users/Pabolo/Library/Preferences/.GlobalPreferences.plist
java.io.IOException: parseReal: unsupported byte count:128
at ch.randelshofer.quaqua.util.BinaryPListParser.parseReal(BinaryPListParser.java:703)
at ch.randelshofer.quaqua.util.BinaryPListParser.parseObjectTable(BinaryPListParser.java:424)
at ch.randelshofer.quaqua.util.BinaryPListParser.parse(BinaryPListParser.java:315)
at ch.randelshofer.quaqua.osx.OSXPreferences.readPList(OSXPreferences.java:176)
at ch.randelshofer.quaqua.osx.OSXPreferences.updateCache(OSXPreferences.java:99)
at ch.randelshofer.quaqua.osx.OSXPreferences.ensureCached(OSXPreferences.java:90)
at ch.randelshofer.quaqua.osx.OSXPreferences.get(OSXPreferences.java:79)
at ch.randelshofer.quaqua.osx.OSXPreferences.getString(OSXPreferences.java:45)
at ch.randelshofer.quaqua.BasicQuaquaLookAndFeel.initSystemColorDefaults(BasicQuaquaLookAndFeel.java:151)
at ch.randelshofer.quaqua.leopard.Quaqua15LeopardLookAndFeel.initSystemColorDefaults(Quaqua15LeopardLookAndFeel.java:208)
at ch.randelshofer.quaqua.BasicQuaquaLookAndFeel.getDefaults(BasicQuaquaLookAndFeel.java:76)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:520)
at javax.swing.UIManager.setLookAndFeel(UIManager.java:564)
at org.nlogo.swing.Utils.setSystemLookAndFeel(Utils.java:41)
at org.nlogo.app.App.<init>(App.scala:302)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.picocontainer.injectors.AbstractInjector.newInstance(AbstractInjector.java:147)
at org.picocontainer.injectors.ConstructorInjector$1.run(ConstructorInjector.java:332)
at org.picocontainer.injectors.AbstractInjector$ThreadLocalCyclicDependencyGuard.observe(AbstractInjector.java:272)
at org.picocontainer.injectors.ConstructorInjector.getComponentInstance(ConstructorInjector.java:354)
at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.getComponentInstance(AbstractInjectionFactory.java:56)
at org.picocontainer.behaviors.AbstractBehavior.getComponentInstance(AbstractBehavior.java:64)
at org.picocontainer.behaviors.Stored.getComponentInstance(Stored.java:91)
at org.picocontainer.DefaultPicoContainer.getInstance(DefaultPicoContainer.java:692)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:646)
at org.picocontainer.DefaultPicoContainer.getComponent(DefaultPicoContainer.java:671)
at org.nlogo.app.App$.main(App.scala:140)
at org.nlogo.app.App.main(App.scala)
at nlcon.NLink_v5.<init>(NLink_v5.java:96)
at org.rosuda.JRI.Rengine.rniRunMainLoop(Native Method)
at org.rosuda.JRI.Rengine.run(Rengine.java:640)
unable to find translation for: edit.viewSettings.2D.frameRate in GUI_Strings for locale: es
unable to find translation for: edit.viewSettings.2D.frameRate.info in GUI_Strings for locale: es
>
You have to change your path to: nl.path <- "/Applications/NetLogo 5.3/app".
They have changed the directory structure so that the netlogo jar file is now in an 'app' subdirectory.
Source: https://stackoverflow.com/a/34837036/468305
Hope that helps, it worked for me.
It says you can not change your working directory. Maybe start a new session. Also one of your backslashes is going the wrong way.
To find your NetLogo path try file.choose() and then navigate to the NetLogo Jar file. Then when you open the path to file will show in R studios console. Copy the file path into the NLStart command which should look something like below.
file.choose()
NLStart("C:\\Program Files\\NetLogo 6.2.0\\app", gui = TRUE, nl.jarname = "netlogo-6.2.0.jar")
Finally, make sure your Java, NetLogo and R are all running on 64 bit (works for me) or 32 bit but try not to mix. Finally try and run code directly from R GUI instead of RStudio. This helped the first time I opened Netlogo with R.
I have a youtube video (https://www.youtube.com/watch?v=zWMdaTEPTOc) explaining how to open NetLogo from R and all my functional code (August 2021) can be found here.

com4j on Windows 64 bit

I've downloaded the latest com4j jars and I'm trying to run through the most simple of their examples.
I'm on Windows 7 64 bit and using a 64 bit JVM.
When I run the command (from the com4j tutorial):
java -jar tlbimp.jar -o wsh -p test.wsh %WINDIR%\system32\wshom.ocx
I get:
Exception in thread "main" java.lang.UnsatisfiedLinkError: com4j-amd64.dll: %1 is
not a valid Win32 application
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com4j.COM4J.loadNativeLibrary(COM4J.java:569)
at com4j.COM4J.<clinit>(COM4J.java:522)
at com4j.tlbimp.driver.Lib.getLibid(Lib.java:90)
at com4j.tlbimp.driver.Driver.addLib(Driver.java:38)
at com4j.tlbimp.driver.Main.doMain(Main.java:123)
at com4j.tlbimp.driver.Main.main(Main.java:56)
Exception in thread "Com4J shutdown hook" java.lang.NoClassDefFoundError: Could
not initialize class com4j.COM4J
at com4j.COM4J$3.run(COM4J.java:476)
The java code extracts "com4j-amd64.dll" next to the jar.
The latest version has just been released:
http://kohsuke.org/2012/04/27/com4j-updates/
https://github.com/kohsuke/com4j/downloads
Using this one solved all my problems.
You have two options:
Download and use the full latest version (located here:
https://github.com/kohsuke/com4j/downloads)
Extract the latest com4j-amd64.dll from the most recent version
Download the latest version (located here: https://github.com/kohsuke/com4j/downloads).
Open up the com4j.jar with your favorite zip utility (read 7zip)
Extract com4j.jar\com4j\com4j-x64.dll to the base directory of your application
(optional) Register the dll using REGSVR32 <path to dll>\com4j-x64.dll
I had a similar result at first. I found the com4j-amd64.dll that is produced by com4j is empty. The remedy is to extract the file from the com4j jar file, and put it in the relevant directory by manual action. Com4j will then not auto-produce the file since it is already there. So check if the file is empty as a first step -Carl

Running Java app from inside emacs using JDEE throws NoClassDefFoundError

I have configured JDEE in emacs. But when I try to run any App, it throws NoClassDefFoundError .
Upon compilation, although a class file is created, it only shows the buffer for sometime and then closes it.
The same files if compiled and run from the terminal work perfectly fine.
Also, on this machine I have java-6-openjdk installed. I had configured JDEE on my home computer which has sun java jdk and there are no such problems there.
Other than this, features such as code completion, generation etc work fine.
How do I solve this? Is this due to open jdk ?
I am using a Ubuntu 10.04 desktop.
This is the stack trace
cd /home/vineet/java/KodeJava/src/org/kodeplay/kodejava/
/usr/lib/jvm/java-6-openjdk/bin/java org.kodeplay.kodejava.EmacsTest
Exception in thread "main" java.lang.NoClassDefFoundError: org/kodeplay/kodejava/EmacsTest
Caused by: java.lang.ClassNotFoundException: org.kodeplay.kodejava.EmacsTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
Could not find the main class: org.kodeplay.kodejava.EmacsTest. Program will exit.
Process org.kodeplay.kodejava.EmacsTest exited abnormally with code 1
Thanks
something in your config is wrong. you are trying to run from the "/home/vineet/java/KodeJava/src/org/kodeplay/kodejava/" directory, but in order to find your class on the classpath, you should be running from "/home/vineet/java/KodeJava/src/". Probably need to configure the "jde-run-working-directory" variable.
From the question, it sounds as if the JDEE configuration is not complete when it comes to setting up the command to be launched when running the Java App.
If the same Java App can be run from the terminal with no issues, OpenJDK is not causing the trouble, I'd wager.
Perhaps you copied over from the other computer the JDEE configurations and did not adopt them for the new computer that has OpenJDK.

Categories

Resources