I've been using Eclipse for a while and I'm having trouble understanding what's going on with my first project in IntelliJ. I've read the documentation, and searched other questions, but I still can't seem to grasp it. I think there is something wrong with my project structure. This is what my structure currently looks like;
I'm trying to run the JavaForLoop class, but whenever I do, compilation fails because I have errors in the StringMethods class of the strings package. My question is why would that prevent compilation if the two classes are in separate packages? Neither class uses the other, and they both have the appropriate package declaration statements. With a similar structure in Eclipse, this would work. Should I be using a different project structure?
By default IDEA adds Build Configuration which is executed before launch and includes following steps (taken from here):
Compiling source code in the source path of a module and placing results to the output path.
Compiling source code in the test path of a module and placing results to the test output path.
Creating copies of the resource files in the output path.
Reporting problems in the Messages tool window.
check if it's your case in Edit Configuration screen and if so, remove it.
To use a class from a different package you must declare a import statement to the class.
In your JavaForLoop.java add the import before the class statement (and after package declaration where its the case)
//package ...
import strings.StringMethods;
//public class JavaForLoop { and the rest of the code
Intellij uses regular javac, which will fail to compile if you have errors anywhere in the code.
Eclipse has it's own compiler, that allows to compile and even run code that has compilation errors, causing a runtime exception if any part of the code that has errors is run. This allows you to run parts of the code that work even if other pieces of code are failing.
The simple solution is to resolve your compilation errors. You can also use the eclipse compiler with Intellij, but I've never done this so I can't comment on how well it works.
Related
I'm a n00b coder. I found an interesting library and trying to start toying with it. Which is not going great. This library is from 99' and uses JUnit (which I'm unfamiliar with) so there is a lot of confusing stuff. But it seems like the source of my failing even more elementary. Namely I have troubles importing packages.
This library has a test called StandardEvalTest.java. I moved to it to main Java directory and now I'm trying and failing to launch it using JUnit.
This package path org.pokersource.game.Deck goes directly from the directory where the test StandardEvalTest.java sits.
I also added the main java directory to the PATH environmental variable. Which as I assumed will allow import to locate the package.
None of those two things help. Also I was suspecting that maybe Deck.java and Deck.class are not enough and I have to do some work to create a package from it. But as far as I can say from Oracle doc the only thing needed is a package name in the header. Which seems to be present.
So I'm out of moves. Please help!
PS: Some additional info inspired by #Dhrubo 's answer:
The test I'm trying to run indeed sits in the main java folder of the library. (I moved it here hoping that when running from here it would be easier to find the package)
If I'm trying to compile the test instead of running it with JUnit he seem to fail to find JUnit classes and other JUnit related stuff.
[Oh OK I'm an idiot! Dont't mind me]
You should include the package while running StandardEvalTest.java as below
javac -cp [classpath] org.pokersource.game.StandardEvalTest.java
and run it from package root directory, I am assuming it is custom java file that you want to compile. You run directory should be parent of your package directory.
** I also see, you are trying to compile StandardEvalTest.java instead of Deck.java ... then check your StandardEvalTest.java file whether it exists in desired location.
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 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 have a class which extends OrmliteSqliteOpenHelper in order to provide a persistence module for an Android application. The problem is, whenever I access this class from the test project in Eclipse, it throws a NoClassDefFound Exception. The source code appears to be fine as the package is imported and Eclipse has no highlighting to indicate anything will go wrong, but it does.
Here's the kicker: not only does everything else in the project work fine when accessed from the test project, but when I move this file into the test project voila it works perfectly! The issue is that it needs to be in the actual project in order for other components to make calls to it. Has anyone ever encountered this error or have any idea where I might be going wrong?
The class path is set correctly as all the other classes work and the test project always has the main project added to its class path. I also tried moving the OrmliteSqliteOpenHelper object to an inner class: this allowed the outer class to be visible and touched but as soon as it tried to instantiate the inner class the same error occurs. Also, if I copy this file into both projects in the same package, an error occurs stating "class ref in pre-verified class resolved to unexpected implementation" whenever something in the main project tries to access this class. Clearly, there is some difference in the way the class is being compiled/handled between the two projects.
I'm quite stumped :/ Thanks a ton for any assistance!
Well friends, I seem to have hacked together a solution for this issue:
I linked the entire 'src' folder from the main project into the one for the test project. Now, when it goes searching for the particular package my file is located in, it finds the file in its own source tree first. Hooray!
Why does this work? I haven't a clue, perhaps someone could enlighten us to that fact.
Does it work? For now...
There is how I fix the problem:
Remove OrmLite from Build Path of the test project.
Export them from the main project.
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