i am currently working on a Maven project with alot external Libraries. Now i have following Issue...
Issue: I have two different Libraries(lets say Library A & Library B) and both have a class(lets name the class abc.class) with the same classname but the classes dont have the same Implementation! Now one of my testclasses uses abc.class from Library A, which is the wrong class/library. This testclass should use abc.class from Library B. I cant just delete the Library A because i needed also for other testclasses.
My SetUp:
Maven: apache-maven-3.6.1
Java: jdk11
IDE: IntelliJ
My Question: Is there a way to pin diffrent Libraries for specific classes? So i could pin the Library B to my failing testclass, so it can use the right Library and the right implementation for the abc.class.
In the best case, i would like to fix it in the POM :)
Pls let me know if its somehow possible.
No.
You need to have compatible versions of the class.
Or even better only include one type of Class to your build.
Related
I'm using gson.toJson(a) where a is an object from class A importing class B.
The result is: NoClassDefFoundError : B
Should I import the package (with maven) containing B in a different way?
Does gson need sources to perform toJson?
Can you give more details? Are you running it in the editor, or exporting it as an archive and running it that way?
Most likely you need to re-import your maven sources, however, it seems like GSON has nothing to do with the fact that Java was unable to find class B. I checked your application of toJson and that seems fine.
Please make sure that class B is properly added to your imports, and the library was actually linked to your build path properly.
Feel free to share more code and I can try to give you a better answer.
I'm fairly new to Gradle so excuse my ignorance: I have a class that has a static string containing the build version I want to set for the project. With gradle, I can't seem to access the project directly with just MyClass.MyVersionString.
What would be the easiest way to go about it? I can't seem to find a simple way of doing this.
Alternatively, if there was a way to access the Gradle version from my project, that too would help. The project needs access to the version, so I'd like a way to set it in one place and have everything else automagically update.
Thanks!
If building an Android project, you can do it the other way: use BuildConfig.VERSION_NAME (or BuildConfig.VERSION_CODE), depending on what you need.
The BuildConfig class is automatically generated from the information in the AndroidManifest (and some other places, such as the flavor you're building).
I have two projects in my NetBeans window
MyProject
Tester.java
Utilities
Utils.java
The Utils.java file contains a number of static methods written by others that we can re-use. Recently I added a new set of static methods to Utils.java that uses new external jar's. I added the libraries to the Utilities project via Properties --> Libraries --> Add Library
I then proceeded to call these methods from within Tester.java but received java.lang.NoClassDefFoundError exceptions for the classes that were defined in those external libraries. This does not occur when I call the methods from within the Utilities project.
I solved the problem by adding the required libraries to the MyProject project as well, but is there a reason why I have to do this?
You need to have the external libraries in your MyProject as well because it is transitively dependent on those libraries. You are getting java.lang.NoClassDefFoundError because the required classes were available for the Utilities during the compile time to build the jar but those classes are missing at the runtime.
The reason is simple: Utils.class relies on the classes from the library to work. So if you don't have the classes of the library in the classpath, Utils.class can't work. Just like just having an accelerator is not sufficient to make a car move. Without the car engine, the accelerator can't work. The fact that you, as a driver, don't mess with the engine directly, but only through the accelerator, doesn't mean the engine is not necessary. (sorry for this car analogy, but hopefully it makes things clearer).
I have a Java project in eclipse - within the project I want to configure two source directories:
src-api
src-core
This is simple.
The problem is that I want src-core to be able to access src-api, but I don't want src-api to access src-core, I want eclipse to not let me compile and be able to find classes configured in src-core only from the src-api.
Is it possible to do so?
I would very much appreciate your help.
No, it is not possible.
Just create two different project api & core. Then make core project dependent to api project.
I would use two different projects, one for src-api and one for .
The src-core should have src-api as a dependency, but not vice versa.
Suppose I have have a java project myProject and am using an external library jar (someJar.jar), which has a class com.somepackage.Class1.class.
Now I find an updated version of Class1.java which fixes a bug in the original jar.
I include the new Class1.java in my source code under package com.somepackage
When I build the project (e.g., using Netbeans), there is a dist\myProject.jar which contains the classcom.somepackage.Class1.class and a dist\lib\someJar.jar which also contains a class with the same name.
When I run the file (e.g, using java -jar dist\myProject.jar), the new version of Class1.class is used (as I want).
How does Java decide which class file to run in case of such duplicates? Is there any way I can specify precedence ?
Is there any 'right' way to avoid such clashes?
In Proguard, when I try to compress my code, I get a duplicate class error. How do I eliminate this?
Java decides which one to use based on the order of the classpath. List yours first and you'll be fine.
The "right" way would be to fix the orignal source, but sometimes that's not always an option.
I haven't used ProGuard, but I have re-jarred libaries before that had duplicate classes. The solution in my case was to tell Ant to ignore duplicate classes. I would assume ProGuard would have that support too.
Can you not create an updated jar file which contains the bug fix? It's going to make things a lot simpler if you don't have two versions of the same fully-qualified class around.
1) Updated Jar is a better solution.
2) Use a different class name. Is there a reason, why you want to use the same class name and same packing? I don't think there is a reason.
3) create a wrapper/ proxy class, that encapsulate all the calls to the jar and you can decide to call this new class that fixes the bug ( provided it has a different name and packaging)