Is it possible apply JavadocMethod checker only on methods in interface? (not in implementation classes)
We had plan to implement it also, keep at eye on issue, not sure when we fix it, or welcome to provide patch we already have full infrastructure for development.
If you are using Java 6, you can annotate the implementing method with #Override, which will tell the JavadocMethod checker not to require a Javadoc comment. Quoting the JavadocMethod docs:
Javadoc is not required on a method that is tagged with the #Override annotation.
The documentation continues stating that you need Java 6. In Java 5, you can still use {#inheritdoc}, which is better than nothing:
However under Java 5 it is not possible to mark a method required for an interface (this was corrected under Java 6). Hence Checkstyle supports using the convention of using a single {#inheritDoc} tag instead of all the other tags.
The built-in Eclipse code formatter can automatically add the #Override annotations for you, so this should be pretty much what you need.
Related
I have a question to ask regarding checkstyle.
It seems that the checkstyle api accepts both module name,
ConstantName and ConstantNameCheck (ConstantName with Check concatenated) for the configuration file, checkstyle.xml.
I would like to ask why is there a double standard here even though documentations on http://checkstyle.sourceforge.net/ only promotes ConstantName module and what is the difference between using either of them? Will either one of them gets deprecated in future?
Thanks!
Behind the scenes, the ConstantName check is implemented by a Java class called
com.puppycrawl.tools.checkstyle.checks.naming.ConstantNameCheck.
You could actually refer to the module in checkstyle.xml by this so-called "fully qualified" name. The other notations are shorthand offered by Checkstyle for convenience. ConstantNameCheck is the simple name of the implementing Java class, and ConstantName is still shorter. Checkstyle will try all three variants when looking for the module in your checkstyle.xml. So, there is no difference between these notations.
The recommended way is to use the most concise form, ConstantName, but as far as I know, none of the other forms is going to get deprecated any time soon.
I have this code from old castle:
IoC.Container.Register(
AllTypes
.FromAssemblyNamed(a)
.Pick().WithService.FirstInterface()
.Configure(o => o.LifeStyle.PerWebRequest));
When I upgrade to castle 3.2 I get this error:
Castle.MicroKernel.Registration.AllTypes' is obsolete
And this error for o.LifeStyle.PerWebRequest :
Only assignment, call, increment, decrement, await, and new object expressions can be used as a statement
How can I fix this?
Like #charleh said, AllTypes was replaced with Classes so fixing this problem is a simple find and replace.
Actually if you look at the compiler warning it should say:
'AllTypes' has been deprecated and will be removed in future releases.
Use 'Classes' static class (if you want to just register concrete
classes) or 'Types' static class (if you want to register interfaces
or abstract classes too) instead. It exposes exactly the same methods.
The reason for this change was that AllTypes was a lie - it was only matching concrete (non-abstract) classes, so Classes is a much better name that better tells you what it really does.
As for the other problem, changing the property call to a method call will fix it:
Container.Register(
Classes.FromAssemblyNamed(a)
.Pick().WithServiceFirstInterface()
.Configure( o => o.LifestylePerWebRequest()));
Or simpler yet, skipping the Configure:
Container.Register(
Classes.FromAssemblyNamed(a)
.Pick().WithServiceFirstInterface()
.LifestylePerWebRequest());
Windsor ships with BreakingChanges.txt file which describes breaking changes and how to upgrade.
The first issue is that AllTypes is equivalent to Classes (I actually learned this this morning!)
So instead of
IoC.Container.Register(AllTypes.etc)
Use
IoC.Container.Register(Classes.etc)
Not sure about the other but quick bit of searching seems to suggest that the lifestyles are pluggable in 3.2, you may be missing a reference
Edit:
Ah: Looks like you have referenced the client build of Castle.Windsor dll - there's another build against the full .NET profile which contains the type you need - check your references
PerWebRequest Lifestyle missing in Castle Windsor 3.2
I'm following this guide http://javaeenotes.blogspot.com/2011/06/short-introduction-to-jmock.html
I've received the error
java.lang.SecurityException: class "org.hamcrest.TypeSafeMatcher"'s signer information does not match signer information of other classes in the same package.
In the guide the author says:
The solution is make sure the jMock libraries are included before the
standard jUnit libraries in the build path.
What makes up the "standard jmock libraries" and the "junit libraries"?
Junit only has one jar so that's easy, but jmock comes with over 10 different jars.
I've been using: j-unit4.10, jmock-2.5, hamrest-core and hamcrest-library
What are the hamcrest core and library classes for?
i'm a committer on both libraries. JMock depends on hamcrest to help it decide whether an call to an object is expected. I suggest just using the hamcrest-all jar. The split between hamcrest core and library was to separate the fundamental behaviour of matching and reporting differences from a convenient implementations of the most common cases.
Finally, if you're using hamcrest, I suggest you use the junit-dep jar to avoid clashes with some features of hamcrest that are included in the junit.jar
JUnit is used to do Unit test in order to test your methods. JMock is used to test your program inside a context, You will have to know what you are expecting to send to the context (ENV) and what will answer the context.
JMock use JUnit, that is why, in order to avoid dependency conflicts, you need to include it before JUnit.
The 10 libraries of JMock are kind of add-ons if you need to use JMock script or any other functionnality not available in the JMock core.
You don't need to know about Hamcrest-core library to use JMock. Just follows the guide on the web site (don't use version 1 of JMock) and Organize your libraries in the correct order (JUnit should be last in order to avoid your error)
mock frameworks licke jmock do some black magic behind the scenes
( including, but not limited to runtime byte code manipulation )
to provide mock methods classes and whatever. To be able to do this,
some tweaks in basic junit classes are necessary, and the only way to do this is to
register itself as java agent before JU classes are loaded.
Also, put your mock framework before junit in classpath
After installing jdk 7 and switching java platform for my project in ide i get this when im trying to build project.
warning: [options] bootstrap class path not set in conjunction with -source 1.6
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.NoSuchMethodError: com.sun.tools.javac.util.Name$Table.instance(Lcom/sun/tools/javac/util/Context;)Lcom/sun/tools/javac/util/Name$Table;
at uk.org.retep.util.javac.JavacUtils.<init>(JavacUtils.java:128)
at uk.org.retep.util.annotation.AnnotationScannerProcessor.process(AnnotationScannerProcessor.java:76)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1106)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
at com.sun.tools.javac.main.Main.compile(Main.java:419)
at com.sun.tools.javac.main.Main.compile(Main.java:333)
at com.sun.tools.javac.main.Main.compile(Main.java:324)
at com.sun.tools.javac.Main.compile(Main.java:76)
at com.sun.tools.javac.Main.main(Main.java:61)
I know that sun switched some apis or something, but ide doesnt tell me whats wrong exactly. Thanks in advance.
You should really share your code that's causing the exception, but the exception indicates that you're using an internal Java API (any class contained in the com.sun packages). You shouldn't be using those APIs directly, as they're considered private implementations and subject to change. As those APIs are private, it isn't as simple as looking for the Javadoc to see what methods are available, but suffice it to say that the method you're calling doesn't exist. You have a few options:
If you're calling this method directly, you need to refactor. You should look for ways to accomplish the same work using public APIs.
If this happens after calling a library method, you should file a bug with the library maintainer informing them about the error and the risks of using the com.sun APIs.
If this happens after calling a public Java API (anything in the java or javax packages) then You should file a bug report with Oracle. This one seems unlikely though.
Also, if you share your code, we may be able to better help you.
[edit]
Further, see this page for more information about why you shouldn't use classes in the com.sun packages.
I am curious about the usage of the feature known as open classes or monkey-patching in languages like e.g. Ruby, Python, Groovy etc. This feature allows you to make modifications (like adding or replacing methods) to existing classes or objects at runtime.
Does anyone know if major frameworks (such as Rails/Grails/Zope) make (extensive) use of this opportunity in order to provide services to the developer? If so, please provide examples.
Rails does this to a (IMHO) ridiculous extent.
.Net allows it via extension methods.
Linq, specifically, relies heavily on extension methods monkey-patched onto the IEnumerable interface.
An example of its use on the Java platform (since you mentioned Groovy) is load-time weaving with something like AspectJ and JVM instrumentation. In this particular case, however, you have the option of using compile-time weaving instead. Interestingly, one of my recent SO questions was related to problems with using this load-time weaving, with some recommending compile-time as the only reliable option.
An example of AspectJ using load-time (run-time) weaving to provide a helpful service to the developer can be Spring's #Configuration annotation which allows you to use Dependency Injection on object not instantiated by Spring's BeanFactory.
You specifically mentioned modifying the method (or how it works), and an example of that being used is an aspect which intercepts am http request before being sent to the handler (either some Controller method or doPost, etc) and checking to see if the user is authorized to access that resource. Your aspect could then decide to return – prematurely – a response with a redirect to login. While not modifying the contents of the method per se, you are still modifying the way the method works my changing the return value it would otherwise give.