I have been working on a Android Web Services program that uses a number of classes from Sun's javax libraries. The eclipse IDE is barking "Attempt to include a core class (java.* or javax.* ) in something other than a core library." My application is an Android application and I am not creating a core library. I am using several .jars; javax.xml.ws, javax.xml.bind, javax.xml.soap, javax.xml.rpc, and javax.jws. I believe I cannot use these java bytecode .jars directly. I will have to use the dx tool to convert them to delvik bytecode or .dex files. I have done some additional research and have found that use of any javax.* classes in an android application are forbidden. Can someone explain why? Are their practical programming work arounds?
Thanks,
Steve
That's because those jars use core core libraries. Android does not support the complete J2SE, but rather a subset of it: http://developer.android.com/reference/packages.html
Thus, you cannot use Java core libraries because they don't belong to the Android SDK.
You need to use an alternate library to handle SOAP in Android - the Sun provided libraries do not work.
One popular alternative is KSOAP2.
Start with an enhanced version of kSOAP called ksoap2-android:
http://code.google.com/p/ksoap2-android/
Then add a tool that generates kSOAP stubs based on a WSDL called wsdl2ksoap:
http://code.google.com/p/wsdl2ksoap/
Not quite as advanced as wsimport, but this gets you pretty darn close.
Related
I am trying to use SQLCipher within Android. They made it very easy to integrate by adding the dependency:
implementation 'net.zetetic:android-database-sqlcipher:4.2.0#aar'
They have nice and simple examples of then using this in Java, but my application is c++ and I am using the NDK. SQLCipher is primarily C code so I know that this is linking against some compiled C code. Are the headers available for use? Where are these dependencies being installed. I am an iOS developer new to Android so I feel like this should simple but I am just missing something.
There's currently no support for consuming C/C++ dependencies from an AAR. We're working on this here: https://github.com/android-ndk/ndk/issues/916
But I should note that even when that is complete, sqlcipher does need to choose to expose that library. The AAR would not currently contain includes, and it may not be a stable API so they may choose not to expose it.
For a library to be usable directly by ndk, you'd need a .so version of it to link against. If you're including the library like this, you'd use JNI to access it via Java.
I'd recommend against hacking something up to access their .so files directly. Its quite possible their Java code has business logic that prevents errors or initialized things that are not set up properly if you go right against their .so file.
I'm a kotlin and Java developer, and recently I started analyzing the bytecode generated by kotlin. And I found out a lot of wrapper code and other stuff that the compiler generates in order to translate what I have coded in Kotlin to Java.
So, my question is:
Imagine that I have an app that its code is 100% written in kotlin. Dependencies and the main app. All Kotlin.
Does this mean that a different compiler will be used in order to avoid Java compatible bytecode?
Or is there any optimization done by the compiler in this kind of scenarios?
Many Thanks.
I know about Kotlin Native but I think it will only be applied to Android in the future.
The only way you're going to avoid Java bytecode with Kotlin is to use Kotlin Native, and you won't be able to use the Android SDK in that case.
Kotlin JVM, as the name implies, compiles to JVM bytecode; it's one of the main draws of using it. If it compiled to something different, it would be Kotlin Native.
To answer your bullets:
No, the same compiler is used whether or not you have Java source files.
Probably not. Kotlin JVM is made to be almost completely interoperable with Java, and that's the same whether or not your project includes Java code.
Think about if you were creating an Android library in Kotlin. Would you really want it to automatically compile to something other than Java bytecode in that case? It wouldn't be able to be used in Java projects, defeating one of the main reasons Kotlin is so good as a Java alternative.
Also remember, you're using the Android SDK. Even if you have no dependencies in your build.gradle, you still reference the core SDK itself, which is Java. The SDK isn't included in your APK, but it's still used during compilation.
If you want something that avoids Java bytecode, use something like Flutter. It has its own SDK, and can bridge back to Java components. Of course, you can't completely avoid the JVM, because you still need some way for Android to install and open the app.
I am creating a cross platform application in java using libgdx. I am using Json in the core project and was trying to deploy on Android when I received this error:
E/AndroidRuntime(2030): java.lang.NoSuchMethodError: org.json.JSONObject.getNames
I read around and I found out that Android has a built in Json library that uses that same package name as the Json library I added to my core project. The library I use has the getName() method and the Android library has a name() method. Is there a way for me to specify the library I want to use? Alternatively, is there a way for me to ignore the Android library?
Update: I tested accessing the JSON method in my android project using
JSONObject.getNames(TEST);
which should have given me null, but instead gave me the same error.
if you happen to use a lib, that uses the same namespace/package name as another, you are at the mercy of the classloader, which usually picks the first place, where it can find the class by name.
so the easiest way to circumvent this is either to use the same library and version as used on android or move your library in another package.
if the library in question allows it (licence etc) and is reasonable small, you might be easier off just pulling in the source files in your project and let the IDE do the refactoring magic. Also there are tools like jarjar.
There are some question on SO (Calling same Method having same packageName From Different JARs, Java, Classpath, Classloading => Multiple Versions of the same jar/project). So you might be able to circumvent this problem, but my gut feeling is, that you will end up in big mess.
My application depends a lot on the JSON library org.json.*. This package is built-in into Android standard libraries, something I didn't know because I also included it in my source tree.
I need to use a function (JSONArray.remove) that is not supported on the built-in package, while it is in the source distribution jar from org.json (that I include in my project). So what happens is, everything compiles & all, but I get java.lang.NoSuchMethodError: org.json.JSONArray.remove at runtime.
My question is, how can I tell eclipse or Android to use the org.json.* from my source tree instead of its built-in version?
And a sub-question: Is it a good idea at all? May the built-in JSON package have native-level improvements or something like that vs. the official source code distribution?
My question is, how can I tell eclipse or Android to use the org.json.* from my source tree instead of its built-in version?
You can't. You do not control the runtime classpath, and the firmware always wins.
You are welcome to use jarjar or a similar tool to move your copy of the org.json classes into a new package. Or, find a better JSON library -- there's lots of them out there.
Hey guys!
I've been working on c++ application lately which has to be run on Android 2.1 and 2.2.
so I am wondering if I have complete c++ application can I just put it into *.so file and then create android project and just simply load this library using System.loadLibrary(blalba.so);
would it work?
Yes you will have to recompile all the native libraries specifically for Android. Yes, you do need the source code for all 3rd party native libs you plan to use simply because Usually when we compile and link these libraries outside Android they are linked to glibc but unfortunately Android doesn't use glibc due to liscence and performance issues. Android uses a watered down version of glibc called libc. It has matching symbol names to glibc for most of the usual functionalities. But as far as i know the libc doesn't have some functionality related to Strings and it definitely doesnt have some posix support. If your native libraries are using any of the deprecated functionality you will have to find workaround for those by using alternative functionality supported by libc and coding your libs accordingly.
Also, as you righty pointed out you will have to use the NDK to interface Java(Android app/fwk) to native world(C++).
Though this sounds pretty simple in my experience compiling native libraries on Android(Android porting) has traditionally been very time consuming with no guarantee of sucesses.