GWT compiling error at constructor - java

I have little knowledge how GWT works, so can anybody help me here?
This is the full log when I use Eclipse to compile my Playn html project:
http://pastebin.com/0EXNe57a
The same error appears when I try to run the html version with Maven in Eclipse or command line. Any feedback is appreciated.

GWT is compiling your Java-Code to JavaScript and emulating the Classes and Methods you are using from the JRE. But GWT is not supporting all Classes and Methods of the JRE.
You can find a List of Supported Classes and Methods on gwtproject.org.
In your case java.util.Vectoris supported but not the methods add(float, float) and set(float, float). So you should look for an alternative.
Note: The use of java.util.Vector is not recommended - regardless of working with GWT or not.
Update: Can't remeber that there ever was a method add(float, float) in java.util.Vector. Do you use that class or do you have an own util.Vector-Implementation?
If so you should check if your gwt.xml-file is including the source-path. Already explained here.

Related

RemoteActorRefProvider ClassNotFound

I'm struggling trying to get remote actors setup in Scala. I'm running Scala 2.10.2 and Akka 2.2.1.
I compile using [I've shortened the paths on the classpath arg for clarity sake]:
$ scalac -classpath "akka-2.2.1/lib:akka-2.2.1/lib/scala-library.jar:akka-2.2.1/lib/akka:akka-2.2.1/lib/akka/scala-reflect-2.10.1.jar:akka-2.2.1/lib/akka/config-1.0.2.jar:akka-2.2.1/lib/akka/akka-remote_2.10-2.2.1.jar:akka-2.2.1/lib/akka/akka-kernel_2.10-2.2.1.jar:akka-2.2.1/lib/akka/akka-actor_2.10-2.2.1.jar:." [file.scala]
I've continuously added new libraries trying to debug this - I'm pretty sure all I really need to include is akka-remote, but the others shouldn't hurt.
No issues compiling.
I attempt to run like this:
$ scala -classpath "[same as above]" [application]
And I receive a NSM exception:
java.lang.NoSuchMethodException: akka.remote.RemoteActorRefProvider.<init>(java.lang.String, akka.actor.ActorSystem$Settings, akka.event.EventStream, akka.actor.Scheduler, akka.actor.DynamicAccess)
at java.lang.Class.getConstructor0(Class.java:2810)
at java.lang.Class.getDeclaredConstructor(Class.java:2053)
...
Looking into the source code, it appears that Akka 2.2.X's flavor of this constructor takes 4 arguments (the Scheduler is removed). But in Akka < 2.2.X, the constructor takes 5 args.
Thus, I'm thinking my classpath isn't setup quite right. At compile-time, Scala must be finding the <2.2.X flavor. I don't even know where it would be finding it, since I only have Akka 2.2.1 installed.
Any suggestions!? Thanks! (Please don't say to use SBT).
The problem here is that the Scala distribution contains akka-actor 2.1.0 and helpfully puts that in the boot class path for you. We very strongly recommend using a dependency manager like sbt or maven when building anything which goes beyond the most trivial projects.
As noted in another answer, the problem is that scala puts a different version of Akka into the bootclasspath.
To more directly answer your question (as you said you don't want to use sbt): you can execute your program with java instead of scala. You just have to put the appropriate Scala jars into the classpath.
Here is a spark-dev message about the problem. The important part is: "the workaround is to use java to launch the application instead of scala. All you need to do is to include the right Scala jars (scala-library and scala-compiler) in the classpath."

locate imports definition in java

I'm a newbie in java. Is there any way to find the required imports(or missing imports) in java programming?. I know that in modern editor like Eclipse and Netbeans. But we have to do java in notepad for examination, that's why.
For example, When I use Jframe, I want to know which is the required imports. Is it possible to locate 'import's definition in a directory or file?
Run the compiler javac which tells you the types that cannot be resolved (this imports are missing).
Then you can use the javadoc from the API. In the left lower corner there is a complete list of classes in the API. Search the class and click on it then you know in which package it is.

Blackberry #Override notation error

In Eclipse, I did: Source > Clean up, and did a clean up according to these rules:
Change non static accesses to static
members using declaring type
Change indirect accesses to static
members to direct accesses (accesses
through subtypes)
Remove unused imports
Add missing '#Override' annotations
Add missing '#Deprecated' annotations
Remove unnecessary casts
Remove unnecessary '$NON-NLS$' tags
but I can't seem to compile it anymore. I get the following error:
Error preverifying class com.myapp.blackberry.Override
java/lang/NoClassDefFoundError: java/lang/annotation/Annotation
Error!: Error: preverifier failed: C:\eclipse\plugins\net.rim.ejde.componentpack6.0.0_6.0.0.29\components\bin\preverify.exe -d C:\DOCUME ...
Packaging project myapp failed (took 0.422 seconds)
When I hover over #Override, it gives me suggestion "Override cannot be resolved to a type"
I am not sure what to do at this point..
Blackberry development is built on top of j2me, which has the language features of Java 1.3. This means it doesn't support annotations. You can remove the #Override annotations and your code will work. Remember these are optional although recommended anyways.
What I do, is write //#Override instead. When/If annotations are added in the future it will be easy to do a regex replace and remove the comment marks.
Seems to be impossible:
The deal is Java ME uses version 1.4 of Java Language Specification.
You cannot use Java 5 language features.
Seems you'll have to do without annotations...

Why is javac failing on #Override annotation

Eclipse is adding #Override annotations when I implement methods of an interface. Eclipse seems to have no problem with this. And our automated build process from Cruise Control seems to have no problem with this. But when I build from the command-line, with ant running javac, I get this error:
[javac] C:\path\project\src\com\us\MyClass.java:70: method does not override a method from its superclass
[javac] #Override
[javac] ^
[javac] 1 error
Eclipse is running under Java 1.6. Cruise Control is running Java 1.5. My ant build fails regardless of which version of Java I use.
The #Override annotation spec changed in Java 1.6. In Java 1.5, the compiler did not allow the #Override annotation on implemented interface methods, but in 1.6 it does. First search result I found is a blog post here.. It was not well documented, but it did change.
Eclipse is adding it because your Eclipse is set for 1.6 compliance. You should try to keep your build and eclipse environments on the same version of Java. It's unclear to me by your specifying Cruise Control is running Java 5 on whether or not it is compiling using a separate JDK6 or not.
Separate from the above 1.5 vs 1.6 #Override annotation rules, remember that Eclipse has its own compiler implementation (not javac) and will occasionally have different behavior. Whenever something compiles in Eclipse, but not Ant or Maven, you will need to find a way to make both compilers happy.
I can't really explain the problem you're seeing but it seems to be related to the fact that JDK 5 will not allow #Override on implemented methods of an interface, only on overridden methods present in a super class.
JDK 6 will allow #Override on any of them.
If your ant build fails it may be passing a source parameter to javac, asking for JDK 5 compliance.
The direct answer to the question "Why" an error is raised by javac when #Override is used in the context of a method implementation is actually in the java specifications:
"The rationale for this is that a concrete class that implements an interface will necessarily override all the interface's methods irrespective of the #Override annotation, and so it would be confusing to have the semantics of this annotation interact with the rules for implementing interfaces."
See http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.6.1.4
But apparently someone changed his mind for java 1.6 and 1.5 u21...
#Override tags for implemented methods are new to Java 1.6. In Java 1.5 #Override is only correct when overriding a method in a base class. Read more here and here.
A lot of people, including me, got busted by this. See here for a bigger SO discussion
Eclipse would be pointing to 1.6 version of Java rather than 1.5.
See here for configuring java version in eclipse.
Ensure that there is only one definition of that interface.
Example:
HttpServletRequest
This is an interface with different specs depending on provider.
Compare pax-web-jetty and apache-felix-jetty. They have different methods.
I have had the same problem when building a project with ANT. The solution to the problem was to change the following property inside the build.properties file:
javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
to:
javac.compiler=modern
That solved the problem and the project got compiled and deployed successfully.

Modern equivalent of javadeps?

I am looking for a replacement for javadeps, which I used to use to generate sections of a Makefile to specify which classes depended on which source files.
Unfortunately javadeps itself has not been updated in a while, and cannot parse generic types or static imports.
The closest thing I've found so far is Dependency Finder. It almost does what I need but does not match non-public classes to their source files (as the source filename does not match the class name.) My current project has an interface whose only client is an inner class of a package-private class, so this is a significant problem.
Alternatively if you are not aware of a tool that does this, how do you do incremental compilation in large Java projects using command-line tools? Do you compile a whole package at a time instead?
Notes:
javadeps is not to be confused with jdepend, which is for a very different purpose.
This question is a rewrite of "Tool to infer dependencies for a java project" which seemed to be misunderstood by 2 out of 3 responders.
I use the <depend> task in ant, which is ok, but not 100% trustworthy. Supposedly JavaMake can do this dependency analysis, but it seems to be rarely updated and the download page is only sometimes available.

Categories