I'm currently trying to get dl4j (deeplearning4j) to import my model that I trained in keras 1.2.
This is my code:
public static void main( String[] args )
{
try {
MultiLayerNetwork network = KerasModelImport.importKerasSequentialModelAndWeights(
"C:\\Users\\A\\Documents\\GitHub\\DevanagriRecognizer\\model_keras1.h5");
System.out.println( "Hello World!" );
} catch (IOException e) {
e.printStackTrace();
} catch (InvalidKerasConfigurationException e) {
e.printStackTrace();
} catch (UnsupportedKerasConfigurationException e) {
e.printStackTrace();
}
}
I'm using Maven to handle the dependencies, and this is my first time using it. (That might be relevant)
When I run the above code I get a ExceptionInInitializerError caused by UnsatisfiedLinkError: no jnind4jcpu in java.library.path.
It looks like a missing dependency, but I have no idea how to fix it.
This is my pom.xml: https://pastebin.com/FzAMwA0z
And this is my full stacktrace: https://pastebin.com/a2kyUtch
By the way, I'm using IntelliJ with Java 1.8u101 on 64-bit Windows 10
I am not much into dl4j. But, multiple existing redirections to this one:
Possibly try specifying a classifier for nd4j-native-platform as:
<dependency>
<groupId>org.nd4j</groupId>
<artifactId>nd4j-native-platform</artifactId>
<version>${dl4j.version}</version>
<classifier>windows-x86_64</classifier>
</dependency>
Build using maven-shade-plugin following this configuration:
https://github.com/deeplearning4j/dl4j-examples/blob/master/dl4j-examples/pom.xml#L160
Or follow this for:
The workaround consists in either:
changing tmp permission changing tmp location.
Define TMP, TMPDIR and
TEMP to a new directory, add -Djava.io.tmpdir=${TMPDIR} to the java
command.
Linking more sources to troubleshoot and its wiki.
FWIW, keras isn't the problem here and isn't really relevant for this stack trace. You have bad dependencies on your LD_LIBRARY_PATH somewhere.
If you're using windows, look into:
https://github.com/bytedeco/javacpp-presets/wiki/Debugging-UnsatisfiedLinkError-on-Windows
A common problem is MKL with anaconda. If you are using that, then another work around is to set library path to empty with:
-Djava.library.path=""
The above is called a System property. Set that in your runtime config if you have one.
For some reason, changing dl4j.version from 0.8.1-SNAPSHOT to 0.8.0 fixed it. Still not sure why, but it's working.
Related
I'm trying to understand a comment that a colleague made. We're using testcontainers to create a fixture:
import org.testcontainers.containers.GenericContainer;
import org.testcontainers.utility.DockerImageName;
public class SalesforceFixture extends GenericContainer<SalesforceFixture> {
private static final String APPLICATION_NAME = "salesforce-emulator";
public SalesforceFixture() {
// super(ImageResolver.resolve(APPLICATION_NAME));
super(DockerImageName.parse("gcr.io/ad-selfserve/salesforce-emulator:latest"));
...
}
...
The commented code is what it used to be. The next line is my colleague's suggestion. And on that line he commented:
This is the part I don't know. The [ImageResolver] gets the specific version of the emulator, rather than the latest. You need a docker-info file for that though, which jib doesn't automatically generate (but I think it can).
This is what I know or have figured so far:
SalesforceFixture is a class that will be used by other projects to write tests. It spins up a container in Docker, running a service that emulates the real service's API. It's like a local version of the service that behaves enough like the real thing that if one writes code and tests using the fixture, it should work the same in production. (This is where my knowledge ends.)
I looked into ImageResolver—it seems to be a class we wrote that searches a filesystem for something:
public static String resolve(String applicationName, File... roots) {
Stream<File> searchPaths = Arrays.stream(roots).flatMap((value) -> {
return Stream.of(new File(value, "../" + applicationName), new File(value, applicationName));
});
Optional<File> buildFile = searchPaths.flatMap((searchFile) -> {
if (searchFile.exists()) {
File imageFile = new File(searchFile + File.separator + "/target/docker/image-name");
if (imageFile.exists()) {
return Stream.of(imageFile);
}
}
return Stream.empty();
}).findAny();
InputStream build = (InputStream)buildFile.map(ImageResolver::fileStream).orElseGet(() -> {
return searchClasspath(applicationName);
});
if (build != null) {
try {
return IOUtils.toString(build, Charset.defaultCharset()).trim();
} catch (IOException var6) {
throw new RuntimeException("An exception has occurred while reading build file", var6);
}
} else {
throw new RuntimeException("Could not resolve target image for application: " + applicationName);
}
}
But I'm confused. What filesystem? Like, what is the present working directory? My local computer, wherever I ran the Java program from? Or is this from within some container? (I don't think so.) Or maybe the directory structure inside a .jar file? Or somewhere in gcr.io?
What does he mean about a "specific version number" vs. "latest"? I mean, when I build this project, whatever it built is all I have. Isn't that equivalent to "latest"? In what case would an older version of an image be present? (That's what made me think of gcr.io.)
Or, does he mean, that in the project using this project's image, one will not be able to specify a version via Maven/pom.xml—it will always spin up the latest.
Sorry this is long, just trying to "show my work." Any hints welcome. I'll keep looking.
I can't comment on specifics of your own internal implementations, but ImageResolver seems to work on your local filesystem, e.g. it looks into your target/ directory and also touches the classpath. I can imagine this code was just written for resolving an actual image name (not an image), since it also returns a String.
Regarding latest, using a latest tag for a Docker image is generally considered an anti-pattern, so likely your colleague is commenting about this. Here is a random article from the web explaining some of the issues with latest tag:
https://vsupalov.com/docker-latest-tag/
Besides, I don't understand why you ask these questions which are very specific to your project here on SO rather than asking your colleague.
I have an old program original written for java 1.3 that trys to get resource bundle :
java.text.resources.LocaleElements
and if that fails trys :
sun.text.resources.LocaleElements
ResourceBundle r=null;
try {
r = ResourceBundle.getBundle("java.text.resources.LocaleElements", zomLocale);
}
catch (Exception ex) {
try {
r = ResourceBundle.getBundle("sun.text.resources.LocaleElements", zomLocale);
}
catch (Exception ex1) {
ex1.printStackTrace();
}
}
This worked fine in 1.3 but these bundles do not exist in java 1.4.
I don't now enough about java as to know:
Where these resources comes from or
How I install them or
How to list what resource bundles are now available in 1.4 or
If I can simply provide the new/replacement name for the resource I want/need
I don't even know how I came up with the original resource bundle names in the first place.
I suppose the simplest solution for me is to determine what are the replacements for these missing bundles.
I'm using netbeans 12.2 maven (Ubuntu 20.04) if that make any difference!
Edit:
looking at the jdk packages :
https://openjdk.binarydoc.org/net.java/openjdk/14.0/package?package=sun.text.resources
I can see that "LocaleElements" no longer exists. A general search doesn't find anything for LocaleElements. So maybe the technique I was employing isn't valid anymore.
If the only thing I need out of LocaleElements is "DateTimePatterns" are there any suggestions how I should instead be doing this?
I have develop a simple java program to run APDU commands. It is working fine.
The file structure is
/moc
/omnikey
--Applet.java
--API.java
/omnikey.api
/omnikey.util
... another 3 more packages ...
Now, I want to extract all those extra packages to a new project and leave only the omnikey package (with Applet.java and API.java) to create a .jar with the needed functionality.
So I created a new project, copied all files, fixed the packages references and linked the external jars needed... and now it doesn't work...
The "new" file structure is like this
/apdu
/apduservice
/api
... files ...
/util
... files ...
/moc
/omnikey
Applet.java
API.java
For some reason, the execution hangs when I declare something from the apdu project. If I do
System.out.println("flag 1");
try {
apduservice.api.MocService ser = new apduservice.api.MocService(null);
} catch (CardServiceException e) {
e.printStackTrace();
}
System.out.println("flag 2");
I get no error trace and the output is flag 1. The execution doesn't stop until force it.
If I try the same thing with the previous configuration everything works.
System.out.println("flag 1");
try {
omnikey.api.MocService ser = new apduservice.api.MocService(null);
} catch (CardServiceException e) {
e.printStackTrace();
}
System.out.println("flag 2");
//output flag 1 and flag 2
I'm not sure where the error might be. I tried exporting the second project as jar, as runnable jar, reference it as a project inside Eclipse, and nothing, the same result. I've tried searching for a solution, but since I get no error, it's hard to know what to look for.
If someone could shed a light I'll be grateful.
PD: doesn't seem to be an Eclipse problem, I've referenced projects in other projects and it has work fine...
PD2: I'm not using Maven or anything like that to handle references. I rather not to, at least for now.
Decided to answer this since there's no logical reason for this to happen.
Solution:
change workspaces, open the two projects and link them. Eclipse was just having one of its days.
I'm trying to open an URI with Swing that I get above error.
What is the reason and how can I fix it?
When I do it in console everything is OK but when I do in GUI I get this error.
I should say that I use Weblogic as server.
Code
private static void open(URI uri) {
if (Desktop.isDesktopSupported()) {
try {
Desktop.getDesktop().browse(uri);
} catch (IOException e) { /* TODO: error handling */ }
} else { /* TODO: error handling */ }
}
Stack trace:
Exception in thread "AWT-EventQueue-1" java.lang.NoClassDefFoundError: java/awt/Desktop
at be.azvub.ext.bcfidownloder.BcfiDownloadPanel.open(BcfiDownloadPanel.java:230)
at be.azvub.ext.bcfidownloder.BcfiDownloadPanel.access$000(BcfiDownloadPanel.java:37)
at be.azvub.ext.bcfidownloder.BcfiDownloadPanel$7.actionPerformed(BcfiDownloadPanel.java:147)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.Component.processMouseEvent(Component.java:5517)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3129)
at java.awt.Component.processEvent(Component.java:5282)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3984)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3819)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1791)
Doc on NoClassDefFoundError
The searched-for class definition existed when the currently executing class was compiled, but the definition can no longer be found.
You do have some incorrect classloading happening. Mostly due to wrong class loader chaining.
NoClassDefFoundError can only be caused by a classpath problem.
Because Desktop is part of jre, make sure that your classpath contains a reference to the jre library.
In Eclipse, you can go to run configurations --> Classpath and check there
UPDATE:
As Andrew suggested, you can also check you have at least java 1.6
java.awt.Desktop has been introduced in Java 6. Chances are high you're running your code on different JRE versions.
I am running the following code in a JUnit test to test fetching a git repository. I'm writing a test for each of the basic functionality i need from JGit so that then i can implement them in my application. The problem is that i keep getting the following error on the git.fetch() call below:
Loading of translation bundle failed for [org.eclipse.jgit.JGitText, en_US]
org.eclipse.jgit.errors.TranslationBundleLoadingException: Loading of translation bundle failed for [org.eclipse.jgit.JGitText, en_US]
The code sample is below. I verified that the repository paths and everything seems correct. If i put a breakpoint on the fetch call and then run the same command in MSysGit it works.
try {
String remoteName = "origin";
URIish uri = new URIish(repository.getRepositoryDirectory());
saveRemote(repository2.getRepository(), uri, remoteName);
Git git = repository.getGit();
FetchResult r = git.fetch().setRemote(remoteName).call();
assertNotNull("Did not get any result from fetch.", r);
} catch (JGitInternalException ex) {
fail("Failed to do fetch. " + ex.getMessage());
} catch (InvalidRemoteException ex) {
fail("Failed to do fetch. " + ex.getMessage());
} catch (URISyntaxException ex) {
fail("Failed to do fetch. " + ex.getMessage());
}
Thanks!
Okay I figured this out. I had to copy the file JGitText.properties from the binary distribution into the same package in the source code, rename it to JGitText_en_US.properties, and add a whole bunch of properties to it manually that the code used in JGitText.java but were not defined in JGitText.properties.
I searched through the entire source code and all binary files and related docs and found no reference to these new properties, or the properties file being created anywhere. I don't know why the devs don't have localization files in the source code or at least a way to generate then through a build file or something. I mean they must manually have to add them into their source code and just not commit it.
Anyway this was a very annoying issue, there was no documentation on it anywhere on the net (that google revealed anyway) so I thought i would share this as it might help others who ran into the same problem.
I had the same problem, but my fix was a little different. In my case, the problem was related to the OSGI classloader.
Here's a commit that fixes the issue:
https://github.com/diffplug/jgit/commit/3bcc69bde5567ec57ccd6bd065ded0db49f810fb
And here's the rationale behind it:
Loading a ResourceBundle within an OSGi bundle