In an UWP application I have a class like this:
public class MyClass
{
public event TypedEventHandler<MyClass, EventArgs> MyEvent;
}
When I run code analysis this code gives me two warnings:
CA1009 Declare the second parameter of 'TypedEventHandler' as an EventArgs, or an instance of a type that extends EventArgs, named 'e'.
CA1009 Declare the first parameter of 'TypedEventHandler' as an object named 'sender'.
How do I solve these issues? I've read the documentation about CA1009 but it doesn't give me any hint.
For the classic .NET pattern, your class should derive from EventArgs to fix the first warning, although that won't work for a Windows Runtime component. You should just ignore the warning.
For the classic .NET pattern, the first type should be Object but for newer designs (like WinRT) you should also ignore the second warning.
Related
I updated an application JDK from 1.6 to 1.8 but I kept the language level 1.6 in IntelliJ.
After updating I got compilation error in some tests in assertThat statements with checking type of an object. The code is like this:
assertThat((Class) myList.get(0).getMyClassType(), is(equalTo(MySubclass.class)));
myList is looking like this:
List<MyClassDefinition> myList = myClassDefinition.getMyClassDefinitions(reader);
Where definition of MyClassDefinition and getMyClassType() are like this:
public class MyClassDefinition {
private Class<? extends MyClass> classType;
public Class<? extends MyClass> getMyClassType() {
return classType;
}
}
and MySubclass is Myclass's subclass:
public class MySubclass extends MyClass {
#Override
public void initialise() {
// some action here!
}
}
The definition of MyClass is
public abstract class MyClass extends AnotherClass<AnotherType>{
//Definitions
}
The import for Assert is and equals library is this:
import static org.hamcrest.CoreMatchers.equalTo;
import static org.hamcrest.CoreMatchers.is;
import static org.hamcrest.MatcherAssert.assertThat;
and the hamcrest version is hamcrest-all-1-3
After changing project SDK to jdk 1.8 I am getting this error message:
Error:(136, 9) java: no suitable method found for assertThat(java.lang.Class,org.hamcrest.Matcher<java.lang.Class<MySubClass>>)
method org.hamcrest.MatcherAssert.assertThat(java.lang.String,boolean) is not applicable
(argument mismatch; java.lang.Class cannot be converted to java.lang.String)
method org.hamcrest.MatcherAssert.<T>assertThat(java.lang.String,T,org.hamcrest.Matcher<? super T>) is not applicable
(cannot infer type-variable(s) T
(actual and formal argument lists differ in length))
method org.hamcrest.MatcherAssert.<T>assertThat(T,org.hamcrest.Matcher<? super T>) is not applicable
(cannot infer type-variable(s) T
(argument mismatch; org.hamcrest.Matcher<java.lang.Class<MySubClass>> cannot be converted to org.hamcrest.Matcher<? super java.lang.Class>))
application is build with Ant and we have added hamcrest jar file to class file, so there is no change when we are altering JDK in project.
So my question is why this code is working with JDK 1.6 but not working with 1.8 while I am using same level of language (1.6) for compilation? Is it depend to different libraries some how?
Apparently, you had a problem with the generic type signatures which you worked around by inserting a type cast to the raw type Class, which causes the compiler to treat the entire statement as an unchecked operation using raw types only.
As you can see from the compiler message, org.hamcrest.Matcher<java.lang.Class<MySubClass>> cannot be converted to org.hamcrest.Matcher<? super java.lang.Class>, it now did a generic type check which (correctly) failed, but imho, it shouldn’t do that type check under Java 6 language rules. The problem stems from the fact that JDK8 doesn’t include the original Java 6 compiler but rather let the new compiler attempt to compile using the old rules, which may not be that precise.
But regardless of whether the behavior is correct or not, I wouldn’t expect a fix for it, as emulating the old Java 6 language rules is not of a high priority.
Note that with source level 1.8, the code compiles without problems, even without the raw type cast. The original problem stems from the restrictive signature of CoreMatchers.equalTo(…). The standalone expression equalTo(InstanceOfFoo) returns a Matcher<Foo>, which being passed to assertThat allows to only test instances of Foo (it’s even worse when using isA(Foo.class) which also can only test instances of Foo, which makes the test pointless).
With Java 8, there is target type inference, which allows, e.g.
Matcher<Object> m = equalTo(InstanceOfFoo);, which will infer Object for <T> and passes, as InstanceOfFoo is also assignable to Object. This also works in conjunction with the compound assertThat statement of your question, inferring a suitable type.
This guides us to the general solution that works with all language levels. Just use
assertThat(myList.get(0).getMyClassType(), is(equalTo((Object)MySubclass.class)));
Class<MySubclass> is, of course, assignable to Object which makes the cast a no-op. But then, getting a Matcher<Object>, you can check every object you like, including the result of myList.get(0).getMyClassType(), which is, of course, also assignable to Object. Unlike your original workaround, this doesn’t bear any raw type usage nor unchecked operation.
You could also use an explicit type instead of a cast, CoreMatchers.<Object>equalTo(MySubclass.class), but this eliminates the benefit of import static.
By the way, when matching Class objects, you may use sameInstance instead of equalTo.
Here is a question related to the algorithm of constructing the call graph for Java bytecode using CHA.
As there is no concrete method implementation for methods in abstract classes, adding a call edge to such methods might be a bit misleading.
take junit-4.12.jar for instance. runFailed has been defined in junit.runner.BaseTestRunner which is an abstract class. Besides, there are calls to runFailed in method getTest which also defined in junit.runner.BaseTestRunner
While in "Assumption Hierarchy for a CHA Call Graph Construction Algorithm"(Jason&Atanas), it is said that
"given a call site x.m(), where the declared type of x is C, the
possible runtime type of x must be a non-abstract subtype of C."
As far as i'm considered, without add a call edge(Calledge1) from junit.runner.BaseTestRunner getTest to junit.runner.BaseTestRunner runFailed, it is more reasonable to add a call edge(Calledge2) from junit.runner.BaseTestRunner getTest to junit/textui/TestRunner runFailed as TestRunner extends BaseTestRunner.
While after running test code to get the result of CallGraph.calledByStatistics(), only Calledge1 has been found. Calledge2 is missing.
Is there anybody can do me a favor to confirm this?
Thank you in advance.
Regards,
Jiang
I found OPAL offers two views of call graph. The second one won't add a "library-call" edge into call edge.
In CallGraph.calledByStatistics()
The binding is between Callsite (PC) to caller.method
for example: between “INVOKEVIRTUAL(junit.runner.BaseTestRunner{ void runFailed(java.lang.String) })” and
junit/runner/BaseTestRunner.public junit.framework.Test getTest(java.lang.String)
In CallGraph.callsStatistics()
The binding is between subtype.method to caller.method
for example:
between "junit/textui/TestRunner.protected void runFailed(java.lang.String)” and “junit/runner/BaseTestRunner.public junit.framework.Test getTest(java.lang.String)”
I need to set the Xaml property of a RichTextBox user control via a binding expression in Windows Phone 8, and I found that it is not a DP, so I have decided to inherit from a RichTextBox and add a DP that will change the Xaml property with PropertyChanged event, anyways the code looks like this, stripped out irrelevant parts.
public class RichTextBoxWithBindableXaml : RichTextBox
{
public string BindableXaml
{
get { return (string)GetValue(BindableXamlProperty); }
set { SetValue(BindableXamlProperty, value); }
}
public static readonly DependencyProperty BindableXamlProperty =
DependencyProperty.Register("BindableXaml",
typeof(string),
typeof(RichTextBoxWithBindableXaml),
new PropertyMetadata(0));
}
//xaml code
<local:RichTextBoxWithBindableXaml BindableXaml="{Binding PageContent , Mode=OneWay}"> </local:RichTextBoxWithBindableXaml>
And I get the following dreaded exception message:
Object of type 'System.Windows.Data.Binding' cannot be converted to type 'System.String'.
I have checked many solutions to these exceptions and similar problems with data binding, and still going through the suggested similar questions on the right, and still cannot see why a simple thing wont work for me. The code I listed above is just the simplest implementations of a DP with a binding expression. Btw, the source PageContent is from a INotifyPropertyChanged object, and it works, I know because, it can bind to TextBlock's Text property.
Am I missing out something so obvious? I wouldn't want to post question for such a straightforward thing, but I cant seem to solve in any way.
EDIT:
Following P.S note turned out to be completely irrelevant.
P.S. My final doubt was on the way xmlns namespace local is loaded. It is loaded as clr assembly, could xaml parser think my custom inherited class as clr-only and confuse since clr properties are not dependency properties. Hope it doesnt sound stupid, i'm desperate. It is as such :
xmlns:local="clr-namespace:RumCli"
I found out that I should either provide a null PropertyMetadata (new PropertyMetadata(null) instead of 0), or a metadata with a default value type if the DP is supposed to be used in Xaml. For my sceneario, since I will make use of the PropertyChangedCallback, the propertymetadata that will passed to the Register method looks like this.
new PropertyMetadata(default(string), new PropertyChangedCallback(OnBindableXamlChanged))
hope, it helps to others.
For each dependency property one must supply a non subscribed value (not a C# term here) which suites the type of object which the consumer will access.
To quote MSDN Dependency Property Metadata
Dependency property metadata exists as an object that can be queried to examine the characteristics of a dependency property.
So for the value type results, a default for the different value types, such as a double is to use double.NaN. A decimal use decimal.Zero. While a string, string.empty is good as a base.
That allows whatever operation which may blindly reflect off of the property, it can determine what its true property type is and access it accordingly.
So assigning 0 to a string makes no sense in identifying that the property is a string which 0 identifies it as an integer. So the int as string is setting up a future runtime failures when objects try to assign bindings, styles and other items to it.
I was reading ActionScript 3.0 Abstract Factory Design Pattern: Multiple Products and Factories, and I have the following,
private var busFactory:AbFactory;
busFactory=new BusinessFactory();
Both in BusinessFactory.as and in AbFactory.as there is no method with the same name as the class, only createProductA and createProductB. So, how could busFactory call the constructor with new BusinessFactory ?
The default constructors for both AbFactory and BusinessFactory (which the article shows inherits from AbFactory) are created by the compiler.
If you start to pass arguments to the BusinessFactory() constructor, the compiler will complain about an unexpected argument count. That's when you need to write the constructor yourself. But passing nothing means the default can be used.
Also the reason that you could set a AbFactory to a BusinessFactory means that they share the same heritage.
Hi and thanks in advance,
I have a custom class being constructed from my main class. In the custom class it has another custom class that is passed in as a parameter. I would like to strictly type the parameter variable but when I do, 'the type is not a compile type constant etc'.
This, I understand, is because the custom class used as a parameter has not yet been constructed.
It all works when I use the variable type ( * ) to type the parameter.
I suspect this is a design flaw, in that I am using an incorrect design pattern. It is actually hand-me-down code, having received a large project from someone else who is not entirely familiar with oop concepts and design patterns.
I have considered using a dummy constructor for the parametered class in my main class but the passed in class also takes a custom class (itself with a parametered constructor). I am considering using ... (rest) so that the custom classes' parameters are optional.
Is there any other way to control the order of construction of classes? Would the rest variables work?
Thanks
(edit)
in main.as within the constructor or another function
var parameter1:customclass2;
customclass1(parameter1);
in customclass1 constructor:
public function customclass1(parameter1:customclass2)
{
....
Flash complains that the compiled type cannot be found when I use the data type customclass 2 in the paramater. It does not complain when I use the variable data type * or leave out the data type (which then defaults to * anyway). I reason that this is because customclass2 has not yet been constructed and is therefore not available to the compiler.
Alternatively, I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
There are over 10,000 lines of code and the whole thing works very well. I am rewriting simply to optimise for the compiler - strict data typing, error handling, etc. If I find a situation where inheritance etc is available as an option then I'll use it but it is already divided into classes (at least in the main part). It is simply for my own peace of mind and to maintain a policy of strict data typing so that compiler optimization works more efficiently.
thnx
I have not added the path of customclass2 to the compiler but I am fairly certain I have ruled this out.
So if you don't have the class written anywhere what can the compiler do ? It is going to choke of course. You either have to write the CustomClass class file or just use "thing:Object" or "thing:Asteriks". It's not going to complain when you use the "*" class type because it could be anything an array, string, a previously declared class. But when you specify something that doesn't exists it will just choke, regardless of the order the parameters are declared in.