I dived into Antlr a while ago, but I've noticed that the compile times are unbelievably long (the progress will sit at 100% for 5 minutes while Eclipse complains about Antlr). When all Antlr references are removed, but antlr-3.4-complete.jar is still included, the problem persists. As soon as it is removed from the build path, the compile time goes back down to infinitesimal.
Also, compiling more than once in a Eclipse session causes an out of memory error.
What could be going on? Is it really recompiling the whole ANTLR library every time? How can I compile it in a timely manner?
Edit: The complaints eclipse gives are warning about inner classes (as shown below).
[2012-08-13 22:23:39 - HoloCalc] Dx warning: Ignoring InnerClasses
attribute for an anonymous inner class
(antlr.TokenStreamRewriteEngine$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is not an inner class.
Related
I am writing a java program that compiles using generated class files (as in .java files) using my own code generator. The naming convention I am using for these generated files is public class classname_generated {}.
e.g. Foo_generated foo;
The problem is, because these generated files are only added to the project source when my code generator creates them before compile (and then removed after compile) Eclipse serves up the warning "classname_generated cannot be resolved to a type" whenever I declare an instance, now I am not bothered that the Eclipse doesn't give me the nice little list of members of the class when write my code, but it would be nice if I could suppress the "could not be resolved to a type" warning.
My question is, is it possible to suppress those warnings for only code that follows the pattern of 'classname_generated'? i.e. only suppress it for code like Foo_generated of Bar_generated
I'm trying to understand more about how GWT compilation works.
More specifically, I want to know how does GWT decide that a particular error is fatal, and the app compilation should fail because of it, and how does it decide that compilation is successful, even though there are compilation errors.
The reason I'm asking is that it's very difficult to distinguish legitimate errors in my log when doing a search, from ones that don't seem to cause any problem.
I'm talking about GWT 2.7 and GWT 2.8 (which I've seen they exhibit the same behavior).
Also, I'm using GWTP 1.5.3, if this is relevant somewhat.
A concrete example: I have this error in my logs:
Tracing compile failure path for type 'myApp.ClientModule'
Errors in 'file:/E:/data/.../myApp/ClientModule.java'
Line 24: No source code is available for type myApp.client.ServicesProvidersModuleGen; did you forget to inherit a required module?
Checked 1 dependencies for errors.
The error above does not make my app to fail compilation, and myApp works just fine (the class is something that registers some GIN bindings, which also work).
Why didn't GWT failed my compilation when it encountered that error?
Additionally, I also have other errors such as:
Errors in 'com/google/gwt/validation/client/impl/AbstractGwtSpecificValidator.java'
Line 102: No source code is available for type javax.validation.ValidationException; did you forget to inherit a required module?
Line 177: No source code is available for type javax.validation.ConstraintValidator<A,T>; did you forget to inherit a required module?
Line 153: No source code is available for type javax.validation.groups.Default; did you forget to inherit a required module?
Line 302: No source code is available for type javax.validation.ConstraintViolation<T>; did you forget to inherit a required module?
These errors also don't fail my compilation. Why?
Edit1: forgot to add.
I'm tempted to guess that compilation fails when the error is in something directly reachable from an entry point, and that compilation is OK when that code is not reachable.
However, I have the counter-example of code with annotations.
I have code that IS reachable from the entry point, and has annotations whose source code is not available, and yet the compilation succeeds (although this is the only exception that I could find so far).
Your analysis is good.
GWT will scan the entire classpath, ignoring everything not in the source path and "rebasing" super-sources. During that scan, it emits the kind of error you saw, but only when code will reach the missing sources (from entry points) the error will become fatal. Annotations are no exception, but code will never actually reach them as their just metadata (unless you implement an #interface, which Java allows). Annotations can be used by generators though, in which case they can fail the build.
Note that if you use -failOnError (or -strict, which is an alias), then all errors are fatal. You should aim for turning this on IMO.
I recently added another "jar" file to my AndroidStudio project, rt.jar. It's the second module I've brought in, so I brought it in the exact same way as the first.
However when I try to debug I get this wonderfully long error in AndroidStudio below. I get the sense that I might need to recompile the jar file mysef? But am not sure. I thought someone here might tell me exactly what I need to do so I don't waste a while lot of time.
p.s. I thought of perhaps doing through the source files for each class I need in my app, it's just a few. But somehow I fear that might be too kludgy.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.Channel$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ChannelSftp$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ChannelSftp$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ConfigRepository$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ChannelSftp$3) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.ConfigRepository$2) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.JSch$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.jcraft.jsch.Util$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.
trouble processing "java/applet/Applet.class":
Ill-advised or mistaken usage of a core class (java.* or javax.*)
when not building a core library.
This is often due to inadvertently including a core library file
in your application's project, when using an IDE (such as
Eclipse). If you are sure you're not intentionally defining a
core class, then this is the most likely explanation of what's
going on.
However, you might actually be trying to define a class in a core
namespace, the source of which you may have taken, for example,
from a non-Android virtual machine project. This will most
assuredly not work. At a minimum, it jeopardizes the
compatibility of your app with future versions of the platform.
It is also often of questionable legality.
If you really intend to build a core library -- which is only
appropriate as part of creating a full virtual machine
distribution, as opposed to compiling an application -- then use
the "--core-library" option to suppress this error message.
If you go ahead and use "--core-library" but are in fact
building an application, then be forewarned that your application
will still fail to build or run, at some point. Please be
prepared for angry customers who find, for example, that your
application ceases to function once they upgrade their operating
system. You will be to blame for this problem.
If you are legitimately using some code that happens to be in a
core package, then the easiest safe alternative you have is to
repackage that code. That is, move the classes in question into
your own package namespace. This means that they will never be in
conflict with core system classes. JarJar is a tool that may help
you in this endeavor. If you find that you cannot do this, then
that is an indication that the path you are on will ultimately
lead to pain, suffering, grief, and lamentation.
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...
I generate some code using CXF from a WSDL-file. When compiling the code with version "1.6.0_16" with the flag -Xlint I get the following warning:
warning: [cast] redundant cast to javax.xml.bind.JAXBElement<java.lang.Boolean>
[javac] this.r = ((JAXBElement<Boolean> ) value);
What does the warning mean, should I be worried? As I have generated and not written the code, what can I do to get rid of this specific warning?
No, you should not be worried, redundant casts are harmless.
It's common for generated code to compile with warnings, you generally just ignore them. Better yet, compile the generated code into a separate JAR, and reference that from your main code. That way, you don't need to recompile the generated code, and you won't see the warnings every time.
I had a similar problem while CXF was generating code redundant cast to byte[] while -Werror and -Xlint:all was set in maven to compile the code
A possible workaround for me/us was to add:
-Xlint:-cast to suppress the warning and keep the -Werror flag