I'm adding a library to my project (a .aar) by using "Open module settings > new > Import .JAR/.AAR Package".
It builds correctly an the app opens but, when the first class of that library is being instantiated it gives me a "Java.lang.verifyError" with that class.
Reading about it it seems the error happens when the library used to compile is not the same as the one used at runtime. But that seems a little abstract to me, where can a I check if that happens? How should I correct it?
Thanks
Maybe your library modules use two version types of dependencies of same library types. Like, say you're using library A and B. Then A use support design 27 and B use 28. Make it same. Few days ago we faced this error by Java which is totally new to us. We were using library modules and after multiple research we found it and solved using same type of versions. I can't guarantee, it will work to you though.
Related
I've downloaded android-src.jar and added it as a dependency to another project, but the code completion will only show the something like com.google.android.mms.pdu but no suggestions come after that for classes.
I've tried various dependencies, but none of them work. I've also tried tried Invalidate cache/Restart.
When I look through the library and view one of its classes, it's telling me it can't resolve symbols for classes that are clearly there.
These classes belong to Android framework, Platform classes can refer to other package private classes and you could not see its actual compiled class. Only symbols exposed by package designer could be seen.
This happens in a Java and maven project in Eclipse with a kotlin nature.
In this part of the code:
val faces = figure.getFaces()
for (polygon in faces) {
//...
I get the error below in eclipse, where faces, in the second line above, is underlined in red:
Cannot access class 'Polygon'. Check your module classpath for missing or conflicting dependencies
The project is a mix of Java and Kotlin. The figure object is an instance of a Java class, while the faces are a set of type Polygon which is in a different project that is pure Kotlin (ie Polygon is a Kotlin type, in a separate Kotlin project).
This Kotlin project where Polygon is, is indeed in the classpath as a Maven dependency, and in fact used by the Java class of which figure is an instance.
I think the problem is in Eclipse, because I can build the project with maven successfully. It looks like either a bug in eclipse or a configuration issue.
I know it's strange to have a mix of Java and Kotlin. I simply started this project in Java and then decided to convert it to Kotlin gradually. So far I haven't had many issues but I'm aware that Kotlin tools and support in eclipse are not mature yet.
Not much of a proper solution: I converted my Figure class to Kotlin and the problem went away, but I can do that because I have full control on my project.
Possibly newer versions of the eclipse plugin won't generate this error or, as suggested in the comments, switching to IntelliJ IDEA is another option.
I have a java project where I use an external jar (not controlled by me).
Until now whenever that a new version of that library is out, I update
my project to use the more recent one, but now is required that the
project uses different versions of that library.
My problem is I don't have any clue how to do that.
How do I tell in java to make the imports according a version of a jar,
What I need to do:
int versionFlag = getVersion2use();
if(verssionFlag = 0){
use imports from last version
}else if(verssionFlag = 1){
use imports from last version 1
} else if(verssionFlag = 2){
use imports from last version 2
}
This is to be used at runtime!
This is usually something that a project will do at build time rather than dynamically at runtime.
That said, here's a good answer on how to add a jar to the system classloader dynamically at runtime, which is something you could work into your general logic above:
How should I load Jars dynamically at runtime?
With respect to imports, there's no way around the fact that you can't dynamically pick your imports. So if you're lucky the two versions have the same basic API. If that holds, add the jar to classloader as early as possible in your app and then develop like normal.
If the two versions have different a different API, however, then you're going to have to write some very convoluted code that tries building objects and almost ubiquitously catches all the many different class load / class incompatibility exceptions (such as ClassNotFoundException). Worse, you'll probably have to do this behind some sort of facade or factory architecture so that you can actually keep running software insulated from all these class loading shenanigans. In short, if the two have different APIs you may actually be better off writing two separate products.
At Runtime
Classes with the same name in the same package follow a first available rule. The first one that is on the classpath is the one that is used.
You can not easily do what you want at runtime without a wrapper program to move the libraries into and out of the system classpath before the Java application is started.
A launcher script/program that dynamically builds the classpath and only includes the version you need of each library and passes it to java -cp is the only way to do what you want at runtime.
At build time
If it is at build time, then just use something like the shade plugin in Maven to build an uberjar with all the required libraries embedded in a single .jar for each of the versions. So 3 versions would be 3 separate uberjar assemblies.
If you can do it at build time, you can use a dependency manager, like Maven.
It provides you with a means to be able to select which versions of which library you use at build-time.
If you need to do this at runtime, you might need to package all libraries in your project. You can use shading (see here) to make sure you don't get import issues, because when importing different versions of libs you end up with similar imports.
Shading can help you make for example:
com.foo.Class in jarv1
com.foo.Class in jarv2
To become
com.foo.v1.Class in jarv1
com.foo.v2.Class in jarv2
This will make sure your code can still use all libs you want.
I am new to enterprise application developement and trying to create a REST server with Spring REST, JPA taking to mySQL database and Javascript on the client side. As I see loads of opensource libraries doing specific task, I started off with using 'maven project' with different 'arch type' (which is nothing but predefined POM with relevent libraries as I understand) provided by Eclipse. But I often run into version mismatch issues, in many cases found specific solution to that perticular libraries in StackOverflow or other sites.
Hence I started looking for a information these version dependancies such as, this version of JPA works with that version of Hibernate library and so on. I checked maven repository of major libraries, I did not find such information so far.
My queries are:
Where can I find these information about the versions dependancies?
Are these pre defined POM in eclipse reliable? Who owns them, where can I get last modified dates on these maven 'arch types'? (I find the ones I choose having fairly old version of libraries).
If I have to start off on my own creating a Maven dependacies, where will I get information about what are the dependent libraries, for example, if I need spring MVC, for sure it needs java servlet library. I am worried becuase the maven 'spring-mvc-jap' arch type whooping 50 libaries as dependancies.(Coming from embeded domain, I find to too hard to digest :D). So not sure if it is the right way.
Please correct if I am missing anything in my understanding.
You can find this information, if you are using maven and some IDE you can go to the dependancy and make click un > and this will show the librarys used for this dependancy or if you want to use the console you have http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html this will show the same that the IDE.
After normally in the documentation of the library used, you can find some doc about the dependancy about this.
Other solution is get the .jar and use 7zip to see the POM and know the dependancy used.
And for finish my answer if the IDE tell you that you dont have x dependancy normally you have to add this because any of the other dependancy used have it (they used only for the compiling task), but sometime somes projet change a lots of code between the version .a to .b so you will have some problem using the version .b, at this moment i didnt find one good and easy way to fix this, only using the way that i told you (only if i found some problem in the compilation)
3> I am not sure how it works in eclipse but in IntelliJ IDEA when you start using some class without proper dependency IDEA suggest you to add proper dependency automatically. The same approach should be in eclipse.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
NoClassDefFoundError - Eclipse and Android
I'm seeing this question is getting asked a lot in many different contexts. Perhaps we can set some strategies for locating and fixing it? I'm noobish myself so all I can contribute are horror stories and questions, sorry...
It seems this is thrown when a class is visible at compile time but not at run time... how can this happen?
In my case I am developing an app that uses the Google APIs, in Eclipse, for the Android platform. I've configured the Project Properties / Java Build Path / Libraries to include the gdata .jars and all is well. When I execute in the emulator I get a force close and the logcat shows a NoClassDefFoundError on a simple new ContactsService("myApp"); I've also tried a new CalendarService("myApp") with the same results.
Is it possible or desirable to statically bind at compile time to avoid the problem?
How could dynamic binding of an add-on library work in the mobile environment anyway? Either it has to be bound into my .apk or else I need to "install" it? ... hmmm.
Advice much appreciated.
It seems this is thrown when a class
is visible at compile time but not at
run time... how can this happen?
The build classpath may include JARs that are not being packaged into the APK.
Is it possible or desirable to
statically bind at compile time to
avoid the problem?
It is possible, desirable, and necessary.
Outside of Eclipse, you just put the JARs you need in libs/ in your project, compile with Ant, and you are done.
Inside of Eclipse, one pattern I have had students use with success is to put the JARs you need in libs/ in your project, add them as JARs to the build path (note: not external JARs), and they get packaged as part of the APK. Note, though, that I do not personally use Eclipse, and so my experience with it is limited.
For those having problem I was having the same error with my app. what I did to solve that was create a new project and copy my resource and source folders along with my manifest file into the new project (I deleted in advance those within the new project created) and voila.
When I got this, the problem was actually deeper in the queue; Dalvik converter had failed to convert some of the referenced libraries and still Eclipse allowed me to launch the project.
Check the Android SDK console to see if there are any errors reported.
In my case, I'm using my own library (MyLib) shared between 2 apps. App A was closed when I added a new class to the library.
When I opened App A to work on it, Eclipse recognised the new class, and I was able to reference it. However on running I got the error.
It turned out that the imported library folder in App A (named something like MyLib_src) didn't reflect the changes made to my library project (MyLib).
To solve this I refreshed App A, the changes reflected, and Android could build my project correctly.
I have found no reference to this version of the problem, so thought I would add it to this list.