When I use the JetBrains IDEA generate the constructor for Java Class, I always get a separate line for the first parameter. For example:
public Test(//this parameter in next line.
Class<Test> clazz) {
super(clazz);
}
I think this should be some configure for the template, but I cannot find it.
Related
I've recently joined a codebase that no one seemed to ever run SonarLint against, and now every test class I open in IntelliJ is highlighted like a Christmas tree - all test methods are public, even though JUnit5 is used.
Tired of removing those public modifiers manually, I decided to implement an SSR template to do that for me. However, I can't seem to make it work with method parameter annotations! (which seem to be rather usual thing with JMockit)
The best I can have thus far is this:
Open Edit->Find->Replace structurally
Paste this into Search field:
#$MethodAnnotation$
public void $MethodName$(#mockit.Injectable $ParameterType$ $Parameter$) {
$statement$;
}
Choose file type: Java - Class Member
Add filter for MethodAnnotation variable: Text=org.junit.jupiter.api.Test
Add Min=0 for statement and Parameter variables
Paste this into Replace field:
#$MethodAnnotation$
void $MethodName$(#Injectable $ParameterType$ $Parameter$) {
$statement$;
}
(mind the indentation, otherwise it will be problematic!)
Select Complete match value for Search target
Find
As you can see, the annotation is hard-coded, which of course limits the applicability of this snippet seriously.
Is this a problem with IntelliJ or rather my bad knowledge of SSR? What would be a proposed solution?
I'm just trying out Spring Shell 2. The section Dynamic Command Availability of the reference documentation shows three ways to indicate availability. However, all of them rely on a naming scheme or string parameter in an annotation. This will break (at runtime) if one uses the refactor functionality of an IDE. So, is there a possibility to use the Dynamic Command Availability feature in a refactoring-safe way?
Update 1:
Considering the answer below, I think this snippet demonstrates the solution:
#ShellComponent
public class MyCommands {
private final static String ADD_NAME = "add";
#ShellMethod(key=ADD_NAME, value = "Add two integers together.")
public int addTwoInts(int a, int b) {
return a+b;
}
#ShellMethodAvailability(ADD_NAME)
public Availability checkAddAvailability() {
return Availability.available();
}
}
Note that the string parameter in the annotation is the command name, so if you specify it both on the availability method and on the command method, this will survive refactoring.
Bonus points if you extract the command name in a constant.
I have an overridden function, where the parameter has a different name in the overridden version.
Original function:
fun hookEvent(event: Event) { ... }
overridden function:
fun hookEvent(e: Event) { ... }
This gives me a warning that it can cause problems when using named arguments.
When I select Refactor->Rename, and try to rename 'e' (in the overridden function) to 'event', IntelliJ searches my entire project and finds every single place where I have overridden the original function, and tries to rename the parameter in all of them. Then I get conflicts because in some of those places, 'event' is already a local variable in those functions.
I only want it to rename that particular instance of the parameter, in that particular overridden function. How?
I'm getting the following error when trying to execute my custom build definition (containing only 1 custom CodeActivity):
Exception Message: Expression Activity type 'CSharpReference`1' requires compilation in order to run. Please ensure that the workflow has been compiled. (type NotSupportedException)
I've tried multiple suggested answers to this error, but none of them are applicable to my activity. My CodeActivity only has a couple of methods that search through directories for specific files, and then returns a delimited string containing the file names.
I don't use any WorkflowInvoker or any DynamicActivities. For what reason would I keep getting this error?
Thanks
I had the same error on an assignment step.
System.NotSupportedException: Expression Activity type 'CSharpValue`1' requires compilation in order to run.
Please ensure that the workflow has been compiled.
The resolution was to remove the carriage returns from statement.
For example this works:
new Foo() { Bar = new Bar() { MyProp1 = "123" } }
This does not:
new Foo()
{
Bar = new Bar()
{
MyProp1 = "123"
}
}
I decided not to work in a clean xaml file, but instead to use the Default Template provided by TFS. The Default template ran my activities without errors.
I was able to fix this solution as well by using the Default Template provided by TFS, clearing all of their activities, and adding the custom activities and arguments in my original custom template.
However, more insight in to this issue, it seems to be caused by the fact that custom template use C# expressions to handle the arguments. Where as the default template is set up to use VB Expressions for it's arguments.
In my case, the language didn't matter because the values were simply strings.
There is a "NameAndType" structure in the constants pool in .class file.
It is used for dynamic binding.
All methods that class can "export" described as "signature + return type".
Like
"getVector()Ljava/util/Vector;"
That breakes my code when return type of the method in some .jar is changed, even if new type is narrower.
i.e:
I have the following code:
List l = some.getList();
External .jar contains:
public List getList()
Than external jar changes method signature to
public ArrayList getList().
And my code dies in run-time with NoSuchMethodException, because it can't find
getList()Ljava/util/List;
So, I have to recompile my code.
I do not have to change it. Just recompile absolutely the same code!
That also gives ability to have two methods with one signature, but different return types! Compiler would not accept it, but it is possible to do it via direct opcoding.
My questions is why?
Why they did it?
I have only one idea: to prevent sophisticated type checking in the runtime.
You need to look up to the hierarchy and check if there is a parent with List interface.
It takes time, and only compiler has it. JVM does not.
Am I right?
thanks.
One reason may be because method overloading (as opposed to overriding) is determined at compile time. Consider the following methods:
public void doSomething(List util) {}
public void doSomething(ArrayList util) {}
And consider code:
doSomething(getList());
If Java allowed the return type to change and did not throw an exception, the method called would still be doSomething(List) until you recompiled - then it would be doSomething(ArrayList). Which would mean that working code would change behavior just for having recompiled it.