I came upon this simple Library that someone wrote in java GetImageText.java for OCR in images so i tried compiling it on my Ubuntu via terminal but i get several error as shown below in this paste :
Compilation Errors
Can Someone help me with it , it is absolute necessity that i test this code , its explanation can be found here
I think the problem is that i do not have com.sun.image.code.jpeg in my system, although java is definitely installed. Although I am not sure how to import this package without using an IDE.
The problem is that the library you are trying to recompile depends on INTERNAL classes1. Portable libraries are not supposed to do that!
What has happened is that the class has been removed or replaced. This happens from time to time, and that is the reason that people are not supposed to write code that depends on INTERNAL classes.
Solutions:
Bug the authors of the library to fix the problem.
Figure out which version(s) of Java that the library supports, and stick with those.
Find an alternative library that supports the version(s) of Java that you need.
Non-solution: Compiling the library on an older version of Java and running on a newer one is likely to fail. The class needs to be present at runtime, as well as at compile time.
1 - Anything in the "com.sun" tree counts as INTERNAL. Sometimes people have no choice but to have such a dependency. However, they still needs to deal with the potential consequences for portability.
Related
I have established through another question that the problem I'm having with my JavaFX program is due to a bug in the JDK that is not going to be fixed anytime soon. I was even informed that the bug is in PrismTextLayout.
So having found the source code for this, how would I implement some kind of patch which would allow me to fix this bug for my application only. Obviously if I did fix the problem, I would contribute it back to a future JDK, but for now I just want a quick fix.
I thought a simple google search for patching the JDK, etc would turn up heaps of information, but actually, virutally nothing.
Can someone, if not explain how to patch, at least point me in the right direction for some documentation on this subject.
Patching a JavaFX class without actually building the whole JDK or JavaFX is quite easy. I did that for example for the class SVGPath some time ago.
Extract the class source from the source zip which is distributed with the JDK and add it to your project in the correct folder according to its package name. In my case this would be javafx/scene/shape/SVGPath.java.
Explicitly add ${JDK_HOME}/jre/lib/ext/jfxrt.jar to your classpath.
Run your program with the java options "-Djava.ext.dirs=".
This procedure is essential to be able to override the existing classes in jfxrt.jar.
That is it.
I am trying to use Vowpal Wabbit through Java. I have downloaded and successfully compiled the code from GitHub. The command line tool works fine.
After having a quick look at the repository (especially here), I can only assume that using it through Java is supposed to be already possible, and I don't really want to reinvent the wheel.
A wrapper around Vowpal Wabbit that allows use through Java. This wrapper is designed to be self contained. Because
of the use of JNI, a number of platforms are supported in this JAR.
I have added the maven dependency (found here) to my project, but without any kind of document, I don't really know where to start.
I have seen in another question that it seems to be possible to use VW with Java, but the guy only uses Runtime.getRuntime.exec() to call his bash command, and I can't find any documentation about any other way of doing (and there are only 2 questions mixing VW and Java on SO, which doesn't help).
I am new to JNI, so most likely there is something easy that I don't see.
To be perfectly clear, my questions are :
Should I just make a valid vw command and use it through Runtime.getRuntime.exec()? This doesn't seem to be the spirit of JNI, for there is no need for any wrapper/library for this. Plus, this doesn't make it very portable.
Where (the hell) is the (Java API) documentation ?
Any kind of help or guidance would be welcome.
I was one of the two primary authors of the VW JNI wrapper. Since the posting of this question the interface has significantly changed. We now encourage users to compile the native side on their own and provide it on the java.library.path. We have updated the README significantly to show how to use the library from Java.
I totally agree with your criticism that we have not published the Java API. I will work on that the next time I modify this code. In the meantime please feel free to clone the library and run mvn install and you can generate the Java API docs yourself. They should be quite detailed as we spent a lot of effort writing detailed docs.
You may checkout vowpal wabbit JNI wrapper we've built in Indeed: https://github.com/indeedeng/vowpal-wabbit-java.
We wrote integration test that can work as usage examples and we wrote API documentation as well. Check "using the library" section of README.
Hope this will help.
I don't think this adds a lot, but none of the previous answers really provided a clear answer. Like #Macchiatow mentioned, to use the Java wrapper which comes with Vowpal Wabbit, you would:
(on the project root dir) make all java or make java
cd into java and verify the installation with mvn test
you'd then mvn install to have the Java API jarred up and placed in your local maven repository. Supposedly this builds the JNI parts on your machine, so as to fit the C/C++ libraries of your platform if you have the necessary native C/C++ libraries installed and available to the make command.
you'd supposedly be able to include the vowpal package/s from those jars in the build tool used in your own project (ant/maven/boot/leiningen/sbt/etc. as in here).
For more background maybe see the Vowpal Wabbit Java readme. I think what it tries to say there, is that if you want a ready made jar from maven central, you should make sure it's the same vowpal version you're using, but without knowing more I'd guess if you built it like above, you are by definition using the same version.
I've had the above process work off a fresh clone, with Ubuntu 16.04 and Java 8.
This link may be of some help with regards to setting up a JNI wrapper.
I wasn't able to find Java API documentation anywhere, but Java code seems well documented - did you maybe try generating Javadoc yourself from the code?
There is indeed Java JNI wrapper to have a basic access to VW. By basic I mean to teach your model and to predict probability later on. They also provide Python library that can do far more than wrapper for Java. Recently I was forced to expose few more VW methods to Java by extending code provided.
Back to the questions:
Rather use the vw-jni artifact available in central maven repo and clone their code and run make all java. I some cases compiling code yourself will be the only solution, as for example provided artifact won't run on OpenSuse (my case)
Code available pretty straight forward. VWLearners::create is a factory to get an instance of VW from Java.
I am developing an Android app in Eclipse. I would like to target a wide variety of devices and SDK versions (for example, I can optionally support multi-touch). I understand the recommended approach of isolating all the new functionality to a separate class and leveraging lazy loading to only load that class at run-time if the host device actually supports the feature.
The downside of this approach is that I have to compile all of my code with the SDK of the newest feature I want to use. Which means if some new feature leaks into my "version neutral" code, the compiler can no longer catch it.
I would like the ability, within Eclipse, to compile my project against an older Android SDK to make sure my "version neutral" code is fine. I'd like to avoid moving my build system out of Eclipse, if possible. I'm okay with this old-SDK build being a bit awkward to run.
I think this boils down to doing some conditional compliation (or conditional "linking") inside Eclipse? For example, in my project when building against SDK-1.6 I'd like to leave the "MultiTouchHandler.java" source out of the build. I'm not sure if its possible to express "build types" like this in Eclipse, though.
The hacky solution seem to be just manually changing the project's SDK version, rebuilding, and looking through the errors, and ignore 'expected' errors. The overkill solution seems to be writing my own ant/maven/make build scripts.
Related Questions
This question:
Versioning and common code-bases with Eclipse
covers similar ground, but would involve moving all of the version-specific classes into separate "libraries". (And I would still have the problem of multiple build types in Eclipse, I think.)
This question:
Build multiple project configurations with eclipse implies that I should move to an external build system (like ant or maven), but that's a lot more work than just trying a build with an old SDK from time to time.
The February 2012 (v17) updates to the Lint Tool in the ADT should help address this without requiring multiple builds. When an app targets an old minimum SDK, but is compiled against the newest SDK (as is the recommended practice), the lint tool will notice if calls to the newer SDK are invoked. If you're confident the call is okay (Because you've hidden it behind a run-time SDK_INT check, or whatever), you can Quick-Fix an annotation to prevent the warning.
For example, in my code I have a call to View.setSystemUiVisibility, which was introduced in API 11, but I'm targetting API 8. Running Lint shows:
Call requires API level 11 (current min is 8): android.view.View#setSystemuiVisibility
The QuickFix suggests two kinds of fixes, either adding an annotation that suppresses the warning or adding an annotation that declares a chunk of code as working at API 11.
More details here: http://tools.android.com/recent/lintapicheck
A somewhat less clean/less performant method would be to use reflection to access the newer apis that you need, rather than trying to reference them directly with lazy loading. This should allow you to compile against a lower sdk level.
This simple line of code gives the error "The method getTextContent() is undefined for the type Element":
String color_string = ( ( Element )( ( Element )inner_node ).getElementsByTagName( "color" ).item( 0 ) ).getTextContent();
I get the error in my Android-java version, but not in my PC-Java which I use for testing and debugging Java code before I run it on the phone.
I have
import org.w3c.dom.Element;
on both versions. And I copied the code from the PC-Java to the Android-Java so I am 100% sure I have the same syntax on both.
The android reference says there is such a method defined for the Element class. So perhaps you are missing some libraries, or have a wrong version.
#Aspen - the answer is that you are using the wrong libraries on your PC. You should be compiling your application against Android level 7 libraries, not against Sun Java libraries.
You should be able to correct this for test compiles by downloading the relevant Android JARs and putting them on your compilation bootclasspath. But I would NOT recommend trying to run code like this on a PC Java platform. (It might work, but you might also end up chasing lots of problems caused by doing this.)
EDIT
A better idea might be to use Eclipse with the ADT plugin, as described on this page.
after checking a lot and scratching my head thousands of times I came up with simple alteration that it needs to change your API level to 8
Android Java is not Sun Java. Androids Java based on Apaches Harmony project (Re-Implementation of Sun Java under an open license). Some details can be different.
Wiki has a list of the java packages and their origins.
Is there a quick way (e.g. tool) to detect, from the source (or maybe even from compiled classes), which parts of an application call Java API methods that are only implemented in a specific Java version? (e.g. which parts of my app are Java6-specific)
I don't necessarily want to hop through all ClassMismatchErrors and avoid the trial-and-error-method. Let's say I only want to document which parts of an application won't work if they were writte for, e.g., Java6 and I want to run it in a version 5 JDK.
Is there something like this? Google did not help this time, nor did I find any solution here (a rare case indeed:)
The Animal Sniffer might be helpful for this, especially its Maven plugin.
If I understand you correctly, what you're describing doesn't sound like a very good idea to me.
It sounds like you want to build some library on JDK 6 (specifying -target 1.5), but let it be run on JDK 5 and just have certain classes or methods here and there just not work (because they needed a Java6-only API). I wouldn't do this. A method which should work might still trigger a class to be loaded which itself contains some reference to a class that's new in Java 6, and an Error will be thrown.
It's much better if you just choose which version is your minimum supported version and live with that.