I want to transliterate (not translate!) text from arbitrary (as far as possible) languages to English in an Android app. Is there a built-in way?
I've found https://android.googlesource.com/platform/libcore/+/master/luni/src/main/java/libcore/icu/Transliterator.java but it doesn't seem to be available by default (at least the IDE doesn't find it). Do I simply need to add this code, as suggested by the comment in Where can I get a JAR to import libcore.io??
Alternately, I could add ICU4J to dependencies and follow icu4j cyrillic to latin. But this is a very large dependency (though Proguard should help).
Finally, I could easily add transliteration from Cyrillic myself and wait until/if someone actually needs other languages (with obvious drawbacks).
Under the hood, Android has all of ICU4J available under android.icu, but only a subset is exposed as public API. If you want to use a class that isn't exposed, you can write code that uses the class and it should work fine. However, doing so is not technically supported, so there could be some version of Android somewhere that doesn't have the class for whatever reason and causes your code to break. (This is unlikely to happen in practice, but possible nonetheless.)
NOTE: The namespace android.icu was added in Android 7 Nougat, so it may or may not be usable yet depending on the version of Android you are targeting.
try compile "org.robovm:robovm-rt:+".
robovm-rt has libcore inside. works for me.
Related
I am trying to write a standalone Java application in IntelliJ using edu.stanford.nlp.trees.GrammaticalStructure. Therefore, I have imported the module:
import edu.stanford.nlp.trees.GrammaticalStructure;
Currently, Intellij doesn't recognize this and many others of the imported external libraries (cannot resolve the symbols) and is also not able to automatically download/import them.
Is there a way to use the GrammaticalStructure class without having to download the entire Stanford CoreNLP .jar and adding it to the project as a library? This question applies to other dependencies as well, since I want to use other external libraries but avoid including their .jar files as much as possible (to minimize the size of the final application, given that it will be standalone). Unfortunately, all the solutions I have found proposed exactly that.
Apologies if I have overlooked some basic setting or setup steps, it has been a while since I have worked with Java.
Any help is greatly appreciated.
If you want to use it means you want to execute the code in them. How is the runtime supposed to execute code that is does not have? How is the compiler supposed to know how the code is defined (e.g. what the classes look like)? This is simply impossible. If you want to use the code you have to provide it to the compiler as well as the runtime.
If you just dont want to include all of that code into your application, you need either access to the sources and just pick the class you need or you need some kind of JAR minimizer as #CrazyCoder suggested.
I am aware that it's quite a weird use case to depend on having JVM installed for some OS source sets, allow me to go through my use case.
I'm writing a simple utility to wrap calls for the steamCMD (https://developer.valvesoftware.com/wiki/SteamCMD), which has platform dependent installation procedures. So, naturally I should have
// commonMain / steamCmdGetter.kt
expect interface SteamCmdGetter {
fun installClient()
}
// [OS] / steamCmdGetter.kt
actual interface SteamCmdGetter { /* ... */ }
On the other hand, my utility also needs to do work with the file storage (for example, downloading and checking client existence in storage), so I could also use a file class.
// commonMain / File.kt
expect interface File
I am aware that the JB team has an explicit recommendation on its tutorials.
We recommend that you use expected and actual declarations only for Kotlin declarations that have platform-specific dependencies. It is better to implement as much functionality as possible in the shared module even if doing so takes more time.
Yet, against the warnings I wish not to write a MyFile implementation to save efforts from reinventing the wheel for such a common task, but java.io.File has been so dominant in the scene that I could not find any Kotlin alternatives on Gradle / Maven.
Does this means I am forced to write MyFile in the end? Or is there a workaround for importing Java libraries to Kotlin MPP platform sourceSets?
First of all, one can use Java libraries only for jvm and android targets, not the others provided by the Kotlin/Multiplatform. In fact, this is exactly a targets subset that is using Kotlin/JVM. Neither Kotlin/JS nor Kotlin/Native provide interoperability with Java, they has their own interop capabilities. See this page to get some details on the difference. About working with files in particular. Most probably the answer is yes and you'll have to implement it per-target. This kind of work is usually platform-specific, as it hardly rely on the OS implementation. However, part of the functionality you search for should be definitely found in the platform.posix.* platform library, even if it would appear more C-stylish.
P.S. Quick search across the Web led me to this community libraries list, maybe it would help. Also, kotlinlang Slack community(find link here) may have some interesting solutions to share.
I am trying to create a simple server program to handle http requests. So with minimum search, I stumbled upon the oracle documentation for the httpserver class, inside the com.sun.net package. I'm relatively new to Java, so I thought that a class "sponsored" by Oracle itself would be included in the default libraries.
Unfortunately, that was not the case. After a lot of trials for possible syntax-import errors (various kinds of error arouse) and having installed the Oracle JDK 8 correctly on my Ubuntu machine, the compiler said that the package did not exist. What do I have to do to get the package to work?
I did finally make it work. Mostly, it was a misunderstanding from my place, since I only imported up to a point that was wrong - that is,I only imported com.sun.net.httpserver, thinking the latter part was the actual class I wanted, but it was merely the package name. So then I proceeded to import com.sun.net.httpserver.HttpServer, then the rest of my classes. Finally a com.sun.net.httpserver.* would work perfectly fine. It seems stupid now that I figured it out, but I think I will leave it here just in case anyone has the same misunderstanding - I already see 1 favourite on the question. And of course, as others have pointed out, the package is not part of the standard java libraries, but I used Oracle Java specifically for that.
P.S. The class is really useful, unlike what the other answer implies, but now I have stumbled upon another problem regarding reading the request body right, something that might have to do with the locale of the client-server, and I will now procced to search that.. Just a warning for anyone thinking of using the package.
Firstly try to avoid com.sun.xxx package, as those are internalls of Oracle/Sun java implementation.
Secondly, why not use libraries from apache ? See https://hc.apache.org/
EDITED:
You can also look on http://sparkjava.com/ , not tested but examples looks promising and they are using Java 8 nice features.
I was reading an answer to a different question on SO, in which #RomainGuy commented that one could (please correct me if I'm paraphrasing incorrectly) back-port code from later versions of android to earlier versions. Specifically, I am interested in back-porting code for BitmapRegionDecoder from Android version 2.3.3 (Gingerbread) to version 2.2.2 (Froyo).
I would have rather asked the question more generally as what is the best practice / what should be avoided when back-porting code from newer versions of Android to older versions, but stackoverflow hinted that my question might be closed as being too subjective.
Maybe if there is enough interest in the topic, this question could be "morphed" into a more general one..possibly a community wiki?
In any case, I would appreciate any insight into how this is done..whether specific to my use case, or more general advice. Do calls to native methods from within the java class complicate the matter (necessarily involving the NDK)?
If it is indeed possible (and reasonable) to cherry-pick and back-port code in this way, I think many would find it very useful to know how.
As #hackbod mentioned BitmapRegionDecoder is based on external skia library. Yet it's may be a benefit.
Let's examine original source:
BitmapRegionDecoder.java. Mostly defines wrappers around native methods:
private static native Bitmap nativeDecodeRegion(int lbm,
int start_x, int start_y, int width, int height,
BitmapFactory.Options options);
private static native int nativeGetWidth(int lbm);
private static native int nativeGetHeight(int lbm);
private static native void nativeClean(int lbm);
// ...multiply nativeNewInstance overloads follow
Class doesn't use any new Java APIs we'd need to backport.
BitmapRegionDecoder.cpp. Header files it includes consist of ones which are present in Froyo except these two:
AutoDecodeCancel.h. The only line it's used in:
AutoDecoderCancel adc(options, decoder);
This class handles SkDecoder instances lifecycle. It's a small piece of code and may be well back-ported.
SkBitmapRegionDecoder.h
As filename states this is a core component. In fact, all previous were a kind of wrappers around it. The good news is that we may not need to back-port it as it should be possible to take a whole skia library from the Gingerbeard and compile it under Froyo as it is external and doesn't contain any new dependencies.
P.S. I didn't actually dive deep in the code so please correct me if there's anything I overlooked.
Update:
Source code we need is located in following repositories on branches froyo-release and gingerbread-mr4-release:
External skia library repository
Header files are in include/core and include/images
Android framework base
Java code: graphics/java/android/graphics/BitmapRegionDecoder.java
Native code: core/jni/android/graphics/...
You can back-port some code, if it can exist on top of the SDK you are porting it to.
You can't back-port anything. For example, you couldn't back-port a kernel feature. :)
In this case, there is no easy solution to back-porting it. The implementation of this sits on top of Skia and the jpeg decoder, which are both native code. You will need to do your own implementation of that code. You could try copy/pasting the code from the platform, gluing it in with your code with JNI, but this will be a significant amount of work and leave you with native code you need to continue to maintain.
Sorry there is no easy solution for this.
You should consider BitmapRegionDecoderCompat, an API 8+ version of the standard BitmapRegionDecoder (API 10+).
Features
It operates in "compat" mode on devices running API < 10 using a basic
Java/Android fallback (which means it won't be as efficient/fast as the native JNI implementation of API 10+, but it will avoid ugly boilerplates and manual fallbacks).
It uses the native JNI implementation when running on API 10+.
It adds extra usuful methods like decodeBestRegion(),
which extracts the "best" image subregion given your parameters (gravity, size). This method also works on API < 10.
Download
In order to use it in your project you can manually download and add the library as an AAR file:
or you can add the dependecy in your build.gradle (requires jCenter repository):
dependencies {
//...your dependecies
compile 'org.bonnyfone:brdcompat:0.1'
}
Usage
As stated in the docs, in order to migrate to BRDCompat you just need to change the base class name from BitmapRegionDecoder to BitmapRegionDecoderCompat:
//BitmapRegionDecoder brd = BitmapRegionDecoder.newInstance(...);
BitmapRegionDecoderCompat brd = BitmapRegionDecoderCompat.newInstance(...);
What is the purpose of the classes in this package?
I want to use Base64 encoding in my app. As I'm typing away in Eclipse, I am prompted if I want to import a class called "com.google.appengine.repackaged.com.google.common.util.Base64"
I can't find any documentation about what this class does. No javadoc, or no mention in the Google App Engine manual (that I can see). Is this some kind of "hidden" API that I'm not supposed to have access to?
Is this some kind of "hidden" API that I'm not supposed to have access to?
Yes.
The purpose of repackaging Java classes is to have a private copy of a library that otherwise might conflict with another version of that some library (that the application developer adds to his project as a jar file).
It is one possible answer to JAR-hell.
Even the JDK makes use of this mechanism, e.g. with com.sun.org.apache.xerces which is an XML parsing library developed by the Apache Project that Sun choose to include (repackaged).
Do not call these classes directly. (You could, and they would probably work okay, but as they are not part of the official API, they could disappear in the next version).