Eclipse is up to date, cofoja too, and so are java jre/jdk.
ASM should be included in cofoja, but I downloaded the 3.3 just in case.
I followed all the procedures I could find in internet, but the first error eclipse is giving never changed from the first step: "Syntax error, insert "EnumBody" to complete BlockStatements".
The code is very basic:
import java.io.whatever;
import java.net.whatever;
import com.google.java.contract.Requires;
public class ManageSocketServerExplicit{
[...]
public ManageSocketServerExplicit(String p_ipAddress, int p_port){
#Requires("p_port >= 0")
this(p_ipAddress,p_port,10,1000);
[...]
}
}
The error is obviously at the end of the Require.
Configuration
There are several projects in the directory. Let's say that I want to use cofoja just on one of them.
The base directory is C:\svn_java\Progetti_NET, in which there is the project I want to use cofoja on, which is 'Malu'. Into it there are multiple source directories, not just a generic 'src', but the main is called 'Code', and it's the principal.
So the paths are (tried them with both slashes, nothing changes):
classoutput C:\svn_java\Progetti_NET\Malu\bin
classpath C:\svn_java\cofoja-1.1-r146.jar
sourcepath C:\svn_java\Progetti_NET\Malu\Code
Eclipse understands the namespace of cofoja, by the way: I can see the objects listed if I auto-complete them.
So 'Annotation Processing' is all set, and 'Factory Path' again contains "c:\svn_java\cofoja-1.1-r146.jar". The workspace automatically updates when there are changes, and both asmn and cofoja are in the libraries of the 'Java Build Path'.
I tried to add also the -vm command in eclipse.ini to use the jdk (C:/Program Files (x86)/Java/jdk1.7.0_21/bin), but again nothing changed.
Since the configuration is pretty simple it shouldn't be so hard to fix it, but I don't know how.
i used Cofoja with eclipse and i used this link to configure it.
However it has a missing factory path. You need to state the sourcepath too as shown in my image.
If you run it using eclipse, you have to set the run configurations of the file and add the following VM arguements
-javaagent:PATH TO JAR/cofoja.jar
And #Requires and #Ensures are method-level contracts.
You cant write it within the method. Instead you need to write it as follows
public class ManageSocketServerExplicit{
[...]
#Requires("p_port >= 0") // CONTRACT
public ManageSocketServerExplicit(String p_ipAddress, int p_port){
this(p_ipAddress,p_port,10,1000);
[...]
} }
Hope it helps :D
Ok, I understood what was wrong: after adding the source code of cofoja to the project I understood I placed the #Requires in the wrong place... The annotation #Ensures gave me this error, but I forgot about it.
:(
a very well realized tutorial: http://webcourse.cs.technion.ac.il/236700/Spring2013/ho/WCFiles/Contracts%20for%20Java.pdf
Related
I guess by asking this I might sound a bit illegible, but I'm still unsure as to how to approach the problem.
In my spring project (not really my, work stuff) I've got some groovy scripts which are initially treated as resources, yet in reality they are rather the "source code" which is compiled not during the gradle assembly of the project but during the runtime by the application itself. And everything's fine with that.
The problem is that the IDE doesn't treat the groovy file properly. Dumb example to somehow describe what I mean:
import myproject.example.blabla
import groovy.transform.CompileStatic
#CompileStatic
class SomeClass1 implements SomeClass2 {
private final SomeClass2 someName1
SomeClass1() {
someName1 = new something
}
#Override
String getSmth() {
return someName1.getSmth()
}
}
The problems:
when I make "command + left_click" on SomeClass2, it says Cannot find declaration to go to, but when I press "command + O" it finds the file because it actually exists
.getSmth() is red, because Cannot resolve symbol
So it seems that I need to somehow show the dependencies via gradle to IDE only. Like, somehow specify the dependencies explicitly for IntelliJ IDEA so that it would understand that it is a source code as well and stop underlining everything with red.
Such files must be located in the module's Source Root directory for the IDE to recognize them as sources and so that navigation would also work.
In a Gradle-based project IDE configures Source Roots automatically based on the Gradle's Source Sets configuration. For each Gradle source set IDE creates a module with one Source Root directory.
So you must configure Gradle to create source set for the directories where these files are located: add them into default sources sets or create a custom source set for them.
I know I am asking the very popular question. But I can not find the solution to the problem. I have a sandbox to which I added a code of the unit test MulticurveBuildingDiscountingDiscountAUDTest.java file and commented it.
Then I added the main method and I could successfully run the program (print something in a console).
Finally, I uncommented the code of the MulticurveBuildingDiscountingDiscountAUDTest.java file and I saw the following error:
The import com.opengamma.analytics.financial.instrument.index.GeneratorSwapFixedONMaster cannot be resolved.
And further in the code:
GeneratorSwapFixedONMaster cannot be resolved
I know that this import is located in the og-analytics src/test/java location, which I believe is not listed anywhere in the build path. I believe the problem is with a build path options and specially with classes like GeneratorSwapFixedONMaster which were created specially for tests. I have been playing around with cleaning, rebuilding projects, reinstalling and as a result updating the JRE. I have visited these Import *** cannot be resolved [duplicate] and these Eclipse error: “The import XXX cannot be resolved” questions.
Do you know what shall I do to cure the following error?
I have many problems with other imports from the original MulticurveBuildingDiscountingDiscountAUDTest.java file as well.
Update: #1 is a location of my file. #2 is the location of classes this project uses. The MulticurveBuildingDiscountingDiscountAUDTest.java file is taken from the src/test/java
Update 2: one may see that in Libraries I have included all the dependencies I might need (at least I do not know what else to add). The Maven Dependencies contains the hole og-analytics package:
You included the source (src) folder og-analytics/src/main/java which contains the *.java files instead of the classes (bin or classes) folder with the *.class files (in your case, probably og-analytics/target/classes).
But instead using Add Class Folder... you should add the project og-analytics in the tab Projects. Or even better, in the Maven pom.xml file add the dependency to the project og-analytics like you did for og-util.
I know that this import is located in the og-analytics src/test/java location, which I believe is not listed anywhere in the build path.
Perfectly explains your problem. In order to import any class, you must either have the source in your build path, or some directory that contains a compiled version of that class. It is that simply.
The answer is: get clear on your project setup. If you intend to use classes from somewhere, you have to make them available somehow. Otherwise it will not work. In your case: if your tests want to make use a certain thing - then you should probably add that "thing" to your test project (you should avoid putting test-only stuff to your "product" projects).
That is all there is to this.
Motivation:
I'd like to try if compile-time annotation processing fits my problem. It needs to work out of the box, no compiler arguments etc.
Current state:
I have:
The annotation
An annotation processor
A .jar containing both of these and a javax.annotation.processing.Processor file containing the FQCN of my processor in META-INF/services
What should happen:
It should autodetect the processor
It should process the annotation and create a new class (WiredAnnotated)
I should be able to use this class in one step of compilation (not multiple phases)
I wan't the editor to accept this class is generated (e.g. AndroidAnnotations manages this as well)
What actually happens:
It autodetects the processor
It creates a new class (in out/production/*/generated/)
I am able to use this class
The source code looks right
When decompiling it looks ok too
The editor cannot resolve the class (see screenshot)
What I tried:
Restarting IntelliJ
Invalidating caches
Checking for output of the annotation processor
Screenshot:
When compiling, it actually works as expected. I guess it has something to do with inspecting the wrong directories.
Does anyone have an idea/clue on what I'm doing wrong? Did I miss information which could help you help me?
Thanks in advance, Till
Well, you need to add you out/production/*/generated/ to projects source folder. So, IntelliJ will know about your generated classes.
You can make it via Right click on directory > Mark directory as source root.
or
Project structure (F4) > Modules > Sources tab > Source folders should contain all directories with your source codes, generated one inludes.
In android there is a gen dir in root folder, but notice, it glows blue or green which means it marked as Source folder, it is also visible in Project structure > Modules. It contains R, BuildConfig and Manifest.
I am importing a Jar file "com.ibm.mq.jar" into my workspace(Eclipse IDE).
While importing, a screen came where I could see all the classes in the Jar file.
After I imported it into the work space, I was able to import the package and following statement didn't give any error.
import com.ibm.mq.*;
But, in code I am not able to use any of the classes which were there in the package.
Like, "MQC" is a class in the package, but in code it doesn't reflect("MQC cannot be resolved as a type" error comes if I try to use it).
This jar file actually contains Websphere MQ API classes.
Can anyone advise, what am I missing.
If you're using MQ 7, check its documentation here. There was some stuff going on about deprecation of com.ibm.mq.mqc and, depending on the version you use, that class was replaced by com.ibm.mq.constants.MQConstants. Like this one, there are other cases.
In fact com.ibm.mq only contains the exception MQException, so you won't find any classes there. I suggest you check the version you're using and dig a little deeper into the docs, as a first step.
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).