I have a class in package foo, FooImmutableCatUser that wishes to use the Immutable, ImmutableCat object defined in package bar. However, I'm having issues getting FooImmutableCatUser in package foo to recognize ImmutableCat despite properly importing it. The import errors (unused import), and building yields the error: error: cannot find symbol at ImmutableCat.of().
My directory structure in bar looks like:
\bar
\models
\Cat.java
Cat.java is defined as
package bar.models;
import org.immutables.value.Value;
#Value.Immutable
public interface Cat {
String getName();
Object getValue();
}
This correctly compiles to the ImmutableCat object.
I try to access this in FooImmutableCatUser like so:
ImmutableCat.of("myString", myObject).
However, this throws the error: cannot find symbol above from both IntelliJ and Gradle.
I'm pretty sure I've seen code that uses Immutables from other packages before. How do you get gradle or IntelliJ to recognize Immutables from other packages while building? Is there a package dependency I need to list somewhere?
Edit: I have already tried enabling annotations with intellij via the APT instructions from Immutable. I've followed those instructions to the letter, but Immutables are still not recognized, possibly due to gradle and Intellij specifying different build output directories. Maybe that is the issue--I'll post back here if resolving that is actually the solution.
Related
I want to create an annotation handler to extend the Java language. However I can't do this easily, because of the SCL files. I wanted to know if the Lombok developers made it this hard on purpose.
If I try extending JavacAnnotationHandler, it can't find it in lombok.jar because the name is JavacAnnotationHandler.SCL.Lombok. I cloned the GitHub repository but I keep getting errors with duplicate classes in the resources.after and resources.before package and Java 12 syntax. I am using lombok 1.18.8.
This is what I have.
import lombok.javac.JavacAnnotationHandler;
public class SingletonJavacHandler extends JavacAnnotationHandler<Singleton> {
It says "Cannot resolve symbol 'JavacAnnotationHandler'"
The SCL files are to hide lombok implementation classes from autocomplete dialogs in IDEs.
The resources-before and resources-after files should not be compiled. They are in the test resources, because our testing framework processes them.
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.
Using Android Studio and creating a java library module as part of a sub project I get an error on the following java statement:
javaFile.writeTo(System.out);
and it complains of can not resolve symbol 'writeTo' and unknown class 'System.out'.
Here's the gist of the source code class
import com.squareup.javapoet.JavaFile;
import com.squareup.javapoet.MethodSpec;
import com.squareup.javapoet.TypeSpec;
import javax.lang.model.element.Modifier;
public class MyClass {
...
JavaFile javaFile = JavaFile.builder("com.foobar.helloworld", helloWorld)
.build();
javaFile.writeTo(System.out);
}
A bit hard to say without knowing exactly what your exception was, but I had something similar pop up when I was testing out a sub-module annotation processor. When linking the processor to my main module, I was getting a java.lang.NoClassDefFoundError: com/squareup/javapoet/MethodSpec. I was using android-apt to get the annotation processor working, so in my build.config my dependencies had the apt configuration definition:
dependencies {
...
apt 'com.squareup:javapoet:1.7.0' // <- Note that since my Processor used javapoet, I had to include Javapoet in the main module's apt dependency as well as my processor jar
apt files('../processor/build/libs/processor.jar')
}
Once i included the above noted dependency, then all worked fine. Not sure if this applies to your situation without more details, but this got me back on track.
I'm trying IntelliJ IDEA after many years as an Eclipse user. At the same time, I'm working on a project that I've inherited with many dependencies.
One class will not compile, because IDEA claims that a method in another class does not exist. I can see the method in its source. Control-clicking on the class name in the IDEA editor takes me to the source that looks OK.
My hypothesis is that the compiler isn't using the class compiled from the source within the project, but a class with the same name, somewhere among my dozens of library jars.
How can I find out where IDEA's compiler is finding the clashing class?
CTRL-N and entering the class name should show you all of the matching classes from across the classpath, and which directory/JAR they're in. If there's a clash, you should have duplicates in that list.
Another possibility is that the source you have for the referenced class doesn't match the compiled version of that class.
I am having problems compiling some Scala with Maven or Eclipse where I try to import a class from a Java jar which contains both a namespace and class of the same name.
I can compile with scalac, however.
E.g. the Java project (jar) contains:
src/foo/bar.java
src/foo/bar/some_resource.txt
-> foobar.jar
Scala project references foobar.jar
Foobartest.scala:
import foo.bar
class foobartest {
}
The compiler complains with:
package foo contains object and package with same name: bar
one of them needs to be removed from classpath
Using Maven 3.0.03/Eclipse 3.7.1 with Scala 2.9.0.1 (and maven-scala-plugin).
The jar which I am having problems with is jenkins-core-1.399.jar - it definitely contains several instances where there is a namespace and object of the same name.
I am attempting to write a Jenkins plugin in Scala (I could do this in Java but would prefer scala since all of our libraries are in scala), which is dependent on using Maven -
https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial.
That kind of limitation was outlined in SI-4695: package object misbehaves in the presence of classfiles.
As suggested in SI-2089 (naming restriction makes some jars unusable), you could try and use the "resolve-term-conflict", as implemented in changeset 25145:
Added a -Y option to resolve namespace collisions between package and object.
It's a blunt instrument: if people have lots of these conflicts they need to resolve in individually nuanced fashion, they'll probably remain out of luck.
val termConflict = ChoiceSetting ("-Yresolve-term-conflict", "strategy", "Resolve term conflicts", 113 List("package", "object", "error"), "error")
// Some jars (often, obfuscated ones) include a package and
// object with the same name. Rather than render them unusable,
// offer a setting to resolve the conflict one way or the other.
// This was motivated by the desire to use YourKit probes, which
// require `yjp.jar` at runtime. See SI-2089.
The actual compiler option is "-Yresolve-term-conflict:strategy" where strategy is either package, object, error.