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.
Related
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.
If we use JDK8 or below, there is a class called java.uti.SubList defined in rt.jar.
The following code works fine in JDK8 or below:
Class c = Class.forName("java.util.SubList");
Now that I have migrated to JDK9 and higher versions, I am unable to execute the same code. Its throwing ClassNotFoundException. Anyone aware of the fix for this? I tried adding java.se module but of no use.
I tried adding various modules of JDK9 but invain.
Class c = Class.forName("java.util.SubList");
I want that code to run successfully in JDK9+.
The reason for asking this question is:
The reason I have asked this question is, I am using kryo-serializers library (https://github.com/magro/kryo-serializers) in my java project.
Those guys have used this "java.util.SubList" class. https://github.com/magro/kryo-serializers/blob/master/src/main/java/de/javakaffee/kryoserializers/SubListSerializers.java#L267 This project is breaking in JDK9. I have asked them to look into it but no response. https://github.com/magro/kryo-serializers/issues/112
I wanted to clone the project and fix the issue myself by finding equivalent of java.util.SubList in JDK9. Thats where I need help.
As #Thilo said in a comment, the class is a private class of the package, it is not part of the interface and therefore should not be used by external user.
That's the reason why you should not produce code that rely on it, because it could be deleted by the package without any notice ( as it seems has happened in JDK9 ).
You should just use the public LinkedList, ArrayList or similar.
You could try something like that:
Class c = Class.forName("java.util.List");
And then use the c.subList();
I have a Java class that i would like to import into my Jython script. Unfortunately, eclipse won't let me create a Java class inside my Jython project.In the window, where you create and name your Java class, I get a message at the top (alongside a red cross) saying, "Source folder is not a Java project" when I type the name of the would be class. How do I rectify this? I need the Java Class to call C code using the JNI (declaring the native method,loading and then calling it). Thank You !!!!!!!
What you can do is to create second module which would be java project. Anyhow, logically it should be that way. Please check out other similar question - PyDev: Jython modules & Java classes in the same project.
Other links that might help - http://pydev.org/manual_101_project_conf2.html
So what nefo_x suggested is correct. You need to create a new Java project that will contain your Java class. Then import the Java package as you would a python module. But there are a few things to watch out for in eclipse to make it work. I list the whole process below:
Your Java class (or classes) should not be in the default package. You need to create a new package and make/put your java class files there.
Export the package as a jar file to some place on your computer.
Add the jar file (located at some place on your computer) to your python path.
Import the package by writing "import PackageName".
The problem for me was that I had my java class in the default package. That does not work due to some naming issues. Anyhow, hope that this helps.
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)
I am using a 3rd party annotation processor for generating meta-data code (.java files) from the annotated classes in my project.
I have successfully configured the processor through Eclipse (Properties -> Java Compiler -> Annotation Processing) and the code generation works fine (code is automatically created and generated). Also, Eclipse successfully auto-completes the generated classes and their fields, without any errors. Let's say that I have a class "some.package.Foo" and that the generated meta-data class is "some.package.Foo_". By the help of auto-completion, I can get the following code in the Eclipse editor, without any errors:
import some.package.Foo_;
...
public class Test {
void test() {
Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
However, as soon as I actually build the project (or just save the file since Build automatically is enabled), I get the error which tells that "some.package.Foo_" cannot be resolved.
It seems like Eclipse is generating and compiling the some.package.Foo_ at the same time, or more likely.
I found two temporary solutions (which are practically hindering the use of the annotation processor in the first place):
Before each build of that generated classes, right click on every generated file go to Properties and uncheck the "Derived" tick. After that, I do the cleanup of the project and the imports are fine - there are no more errors. However, if I do the cleanup one more time, the errors again show up, because the generation of the files causes the "Derived" tick to be checked again (automatically). So this is really annoying and time-consuming.
I also uncheck the "Derived" tick
from all those files, and this time
I uncheck the "Derived" tick from
the source folder and packages which
contain those files. Then I disable
the annotation processor, and then
do the cleanup. There are no more
import errors, even if I do another
cleanup, but there is no benefit of
using the annotation processor,
because if I was to change something
which would update the model, I need
to turn the annotation processor
back on, and repeat this tedious
procedure to turn it off, after it
has generated the new version of
those files.
Is this a bug in Eclipse? If yes, is there a better workaround or quick-fix than the two I have stated above? If not, what should I try to solve the problem?
I also tried rearranging the order of the libraries on the build path and it doesn't help.
I assume that you are generating sources in the last processor round. This is not recommended way and leads exactly to the problem that you had.
Explanation is here: http://code.google.com/p/acris/wiki/CodeGenerationPlatform_Pitfall_Rounds
So the my advise is to generate sources in regular processing rounds and final round should be used just for notification that processing is over or something like that.
Hopefully this helps you.
I have a similar problem, and the only thing I've found is that it's the imports specifically that don't work, but the references in the class itself do work. The workaround I've used is to use the FQCN in all cases where the generated class is needed (except when the generated class is in the same package, since then the import is obviously not needed).
So to use your example, I'd do:
public class Test {
void test() {
some.package.Foo_.someField = null; // try to access a field from the generated class Foo_
}
}
My only guess then is that the eclipse compiler is processing the imports before doing the annotation processing, which imho must be a bug in eclipse.
I know this question is over a year old, so I'd be interested to know if you've found any other way to fix it.
We were experiencing a similar problem and apparently just solved it, so thought of sharing it at SO, in case it helps someone.
We are using:
Eclipse Indigo (Build id: 20120216-1857)
m2e Connector for maven
openJPA for static metamodel class generation
Our problem:
Say, we have a package named com.abc.xyz and an entity class in there named OurEntity. When we build the projects (JPA, EJB, EAR etc. all together with an mvn clean at the beginning) the metamodel classes get generated. And also get appropriately packaged within the PU jar. But when we try to import the generated metamodel class com.abc.xyz.OurEntity_, Eclipse cannot resolve it. OP apparently got past this point:-). Maven build failed, saying it could not resolve that class. Not much help from google except for a few bug reports such as this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=350378
That bug report said importing the whole package as opposed to the single class helped. So, tried that, but with no benefit. It also said (and so did David Heitzman) that using the fully qualified class name worked for them. That did not work either.
The solution:
Added the PU jar to Eclipse build path for the project that needed to use the metamodel classes. All of a sudden all the red underlines went away (not a surprise). But the fear was there might be two PUs in the same ear. But maven automagically took care of that.
As this rather old question got some attention without pointing to the very probable eclipse bug the OP was specifically asking for, I'd like to complement the above answers with a pointer to the eclipse bug tracker:
Cannot resolve import for generated class IF processing annotations with parameters referencing constants
The workarounds include
doing a wildcard import of the package defining the generated classes (i.e. import some.package.*;)
using the fully qualified name of your generated class, i.e. referring to some.package.Foo in your code and not using an import
switch to a newer Eclipse. This specific eclipse bug is resolved with Eclipse version 4.4 (aka Luna).