Can someone explain if I have a correct understanding of DeclareParents Spring annotation:
As per my understanding the below piece of code shall tells that all classes that implement interface Performance should also implement interface Rock as of now.
#DeclareParents(value = "com.example.demo.Performance.*+", defaultImpl = RockImpl.class)
public static Rock rock;
Here's simple example of Rock interface
public interface Rock {
void acDC();
}
However, when I try invoking method acDC on my class SongService which implements Performance - it doesn't work.
Appreciate your thoughts
The target type expression is incorrect.
A target type expression : com.example.demo.Performance.*+ would mean all implementors of interfaces within package com.example.demo.Performance
For all implementors of Performance interface to also implement Rock interface the expression should be as follows
#DeclareParents(value="com.example.demo.Performance+", defaultImpl=RockImpl.class)
public static Rock rock;
Reference : Introductions
AspectJ Type Patterns : Go through the subtype pattern
Fixing subtypes in introduction
Related
I'm using flink 1.11 with Scala and i have a question regarding the schema evolution using a POJO.
In the documentation is written, that POJOs are supported for state schema evolution (with some limitations).
Are Scala case clases also considered as POJO and therefore supported?
case class WordCount(word: String, count: Int)
Or have i to write something like this:
class WordCount(var word: String, var count: Int) {
def this() {
this(null, -1)
}
}
Case classes are not POJOs. In particular, they do not satisfy:
The class has a public no-argument constructor
All non-static, non-transient fields in the class (and all superclasses) are either public (and non-final) or have a public getter- and a setter- method that follows the Java beans naming conventions for getters and setters. (afaik case classes have final fields with getters in the generated JVM class)
You can implement all required things in a normal scala class but your IDE might not support you well. An option is to create your class in Java, let your IDE beanify it and convert it to scala (or use it directly).
There is also the option to create evolution support for case classes with a custom serializer. That will eventually be available by Flink. (You could also go ahead and contribute it).
I have written this methods in Kotlin and analysed the bytecode:
Situation 1
class A {
object b {
fun doSomething() {}
}
}
Situation 2
class A {
companion object b {
fun doSomething() {}
}
}
Situation 3
fun doSomething() {}
Bytecode Result
Situation 1: class Test$asb, public final doSomething()I
Situation 2: class Test$Companion, public final doSomething()I
Situation 3: class TestKt, public final static doSomething()I
My questions are:
I have an enum class, and I want to return an enum instace given an enum variable, for instance, findById (enum(id, color)). How would I do it? Companion Object? object?
It seems the only way to have a real static method is in package level, without class declaration. But that becomes a little bit too global. Is there any way to access it via: ClassName.staticMethod, staticMethod being really static.
Provide meaningfull examples of package declaration methods, companion object and object.
Context. I have been coding in Kotlin and I find it amazing. But sometimes I need to make a decision: for example, a heavy immutable property which in java I would declare as static final, but in Kotlin I find it hard to "find an equivalent".
If you have a function which performs some action closely related to a class but doesn't require a class instance, such as your findById example, you should put it in the companion object of the class.
If you want to expose a method as a static method to Java code, you can annotate it with the #JvmStatic annotation.
If a function does not require an instance of a class, then it is your design decision where to put it. Use package level if it is package-specific, use a class companion if it closely relets to the class (for example other classes in the package have similar functions).
Note that enum has several in-build properties and patterns:
enum class Colour(val value: Int) {
black(100), red(200), green(300)
}
fun colourById(id: Int) = Colour.values[id]
fun colourByValue(value: Int) = Colour.values.first {it.value == value}
fun colourByName(name: String) = Colour.valueOf(name)
I would suggest to develop voddan answer:
enum class Color {
RED,
BLUE,
GREEN;
companion object Utils {
fun findById(color: Color): Color {
return color;
}
}
}
And to test
#Test
fun testColor() {
println(Color.Utils.findById(Color.valueOf("RED")));
}
I'm new to Simple Framework, but I didn't find any advice about the use of the Getters/Setters knowing that they are not good in Android for performance point of view.
http://developer.android.com/training/articles/perf-tips.html#GettersSetters
Is there a way to not use them in Simple-Framework ?
My answer will probably be better with code samples, but pretty much. Whenever you are dealing with the field within the class, try to use the actual variable vs a method.
example. Within your class, you would use it like the following:
public class Foo
{
public Object bar; // This would be private if I was using a getter
public void doSomeStuff()
{
if(bar)
{
//work the bar
}
}
public Object getBar()
{
return bar;
}
}
Then externally, it would be used like this:
public class OtherFoo
{
public void somethingElse()
{
Foo ob = new Foo();
inner = ob.getBar();
}
}
External getters are a pro/con here, as they do break the performance rule stated, but they promote much better practices (preserved encapsulation, less nasty coupling, better maintainability, etc).
This all being said though, this performance tip can be taken with a grain of salt, since Android devices have gotten more and more powerful (in fact, I'm very certain this performance hit has almost been removed as of GingerBread).
My personal recommendation is to follow OOP principle, and use getters when possible, unless there is a serious performance issue.
is is possible to do end up with something like this:
ServiceChild (class) extends (or only partial implements) Service and overrides sayHello
Service (interface) implements hello,goodbye
Hello (has a mixin HelloMixin) has method sayHello
Goodbye (has a mixin GoodbyeMixin) has method sayGoodbye
I've tried doing the above using the concern approach in ServiceChild
public class ServiceChild extends ConcernOf<Service> implements Hello
{
#Override
public String sayHello() {
return "Rulle Pharfar";
}
}
However using this approach only the Hello implementation are detected by java and not the rest of the stuff from the Service class. So is there any other approach that would work?
I'm not sure I understand what you are trying to do, but a concern should more be seen as a wrapper around the original implementation of the class it is a concern of.
As the documentation states:
A concern is a stateless Fragment, shared between invocations, that acts as an interceptor of the call to the Mixin.
And would usually do this:
//Given interface MyStuff
#Mixins( MyStuff.Mixin.class )
#Concerns( MyStuffConcern.class )
public interface MyStuff
{
public void doStuff();
abstract class Mixin implements MyStuff
{
public void doStuff()
{
System.out.println( "Doing original stuff." );
}
}
}
public class MyStuffConcern extends ConcernOf<MyStuff>
implements MyStuff
{
public void doStuff()
{
// if I want to do anything before going down the call chain I'll do it here
System.out.println( "Doing stuff before original." );
// calling the next concern or actual implementation
next.doStuff();
// anything to do after calling down the call chain - here is the place for it
System.out.println( "Doing stuff after original." );
}
}
But nevertheless if you have a concern on a interface you should also implement said interface:
public abstract class ServiceChild extends ConcernOf<Service> implements Service
{
public String sayHello()
{
return "Rulle Pharfar";
}
}
Hope this helped.
I also don't fully understand the question.
As Arvice says, Concerns are the equivalent of around-advice in AOP, with much more precise pointcut semantics. Although it is technically correct that a concern 'wraps' the underlying concerns/mixins, I prefer to not thinking of it as a 'wrapper' but an 'interceptor'. It is the incoming call that is handled. Conceptually slightly different, and it may not work for everyone.
It is also possible that both Concerns (stateless) and Mixins (stateful) implements only a subset of the methods in the interface they override, simply by making the class 'abstract'. Qi4j will fill in the missing (and unused) method calls. And any combination may be used.
Further, well implemented concerns should call the 'next', because they should be unaware of their actual uses. If the concerns are expected to take care of the method call. There must be a Mixin for each composite type method, or assembly will fail.
So in short;
1. A Mixin implementation may implement zero (a.k.a private mixins), one or more methods of the composite type interface.
2. A Concern may implement one or more methods of the composite type interface.
It is also interesting to note that when a class (mixin or concern) calls one of its own methods that are in the composite type interface, the call will not be intra-class, but call the composite from the outside, so the entire call stack is invoked, to ensure that an internal call and an external call are identical in results. Patterns exists if this needs to be bypassed.
we have a nasty (or maybe a trivial?) issue.
There is a WPF control. It has 2 interfaces, the main and one for automated testing purpose. Defined this way:
[ComVisible(true)]
[Guid("xxx")]
public interface IXXXXXTest
{
[DispId(1)]
void Test1(int index);
}
[ComVisible(true)]
public interface IXXXXX
{
void Main1(index);
}
[ComVisible(true)]
[Guid("xxx")]
ClassInterface(ClassInterfaceType.None)]
public partial class XXXXX_WPF_CONTROL : UserControl,
IXXXXX,
IXXXXXTest
{
...
}
Now we are trying to reach it from VBS.
Try 1)
Set Ctrl = GetControl(...) <---- this is ok
Ctrl.Test1(0) <---- Object doesn't support this property or method: 'Ctrl.Test1'
Set Ctrl = GetControl(...) <---- this is ok
Ctrl.Main1(0) <---- this is ok
So it works fine for the "main" interface but for the test interface.
This seems ok(?), because as far as I know VBS reaches the "main" interface only via IDispatch if there is no IDispatchEx. So I added a property to the IXXXXX to get the test interface.
[ComVisible(true)]
public interface IXXXXX
{
void Main1(index);
IXXXXXTest Test { get;}
}
....
public IXXXXXTest Test
{
get { return this as IXXXXXTest; }
}
Great, so now I can reach this IXXXXTest interface via the "main" interface.
Try 2)
VBS:
Set Ctrl = GetControl(...) <---- this is ok
Set CtrlTest = Ctrl.Test <----- this is ok
CtrlTest.Test1(0) <---- Object doesn't support this property or method: 'CtrlTest.Test1'
:(
Note that, for an other .NET control of us the "Try1" works, without any trick!
So probably due to the WPF something different?
Also, changing the
ClassInterface(ClassInterfaceType.None)]
into anything else (AutoDispatch / AutoDual), or leaving it makes the WPF control unusable.
Besides that this is also how it should be by this article: Is it possible to package WPF window as COM Object
Do you have any idea what could be the problem?
Thank much in advance!
Scripting languages can only use the default interface on a class. You've got more than one so at least one of them will not be usable. And method names may be renamed if they conflict with other declarations. I'd assume you obfuscated the real names in your question so hard to diagnose such a renaming happening from what you posted.
Best thing to do is to temporarily apply the [InterfaceType(ComInterfaceType.InterfaceIsDual)] attribute on your interface types. Which allows you to generate a type library with Tlbexp.exe which you can then view with the OleView.exe utility, File + View Typelib command. You'll see the exact names of the methods and you'll see which interface is the [default] one on the coclass. From there you should have little trouble modifying your declarations so they'll work in a scripting language.