Develop Reference

java 1.3 to 1.4 text resource local elements (resource bundle)

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?

ExceptionInInitializerError when running simple DL4J code

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.

Try/Catch not catching exception

I'm trying to do java class loading. I'm using eclipse (luna) with 1.8.0_25 on a macos yosemite.
I'm using the following code in order to do it. It's working, until it reaches a class that has a dependency that isn't contained inside the jar that I'm loading classes from. Neither on the environment.
I'm not interested in this classes, so, it's safe to ignore then. So, I put it inside a try/catch and just log it.
But, when the exception occurs, the execution is canceled.
The exception (summarized) is:
Exception in thread "main" java.lang.NoClassDefFoundError: org/aspectj/runtime/internal/AroundClosure
Caused by: java.lang.ClassNotFoundException: org.aspectj.runtime.internal.AroundClosure
It rises at the exact line that is inside the inner try/catch block.
Why? Shouldn't the try/catch just log it and move on?
URLClassLoader ucl = null;
try {
URL url = Utils.getURIFromPath(jarFilePath).toURL();
URL[] urls = new URL[] { url };
ucl = new URLClassLoader(urls);
for (String tmp : classes) {
String clazz = tmp.substring(0, tmp.indexOf(".class")).replaceAll("/", ".");
try {
ucl.loadClass(clazz);
} catch (Exception e) {
LOGGER.error(e.getMessage(), e);
}
}
} catch (MalformedURLException e) {
LOGGER.error(e.getMessage(), e);
} finally {
if (ucl != null) {
try {
ucl.close();
} catch (IOException e) {
LOGGER.error(e.getMessage(), e);
}
}
}

NoClassDefFoundError is an Error, not an Exception, you should never1 try to catch an error, as stated here, catching it won't help you.
Check your classpath and fix it.
1 In some cases you might want to catch an error and handle it accordingly, as stated in the comments, maybe "never" is a little bit strong

Ok then try this:
catch (Throwable e) {
LOGGER.error(e.getMessage(), e);
}
Although using the above code will handle both Errors and Exceptions for you (both extend from Throwable), but it's not the right way to do it, only in very special cases do we handle errors using try-catch, errors are something we need to check in our code and resolve them.

It seems that one of the classes that you're using, probably one of the classes that you're trying to load with loadClass, has a dependency to classes from AspectJ, but the ClassLoader does not find the AspectJ classes. A possible solution is to make sure that AspectJ is on your classpath when you execute this.
It might also be that AspectJ already is on the classpath. If that's the case, it's just that your URLClassLoader doesn't know of your ClassPath. You might want to construct the URLClassLoader with a parent ClassLoader in place, like this:
ucl = new URLClassLoader(urls, getClass().getClassLoader());
The reason why the program doesn't just move on is that you're catching Exception. The hierarchy is class Throwable, class Exception extends Throwable and class Error extends Throwable, so catch (Exception e) will not catch Error. You might want to use catch(Exception | NoClassDefFoundError e) in this special case. Usually, catching Errors is not a good idea, but sometimes there are reasonable exceptions for errors like NoClassDefFoundError, OutOfMemoryError or StackOverflowError.

Calling C++ From JMS with JNI

I'm trying to call Sleuth Kit C++ Framework through its JNI wrapper from a JMS MessageListener. But I'm getting this error
java.lang.UnsatisfiedLinkError: /tmp/libtsk_jni.so: libtsk.so.10: cannot open shared object file: No such file or directory
I tried coping the libtsk_jni.so to /tmp but no difference.
But I can do this in a Java console application. What could be the error?
public void onMessage(Message message) {
try {
String imagePath = "uploads/Cfreds001A001.dd";
try{
SleuthkitCase sk = SleuthkitCase.newCase(imagePath + ".db");
} catch (TskCoreException ex) {
}
} catch (JMSException ex) {
Logger.getLogger(WorkerBean.class.getName()).log(Level.SEVERE, null, ex);
} catch (InterruptedException ex) {
Logger.getLogger(WorkerBean.class.getName()).log(Level.SEVERE, null, ex);
}

Attempting to use native methods from code running in a Java EE container is not allowed by the standard and may cause undefined behavior. See the JavaWorld article from August 2000 "Programming restrictions on EJB", still true today as far as I know.
Depending on your Java EE container, you may in fact be able to get this to work. It may help to put the libtsk_jni.so in the system library directory or to edit the server's start script to set the LD_LIBRARY_PATH environment variable.

JGit/EGit Loading of translation bundle failed en_US

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