I'm debugging a 3rd party proprietary jar. JD-eclipse generates the source just fine but I can't add breakpoints into the generated source code.
Eclipse complains the class file lacks line number info.
Is there any way to work around this?
Unfortunately, there is no workaround. If the original class was compiled without debug info it's lost to you - there's no way you can fabricate it out of the void.
Related
I'm working on a module project in NetBeans 8.2, with a GUI and everything. I'm using lots of the IDE functionality to auto-generate code for the GUI.
Every time I do a clean build of my project, I get a warning from the compiler:
warning: No processor claimed any of these annotations:javax.annotation.Generated
Browsing the build directory, I see that the IDE generates a class for me, Bundle.java, and it slaps the given annotation on top of it:
#javax.annotation.Generated(value="org.netbeans.modules.openide.util.NbBundleProcessor")
I need this warning to go away. I tried searching the web for an annotation processor that processes this specific annotation but I had no luck. Does an annotation processor for this specific annotation exist?
If this is a "harmless warning," I need to understand why it is harmless to justify its existence in my build output.
If needed I can include in this question the argument to the -processorpath option that is passed to javac from the IDE; I didn't include it on purpose because it is very long but I can add it if necessary
EDIT #1:
I did a "hacky" modification to the common.xml file under the NetBeans installation directory to make the invocation to javac not include the -processorpath option, and doing so makes the warning dissapear. I still do not understand why that is the case
A simple fix for this is to remove the #Messages annotation from the TopComponent class that is generated by the NetBeans code generator. It is that annotation that is responsible for generating the Bundle class, as per the NbBundle.Messages API Documentation.
As soon as you remove that annotation, you might get warnings from other annotations that rely on the contents of the #Messages annotation (i.e. TopComponent.OpenActionRegistration), so make sure to modify the contents of those annotation as well until nothing in your code depends on that Bundle anymore.
Hopefully nothing else in your code relies on your Bundle.
I have a file called MyFile.java and it contains multiple classes(none of them is public). Note that the file does not contain MyFile class. Apparently Javadoc is not happy about this and it generates a warning saying file does not contain class com.example.MyClass. A few solutions I looked into:
Move classes into their own files. This looks like the proper way of fixing the warnings, but the new files won't obliviously have the source control history, so I am trying to avoid it.
Create empty MyFile class. This is ugly.
Hide Javadoc warnings, preferably per file. There is a high chance that this is not possible.
A few questions that I have:
Why does Javadoc complain? I couldn't find any documentation, please point me to one. I think it is perfectly fine not to have a class with the same name as the file.
Any other suggestions I can look into?
Is it possible to hide warnings somehow? additionalparam="-Xdoclint:none" does not work.
Thank you all in advance
When building with maven from the command line, I encountered this error from maven-javadoc-plugin.
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.2.0:jar (default) on project code-mapping-database: MavenReportException: Error while generating Javadoc:
... error: cannot access DataSourceWrapper
Eclipse IDE reported a similar error.
This occurred after I had copied DataSourceWrapper.java to another (dependent) project and commented out all lines of DataSourceWrapper.java in the original project. After deleting the commented out version, the error went away. The effectively empty DataSourceWrapper.java file must have caused maven-javadoc-plugin to stop looking for class DataSourceWrapper.
I've recently discovered Error Prone and am integrating it into my Android build using the Gradle plugin linked on their page.
Since our project is using Icepick (and some other code generating annotation processors), we have generated source code, which gets compiled in. Unfortunately, some of the generated code triggers warnings in Error Prone, and I'd like to filter that noise out somehow.
The generated code shows up in the app/build/generated/source/apt/debug directory. How can I exempt this code from Error Prone's steely gaze?
Use the flag -XepDisableWarningsInGeneratedCode
See this issue on GitHub
In my case classes were annotated with #AvroGenerated and -XepDisableWarningsInGeneratedCode didn't work.
The solution was to exclude build directory from checks via -XepExcludedPaths:.*/build/.*
I am working on moving code from R2007a to R2013a. I am getting a java.lang.NoClassDefFoundError during my run in R2013a which does not appear in R2007a. It occurs when I call.
feval('get',fname,jevent);
Where fname is a product.ProxyField object for an Object Filter and jevent is a product.format.java.internal.JavaEvent.
The class is in a jar file on the path and is being accessed by another class in the same jar file. The stack trace does not leave the realm of the product if that helps.
I do not have access to the original code for the jar file. I do have access to code derived from that original code and both classes are in the same package. I'm guessing this has something to do with differences in the java version but I'm not sure what to do since I don't have the original code to recompile.
Unfortunately I can't provide actual source or full detail but a google search only yielded results for MATLAB startup issues. Any thoughts?
Seems like the difference between R2007a and R2013a is that the first uses 1.5 jre and second uses 1.6 jre. It would be easier to help you if you provided the stack trace showing the exception. Sometimes classes get moved around in between jvm versions, so having the actual missing classes would help in determining if the missing class is a class that was just moved around to a different package. You could take the missing class, google it adding the same exception message as you put above and seeing who else ran into similar issues.
I get the following IDE error which appears inline or on the package declaration of my classes, but doesn't prevent the code running or working as expected.
I tried manually downloading the javax-annotations.jar from Glassfish and placing that in both the classpath and also on the JDK external JAR resources areas, no help.
The type javax.annotation.meta.When cannot be resolved. It is indirectly referenced from required .class file.
The error appears anywhere that I use the Findbugs #NonNull annotations; any class which uses this annotation has the above message appear in the IDE on the package declaration line. The class however appears as error-free from the Package-Explorer or Navigator view.
I would quite happily ignore this, however it breaks the Mark-All-Occurences behaviour which I quite like, if anyone has any ideas on what I might have missed I would appreciate it!
The FindBugs jar already contains a jsr-305.jar, which contains an implementation of JSR-305.
More info in this previous question.
Edit Oh, you already did that--I didn't even know it was in annotations.jar as well.