I want to debug a static inner class, which is actually a Callable. Whenever I try to set a conditional breakpoint in Eclipse I get the breakpoint error:
The type com.sun.source.tree.Tree$Kind cannot be resolved. It is
indirectly referenced from required .class files.
What is causing this error? Is it a bug in the class/package that uses com.sun.source.tree.Tree$Kind but does not provide it? How do I find out which class it is? How do I resolve it?
An example expression which should be correct is: return mRtx.getNode().getNodeKey() == 74;
I have changed it to mRtx.getNode().getNodeKey() == 74 but still the same error. Recently I've found the bug and simply used:
if (mRtx.getNode().getNodeKey() == 74) {
System.out.println("bla");
}
and set a "normal" breakpoint on the "sysout" statement just in case someone has the same problem.
I am not sure on how I would reproduce it as your description is not exactly telling much.
The com.sun.source.tree package is included in tools.jar, which is part of JDK but not of JRE, so make sure you run your Eclipse in JDK (JAVA_HOME variable?), maybe try setting projects JRE to a JDK folder.
I also think that the Compiler API was introduced in Java 6, so check if you are not using a lower version.
Maybe you should try to edit the debugger's source lookup.
To do this, go to debug perspective, in the debug view (where the stack is normally shown) right click on the terminated run, and choose 'Edit Source Lookup...'.
Then you can add a lookup place. In this case you should maybe add the tools.jar that is in the jre folder.
The compiler can't find the type, that is the root issue, but in my thinking, this should only be a compile time error, but by implication from what I read, it's a run time error. Is that correct?
Here is are some tips:
http://java.syntaxerrors.info/index.php?title=Cannot_resolve_type
Indirectly referenced from required .class file
Maybe you could post more code or use "control + T" in Eclipse on the class to look at the type hierarchy, I would like to know what other classes are referenced.
HTH,
James
Related
I am trying to compile a java file, which uses package com.sun.xml.internal.messaging.saaj.soap.dynamic, using ANT-1.9.3 but I'm receiving error
package com.sun.xml.internal.messaging.saaj.soap.dynamic does not
exist
I tried compiling both JDK7 and JDK 8 and getting the same error.
I can see the package exist inside rt.jar of both JDK. I have set JAVA_HOME also properly.
Can someone help me to resolve this issue?
Unfortunately for you, this behaviour is probably intentional and your usage is deliberately unsupported. If your code used to compile under Java6 and now doesn't under Java7 or Java8 then you've basically fallen foul of
From one release to another, these classes may be removed, or they may be moved from one package to another
http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
See also http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6778491 for a technical description of a possible cause of not being able to compile a class which references a 'com.sun.*' class but which throws the same compiler error you're seeing despite the fact that the referenced class exists in rt.jar. Also for the kind of response which Oracle give to bug reports relating to it;)
Unfortunately, using undocumented, unsupported APIs often has this kind of 'bite you in the posterior' kind of effect.
Please add the line, < compilerarg line="-XDignore.symbol.file" compiler="modern"/ > for < javac > tag in your build.xml. This should solve your problem. It solved for me.
For reference you can view the forum link
http://www.icesoft.org/JForum/posts/list/19871.page#sthash.srrN9Ijk.dpbs
I am unable to run the following code in Eclipse (Eclipse IDE for Java Developers, Version: Indigo Service Release 1, Build id: 20110916-0149), and I think that I may have a configuration problem in Eclipse (but I do not know what or where):
class Saluton {
public static void main(String args[])
{
String greeting = "Saluton mondo!";
System.out.println(greeting);
}
}
I am also running against Java 6 (1.6.0_29-b11-402) on Macintosh 10.7.2.
When I run this, I get the error:
"java selection does not contain a main type"
but I am pretty sure that my class is written correctly...? I have looked this error up, and cannot explain this problem so far.
TIA for any thoughts or opinions!
I think you have to make your class public, otherwise it won't work?
EDIT: My previous answer was incorrect. The JLS says you can declare arrays with the brackets at either end. See here for some examples. My mistake.
Have you verified your configuration in Eclipse such that it knows where to find the Java compiler, and a JVM? You can check the project-specific libraries by right clicking the project and going to Properties, Java Build Path
You can also check the JRE's installed by clicking Window, Preferences, Java, Installed JREs. Make sure the JRE you wish to use is listed here and that the path is correct.
Another solution (simple and direct):
In Eclipse: File -> Restart
Right click your class Saluton and choose Run as --> Java Application.
It should work.
Ok, so I'm a fellow noob, and I came here because I had this problem. I checked all my class paths and everything, and they were correct. I had actually been putting all of my files in the JRE System Library Folder, instead of the source folder. I'm not sure if this was you'r problem, but it seemed to work for me when I moved the code files into the src folder.
I took the long way around to solve this; eventually I created a package within my project and added my source code to that package and it compiled and ran! I am learning that Wizards rule!
It will work if you make your class as public !
I get the following IDE error which appears inline or on the package declaration of my classes, but doesn't prevent the code running or working as expected.
I tried manually downloading the javax-annotations.jar from Glassfish and placing that in both the classpath and also on the JDK external JAR resources areas, no help.
The type javax.annotation.meta.When cannot be resolved. It is indirectly referenced from required .class file.
The error appears anywhere that I use the Findbugs #NonNull annotations; any class which uses this annotation has the above message appear in the IDE on the package declaration line. The class however appears as error-free from the Package-Explorer or Navigator view.
I would quite happily ignore this, however it breaks the Mark-All-Occurences behaviour which I quite like, if anyone has any ideas on what I might have missed I would appreciate it!
The FindBugs jar already contains a jsr-305.jar, which contains an implementation of JSR-305.
More info in this previous question.
Edit Oh, you already did that--I didn't even know it was in annotations.jar as well.
I'm getting:
NoSuchMethodError: com.foo.SomeService.doSmth()Z
Am I understanding correctly that this 'Z' means that return type of doSmth() method is boolean? If true, then that kind of method really does not exist because this method returns some Collection. But on the other hand if I call this method, I'm not assigning its return value to any variable. I just call this method like this:
service.doSmth();
Any ideas why this error occurs? All necessary JAR files exist and all other methods from this class seems to exist.
Looks like method exists in classpath during compilation, but not during running of your application.
I don't think return type is a problem. If it was, it wouldn't compile. Compiler throws error when method call is ambiguous, and it is when two methods differ only by return type.
Normally, this error is caught by the compiler; this error can only occur at run time if the definition of a class has incompatibly changed.
In short - a class/jar file at runtime is not the same that you used at compile time.
This is probably a difference between your compile-time classpath and you run-time classpath.
Here is what seems to be going on:
The code is compiled with a class path that defines the doSmth() method returning a boolean. The byte-code refers to the doSmth()Z method.
At runtime, the doSmth()Z method isn't found. A method returning a Collection is found instead.
To correct this problem, check your (compile time) classpath.
The current reply just tell you why is failing. Usually is even nicer to know how to fix problems. As it is mentioned, the problem usually is that you built your program but when running or exporting it, the library is not included. So the solution is...
If you are running, check the the run configuration
Select Run tab -> Run configurations -> Select the configuration you are running -> Check the Classpath tab -> Ensure the libraries you need are there
If you are exporting (for example a war file), follow this
Select project -> Select properties -> Select Deployment Assembly -> Press Add -> Select Java Build Path Entries -> Select the libraries you want to be included in your exported file (for example a war file)
In both cases, ensure the library which you are referencing in included.
Other frequent problems for this error are not the right type of parameters or visibility but then, the compiler will detect the error before running. In this case, just check the documentation to match the function and package visibility, and ensure that the library is found in Java Build Path in your project properties.
Maybe still can help somebody, but this exception can happen also when you have on the classpath two classes in different jar files that have the same exact signature but they haven't the same public methods.
For example:
On file mylibrary1.jar you have class com.mypackage.mysubpackage.MyClass with method doSmth()
On file mylibrary2.jar you have class com.mypackage.mysubpackage.MyClass without method doSmth()
When searching the class, the classloader may find first mylibrary2.jar depending on the path precedence but can't find the method on that class.
Be sure you don't have the same package + class on two different files.
I noticed this problem occurring while testing some experimental changes in multiple linked projects, after updating them from SVN in Eclipse.
Specifically, I updated all projects from SVN, and reverted the .classpath file rather than edit it manually to keep things simple.
Then I re-added the linked projects to the path, but forgot to remove the related jars. This was how the problem occurred for me.
So apparently the run time used the jar file while the compiler used the project files.
Another way this can happen and is difficult to find:
If a signature of a method in an external jar changes in a way that there is no error found in the IDE because it's still compatible with how you call it the class might not be re-compiled.
If your build checks the files for changes and only then recompiles them, the class might not be recompiled during the build process.
So when you run it this might lead to that problem. Although you have the new jar, your own code expects still the old one but does never complain.
To make it harder it depends on the jvm if it can handle such cases. So in the worst case it runs on the test server but not on the live machine.
We have a package that ends with exception e.g.
package a.b.c.exception;
Our code base had no issues up till eclipse 3.3, however when we shifted to eclipse 3.4, it started giving errors related to this package:
"The package a.b.c.exception collides with a type"
When I refactor the package name to a.b.c.exceptions, there are no issues. Is this due to a bug in eclipse 3.4 or is there some setting to rectify this behavior?
It's because you have a class named exception (with a lower case "e") in the a.b.c package and a package named a.b.c.exception.
It causes a name collision because if you have the code a.b.c.exception.doSomething(); - does that mean you want to call the static doSomething() method in the a.b.c.exception class? Or does it mean there's a class called a.b.c.exception.doSomething that you're trying to invoke the constructor of?
Stick with the Java naming conventions - packages all lowercase, classes starting with an uppercase and camel-case after - and you'll never see this problem.
==========EDIT==========
This is the only legitimate reason this error should be showing up...
It doesn't have to be in your project directly, it could be in another project or library that your project depends on. This should show you any occurrences of the class anywhere on the build path or your project : Hit the Flashlight looking button in the Eclipse toolbar -> Choose 'Java Search' -> enter a.b.c.exception in search field -> select 'Case sensitive' -> select 'Type' in 'Search For' -> make sure all options are selected for 'Search In'.
Are you using any tools that generate classes? Could they be putting them into the build directory of your project? When you see the error, if you go to the project's build directory, and go down into the a/b/c/ directory do you see a .class file for 'exception'?
Of course Eclipse in general could have a bug (though I'd expect there would be a bug report in Eclipse 3.4 and you'd be able to find more complaints if it was...), your Eclipse install could be broken in some way (Can anyone else open your project in Eclipse 3.4? Could you do a clean Eclipse 3.4 install in another directory? Does the error appear there?), or your project could be messed up in some way (Create a new project with no dependencies other than the JDK, create the a.b.c.exception package in your new project, create a class in your project to import a.b.c.exception.*; and see if the error occurs.).
In Java you can not have a class name that is the same as a package name.
That means the JDT package must have enforced that rule only in 3.4
See bug 63668 for instance.
As Nate comments:
A class named Exception won't prevent you from creating package exception.
Case matters.
Also remember the full name of a class includes the package it's in.
So a.b.SomeClass (class name) is different from x.y.SomeClass (package name).
There would be no name collision here.
The class name and the package name have to match in both case and package to cause this error.
See his more accurate answer.
I encountered a similar problem in a huge code base that I inherited. It turns out that the clash was caused by an partially qualified class name in a JavaDoc link.
To paraphrase, Eclipse was telling me that I had a package/type clash for a.b.c.d. when compiling a.b.c.d.London. Doing a java search on the code for a.b.c.d revealed that Eclipse thought that a JavaDoc comment in a.b.c.Paris was a match. The JavaDoc comment contained {# link d.NewYork}. When I changed the it to read {#link a.b.c.d.NewYork} the compilation error was resolved.
It should also be noted that NewYork was not imported into the Paris class as it only appeared in the JavaDoc comment. This also made it un-resolved in its abbreviated form and clicking on the link in the comment did not work. Making it an absolute reference also makes the JavaDoc link work.
I know this will sound silly, and possibly too simple to be true, but I solved this exact same error message by:
Deleting the entire line of the package name causing the error message.
Saving the .java file(this triggers a new error on the same line stating "The declared package "" does not match the expected package"), which it should do.
Re-typing the original package name onto the same line.
Saving the .java file.
Could not tell you why this worked, but it did, and Eclipse stopped throwing a tantrum on the spot.
Safe typing and speedy coding.
-Goodge
I changed one of the compilation option in eclipse and the problem disappeared.
Under workspace properties:
Java Compiler -> Errors/Warnings ->
Change 'Unused import' from 'Warning' to 'Ignore'.
If you have a class Foo, you cannot have a package that ends with Foo, such as com.my.Foo.
Also if you are using maven style, you have resources in your project under something like src/main/resources
The folders in your resources also have a package style and there, also, you cannot have a folder that contains the name of your class.
you will definitely encounter this problem when developing a Jenkins plugin according to the recommended conventions.
if you follow the Jenkins conventions, and you create a builder in a class named MyBuilder in package x.y then you are also supposed to place your .jelly in a resource folder named x.y.MyBuilder. This will result in the above problem.
However, if you name your resource folder x.y.myBuilder (notice lower case 'm' in myBuilder), unlike the recommended convention, the plugin will still work as you intended