So, I've got this problem - a strange problem. I have a library as part of an IDEA project - in which all the code is publicly visible under 'tk.*' (IE: all classes exist in sub-packages of tk). Should the attempt be made to import a class residing within that package IDEA highlights the import statement (only th 'tk' mind you - which is strange enough), citing the reason mentioned later. Despite the apparent "errors", the project (consisting of a formidable number of files) compiles successfuly - very much so, infact.
Info:
The highlight reason (when you hover over the aforementioned highlight): 'tk' is not public in ''
Note about this: the file importing from said package IS NOT in the default package.
It would seem that the importing from packages residing in other libraries is not found at fault by IDEA
The class(es) imported by aforementioned file(s) are not package-private, nor protected, nor private - they are public
The project's path settings should be correct, however I am open to the suggestion that these may be at fault
Notes:
Sorry if this quiestion reads wierdly - I'm rather distracted by the environment in which I currently reside.
Related
I have received the task, at work, to find a way to use some methods from an existent jar file in a Python project. I have very limited experience in Python, but I have worked with that specific jar file before (it is part of a project we are working on). I am not allowed to modify much of both projects, and they are required to be as independent as possible.
I have researched multiple ways to include the jar methods in Python. So far, I have tried Jython (which I cannot use because the Python project uses PyQt among other libraries, which force the use of CPython, if my understanding is correct), Pyjnius and JPype. JPype seems the most promising, but I cannot get it working either. I have pasted the my code below, slightly censored because I don't know how much I am allowed to share.
from jpype import *
import jpype.imports
try:
jpype.addClassPath("jars/sdk.jar") #the relative path to the jar file
jpype.startJVM(convertStrings=False)
java.lang.System.out.println(jpype.getClassPath()) #printing the classpath to check, the path is correctly pointing to the sdk.jar file
java.lang.System.out.println("Hello world") #just to check if jpype is installed correctly, works
jpype.imports.registerDomain("a")
from a.b.c.d.e.f.g.h import SomeClass #fails here
except OSError as err:
print(err) # ToDo: Remove print when done
pass
The error I am getting is that the module a.b.c.d.e.f.g.h.SomeClass could not be found. I have tried different ways to give the path (absolute path, relative path, place the jar in different places in the project and outside of it), but that doesn't seem to be the problem, as the path printed is the correct absolute path to the jar file.
Also, the jar is used in other (Java) projects and it works. It is created using maven package (using IntelliJ, if it is relevant, and the same Java version as the one used by the JPype JVM). In the Java projects, the import would be:
import a.b.c.d.e.f.g.h.SomeClass;
I have copied this and just transformed the syntax into Python.
I have also tried to create the class with JObject (which I probably didn't do right anyway) and also tried the older syntax (to my understanding) with JPackage. For the JPackage way, I am getting the exception that the package a.b.c.d.e.f.g.h.SomeClass.someMethod is not Callable, which to my understanding is an equivalent exception to the one I'm getting using jpype imports. I have already gone through all the questions I could find here with similar problems, but none of those solutions have helped me.
Can anyone suggest some possible solution? Or can anyone see what I'm doing wrong? Suggestions of other possibilities to replace JPype are also welcomed. If there is any clarification needed, I will edit the question.
The only thing that seems likely if the jar is on the classpath and failed to import would be for there to be some missing dependency. You have two other ways to try loading the class which may provide additional diagnostics.
jpype.JClass("a.b.c.d.e.f.g.h.SomeClass")
and
jpype.JClass("java.lang.Class").forName("a.b.c.d.e.f.g.h.SomeClass")
The first is manually loading a class by full class specification. It is mechanically what is happening under the import. The second is calling for Java to load the class (bypassing all of JPype). It returns a java.lang.Class which can be passed to JClass to make a wrapper.
Common failures include missing a jar or native library, attempting to start JPype from within a module and having the wrong relative path, error in initialization of the class due to missing resource. JPype is just calling JNI calls, so if everything is fine on Java end it should work. Given that you checked the java.class.path System variable, it has to be something to do with class resources.
The JPype user manual has an alternatives section if you would like to try to find another package. Most of the alternatives with the exception of PyJnius appear to be unmaintained.
I'm trying to develop an email parser - to take email that's in a file and be able to programmatically handle the various components - to know who the sender and recipient were, the subject line, main body, and any attachments. I intend to extract attachments as individual files, but I'm stumped right at the beginning.
I started with an already working java program in a fully-functional development environment and have begun adding to it. One of the first additions was this line (then later, set of lines):
import javax.mail.*;
import javax.mail.internet;
import javax.mail.internet.MimeUtility;
Later, in an appropriate place, we have this humble beginning:
MimeMessage m = null;
I was shocked to find that the compile failed with only these two changes, and I learned here (on another StackOverflow page) that the package javax.mail package isn't included in the standard JDK. Puzzled, I looked and found this:
# rpm -qa | grep -i java
android-json-org-java-4.3-0.2.r3.1.fc21.noarch
snappy-java-1.0.5-2.fc21.noarch
tzdata-java-2015b-1.fc21.noarch
python-javapackages-4.1.0-7.fc21.noarch
postgresql94-jdbc-javadoc-9.3.1101-1.f21.noarch
protobuf-java-2.5.0-11.fc21.x86_64
java-1.8.0-openjdk-1.8.0.40-25.b25.fc21.x86_64
java-1.8.0-openjdk-headless-1.8.0.40-25.b25.fc21.x86_64
javassist-3.18.1-2.fc21.noarch
apache-commons-javaflow-1.0-0.8.20120509SNAPSHOT.fc21.noarch
javapackages-tools-4.1.0-7.fc21.noarch
java-1.8.0-openjdk-devel-1.8.0.40-25.b25.fc21.x86_64
antlr3-java-3.5.2-2.fc21.noarch
javamail-1.5.1-3.fc21.noarch
xz-java-1.5-3.fc21.noarch
abrt-java-connector-1.1.0-2.fc21.x86_64
Please note that yes, actually, JavaMail is installed - version 1.5.1-3. However, just to be a belts and suspenders kinda person, I found the JavaMail project and downloaded the latest production version, and put it in the CLASSPATH.
To my great surprise, this did not cure the problem! Being the careful type, and keeping things simple to prove the way as I go, I simply removed the javax.mail.jar file from the library directory, then removed the two lines from my program, recompiled and it worked. Then, I added back in the import line, and it failed. Then I moved the jar file back into the library directory and the compile succeeded, confirming that the javax.mail package was being loaded.
However, when I added in the first reference to the library, MimeMessage (see the line above), the compile failed.
So, of course, I went to check the documentation! Indeed, MimeMessage is an available class.
What am I doing wrong?! I mean, geez, I've been using Java literally since version 1.0 - I'm not known for making too many dumb mistakes, but I figure I must be!
Two open questions come to my mind:
1) Why isn't the installed version of the JavaMail package being used? CLEARLY I had to add it. And do note that I don't have to do ANYTHING special to CLASSPATH (or anywhere else) to get all the rest of Java! And;
2) Now that I've got a JavaMail package in there, why is it not discovering the MimeMessage class?
Any / all help appreciated - and if you spot me being abjectly stupid, please point out my error gently!
Additional Information:
I added two more import lines, so there are now the three listed above. Curiously, when I have the .jar file in the path specified by CLASSPATH, but not explicitly cited, I get one error per import, but when I explicitly cite the .jar file as an explicit item, I only get ONE error! That one error is on:
import javax.mail.internet;
Naturally, knowing that the jar is actually just a zip, I unzipped and looked. Sure enough, a directory named "internet" is there, populated with 38 class files.
Somewhere along the way, I had a wild idea that somehow there was ANOTHER javax.mail entry on the system or in the CLASSPATH, so I looked. This is Fedora Core, so it's under /usr/lib, and I did NOT find another file including the string "mail" in its name, so I presume that's not it, either.
I noticed in the NOTES.txt file that there were some notes about not unpacking the jar for some applications because that was seen as a security risk, but I figured that for what I want to do there is no such risk and maybe it would work, but I couldn't get THAT to work either...
I've also been trying using -cp versus actually altering the CLASSPATH variable, but it doesn't seem to matter. I apparently get identical results either way, so I've just been using -cp for testing because it's faster to try various alternatives.
MimeMessage is in the javax.mail.internet package, which you haven't imported.
EDITED BY QUESTION ASKER:
Actually, I was trying to import, among other things:
import javax.mail.internet;
And that didn't work. What I was missing was that there's nothing to import on just javax.mail.internet. Changing it to:
import javax.mail.internet.*;
worked just fine!
So, while Bill wasn't quite correct, this answer plus his comment got me to see what I was blind to... and I feel silly!
I am trying to emulate some java.lang and java.io classes, e.g. OutputStream within GWT.
I have created a "super" package in my module and referenced it using super-source.
My package structure looks like
com/example/gwt/client
com/example/gwt/server
com/example/gwt/shared
com/example/gwt/super
com/example/gwt/super/java/io/OutputStream.java
com/example/gwt/mymodule.get.xml
and mymodule.xml contains an entry
<super-source path="super" />
Within Eclipse all of the files within the super folder are in error - to be expected because the package structure is wrong. .class files are being generated in the WEB-INF/classes folder, again with the "wrong" package structure so should be ignored.
When I run my application in development mode I get lots of
unable to resolve class java/lang/Object
errors. What am I doing wrong?
Rename ....get.xml to ....gwt.xml?
You can exclude "super" from the eclipse build path.
Try right-clicking or the build path menu exclusion options..
There was nothing wrong with the approach - just the execution.
I had compile errors in the emulated classes which were being masked by the fact that Eclipse was showing errors because of the "incorrect" package structure. Running the compiler from within Eclipse flushed these out.
It also seems that deleting the gwt-unitCache might have helped. As I was moving code around it seems that there were stale entries in here that were still being referenced.
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.
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