im working on a huge project which has a lot of old code.
I found manually found some random case classes which are not used in the project and asked myself how many of those exists.
But I found no method to found them via scalac compiler or via some Intellij magic.
This code often uses sometimes this companion structure
object MyCompanionClass{
final case class TEST(...)
...
}
Running unused declaration in intellj ofcourse delivers only findings in java..
Can anyone help?
regards
Related
I've come up against an odd issue in Eclipse while using the Stanford CoreNLP API. I've written a custom implementation of the Annotator interface, which amongst other things specifies two methods with the type signature Set<Class<? extends CoreAnnotation>>.
I've implemented those methods, but Eclipse is showing an error telling me that the type signature is incorrect. Specifically, it reports, The return type is incompatible with Annotator.requires(). The recommended fix suggests changing the return type to exactly the same type I already have written, but still leaves the error:
As you can see, the supposed `incorrect' type is exactly the same as the type given in the interface.
The project compiles correctly using mvn compile, so this isn't an actual compiler problem. Has anyone seen this before, and can you advise as to how to make those errors go away?
Edit: added screenshot showing the error
Edit2: added details of the error message in Eclipse
I have a routes file like this:
GET /getOf/:city/:fi/:state/:zipCode cont.Offer.getOf(city:String, fi:String, state:String, zipCode:String)
In my scala class, my code is like this:
def getOf(city:String, fi:String,state:String,zipCode:String) = Action(parse.anyContent) {request =>
val offer = Offer(city,fi,state,zipCode);
Ok(Json.toJson(offerService.getOffer(offer)));
}
But when I run I get this compilation error:
too many arguments for method apply: (name: String, constraint: String)play.core.DynamicPart in object DynamicPart
But same code works fine if I have only one argument. I even not understanding what's the problem. Yes, I have created Eclipse project with play clean-all and others. But still same problem persists.
Can anyone please guide me on this? As I am very new to Play framework and scala.
i got the same problem when i walk through from the below url http://scala-ide.org/docs/tutorials/play/index.html but the issue resolved by calling clean and then compile from play console solved the issue.
Note* i initially had the site at different folder.
I got this error only in eclipse IDE and if i make any changes to the views it compiled atonce whereas for controllers it check only when "RELOAD" works...till then you may see the error at eclipse ide but app works fine.
Today I cleared my .ivy cache and cleaned my project output targets. Since then I have been getting really strange behaviour when running tests with SBT or editing in the Scala IDE.
Given the following:
package com.abc.rest
import com.abc.utility.IdTLabel
I will get the following error:
object utility is not a member of package com.abc.rest.com.abc
Notice that com.abc is repeated twice, so it appears that the compiler uses the context of the current package when doing the import (maybe it's supposed to do this, but I never noticed it before).
Also, if I try to access classes in package com.abc from anywhere inside com.abc.rest (even using the full path) the compiler will complain that the type can not be found.
It appears that the errors only occur when I try to include files from parent packages. What I do find strange is that my code used to work. It only started happening after I cleaned up my project and my ivy cache, so maybe a later version of the compiler is more strict than the previous one.
I would love some ideas on what I can be doing wrong, or how I can go about troubleshooting this.
Update:
By first importing the parent classes and then defining the current package, the problem goes away:
import com.abc.utility.IdTLabel
import com.abs._
package com.abc.rest {
// Define classes belonging to com.abc.rest here
}
So this works, but I would still love to know why on earth the other way around worked, and then stopped working, and how on earth I can fix it. I had a good look, and could find no packages, objects or traits by the name of com anywhere inside the parent package.
Update relating to Worksheets:
Scala worksheets belonging to the same package share the same scope, which sounds obvious, but wasn't. Worksheets are not sand-boxed - they can see the project, and the project can see them. So all the 'test' object, traits, and classes you create inside the worksheet files, also becomes visible in the rest of the project.
I have so many worksheets that I did not even try to see where the problem came in. I simply moved them all to their own package, and like magic, the problem went away.
So, lesson learned for the day: If you create stuff inside worksheets, it's visible from outside the worksheet.
Anyway, this new found knowledge will come in handy, meaning anything 'interesting' can be build, monitored and tweaked inside the worksheet, while the rest of the project can actually use it. Quite cool actually.
It's still interesting to think how a sbt clean and cleaned up ivy cache managed to highlight the problem that was hidden before, but hey, that's another story....
(At the request of JacobusR, I'm making a proper answer out of my earlier comments).
This can happen if you have defined some class/trait/object inside package com.abc.rest.com. As soon as package com.abc.rest.com exists, and given that you are in package com.abc.rest, com would designate com.abc.rest.com as opposed to _root_.com. Fastest (but non-conclusive) way to check, without even scanning the source files, is to look for any .class files in the "com/abc/rest/com" sub-folder.
In particular you would get this behaviour if any of your files has duplicate package definitions (as in package com.abc.rest; package com.abc.rest; ...). If you have this duplicate package clause somewhere in the same file where you get the error, you wouldn't even see anything fishy with the .class files, as the failure at compiling the file would prevent the generation of .class files for any class definition inside the file.
The final bit of useful information is that as you found out the scala Worksheets are not sandboxed, and what you define in the worksheets affects your project's code (rather than only having the project's code affecting the worksheet). So a duplicate package clause in a worksheet could very well cause the error you got.
If package names conflict, there might be a custom error message for that. See if specifying the full path resolves the issue by starting from __root__. Ex. import __root__.com.foo.bar._
After migrating to Play-2.1 I stuck into problem that routes compiler stopped working for my routes file. It's been completely fine with Play-2.0.4, but now I'm getting the build error and can't find any workaround for it.
In my project I'm using cake pattern, so controller actions are visible not through <package>.<controller class>.<action>, but through <package>.<component registry>.<controller instance>.<action>. New Play routes compiler is using all action path components except for the last two to form package name that will be used in managed sources (as far as I can get code in https://github.com/playframework/Play20/blob/2.1.0/framework/src/routes-compiler/src/main/scala/play/router/RoutesCompiler.scala). In my case it leads to situation when <package>.<component registry> is chosen as package name, which results in error during build:
[error] server/target/scala-2.10/src_managed/main/com/grumpycats/mmmtg/componentsRegistry/routes.java:5: componentsRegistry is already defined as object componentsRegistry
[error] package com.grumpycats.mmmtg.componentsRegistry;
I made the sample project to demonstrate this problem: https://github.com/rmihael/play-2.1-routes-problem
Is it possible to workaround this problem somehow without dropping cake pattern for controllers? It's the pity that I can't proceed with Play 2.1 due to this problem.
Because of reputation I can not create a comment.
The convention is that classes and objects start with upper case. This convention is applied to pattern matching as well. Looking at a string there seems to be no difference between a package object and normal object (appart from the case). I am not sure how Play 2.1 handles things, that's why this is not an answer but a comment.
You could try the new # syntax in the router. That allows you to create an instance from the Global class. You would still specify <package>.<controller class>.<action>, but in the Global you get it from somewhere else (for example a component registry).
You can find a bit of extra information here under the 'Managed Controller classes instantiation': http://www.playframework.com/documentation/2.1.0/Highlights
This demo project shows it's usage: https://github.com/guillaumebort/play20-spring-demo
I have a class which uses a class from Eclipse OSGI jar (org.eclipse.osgi_3.7.2.v20120110-1415.jar) and which is well compiled within Eclipse IDE and it's compiler. But if I try to compile this class with Ant and JDK 1.7 compiler, the compiler outputs these errors:
[javac] /data/ant/sw_jdk1.7/test-Java7/com.tsystems.favbg.ui.core/src/com/
tsystems/favbg/ui/core/job/AbstractLoader.java:24:
error: type CopyOnWriteIdentityMap does not take parameters
[javac] private final CopyOnWriteIdentityMap<LoaderListener, String>
eventListenerMap = new CopyOnWriteIdentityMap<>();
and
error: cannot infer type arguments for CopyOnWriteIdentityMap;
[javac] private final CopyOnWriteIdentityMap<LoaderListener, String>
eventListenerMap = new CopyOnWriteIdentityMap<>();
[javac] reason: cannot use '<>' with non-generic class CopyOnWriteIdentityMap
Obviously javac does not recognize the class as using generics. But when I open it with Java Decompiler generic parameters are well recognized.
Does anybody know this problem and have a solution?
I would say that the problem is in the way that you are using CopyOnWriteIdentityMap class. I'm assuming that you are using this class:
org.eclipse.osgi.framework.eventmgr.CopyOnWriteIdentityMap
If you look at the javadocs, you will see that it is not a generic class. I also get the impression (from its package location) that it is not intended to be a general purpose utility class.
Perhaps you are using a different version of the JAR when you are compiling in Eclipse ... one that is a generic class. Either way, the compiler you are using via Ant thinks it is not generic.
I am finding discrepancies when reading a certification book for SCJP based on JDK 1.6, and, trying to write (copy and paste) code, compiling within JDK 1.7.
Perhaps, I am making the same mistakes all over, however they seem hard to comprehend. For example see my posts at http://www.coderanch.com/forums/posts/list/80/467890#2679297. I am not an expert, however, I find the curriculum of Angelika Langer (http://www.angelikalanger.com/Publications.html), to be appealing for consulting, given the tutorials available on the website relating to Java Generics.
What is your advice on the matter?