I have 2 classes: A,B. And A extends from B.
In my aspect I'm trying to declare parents for A and B to implements Serializable.
But for some reason, only B implements Serializable and A doesn't.
(See the orange arrow that is only on B)
image
If I switch the order between those lines, now A implements Serializable, and B doesn't.
(See the orange arrow that is only on B)
image
Why this is happening?
How can I make both of them implements Serializable?
I'm working on Eclipse Luna 4.4.2 with AspectJ 1.8.7.
Since A extends B, A inherits all implemented interfaces of it's superclass B. The declaration declare parents: A implements Serializable; hence does nothing, since A already implements Serializable through B.
Related
What is the difference between sealed and internal in Kotlin? I have read Kotlin's documentation on sealed classes and visibility modifiers; however, it is still not clear to me when to use sealed vs. internal. Maybe someone could provide real-world code samples?
Sealed classes | Kotlin & Visibility modifiers | Kotlin resources.
sealed class will be visible in all modules, but extendable only in the same module. This means if you have this:
sealed class MyClass {} then you can do this in the same module:
class MyExtensionClass: MyClass() {}
But you can't do the same thing in another module. But you can still use both MyClass and MyExtensionClass in another module.
For example you can do this in another module:
val x: MyClass = MyExtensionClass()
You can't instantiate a sealed class directly neither in the same or another module. This means you can't do this nowhere:
val x = MyClass()
So sealed class is basically an abstract class which can only be implemented in the same module.
internal class can be used and extended in the same module just like a sealed class, but you can do neither in another module. So you can't even use or instantiate it in another module. Also you can directly instantiate an internal class as long as you are doing it in the same module.
So: Use sealed to better control extending something. For example you create a library and you want a class from this library to be used but not extended. Use internal if you wan't your class to be invisible to other modules (you create a library, but certain class in this library shouldn't even be directly compile time usable by libraries users)
A good use case for sealed class:
You build a library and have some abstract class or interface which has multiple different implementations, but you want to make sure the libraries user doesn't add its own implementations (you wan't to be in control of implementation details).
A good use case for internal class:
You have some interface and a factory that creates implementations, but you don't want the implementing class to be compile-time visible to libraries users. They just use the factory and don't need to worry about the implementation. They might build their own implementation though and therefor not use the factory you provided and this is OK.
These are not mutually exclusive. You can have an internal sealed class as well.
internal is about visibility, and sealed is about inheritance rules.
internal means the class type is only visible within the module. In other modules, you can't even mention the name of the type.
sealed means it is open (can be subclassed), but subclasses (or implementations if it's a sealed interface) can only be defined in the same module, and the compiler keeps track of an exhaustive list of all subclasses. Another rule is that you can't create anonymous subclasses of it (object: MySealedClass). The advantage of a sealed type is that the compiler knows when you've exhaustively checked a type in when statements, if/else chains, etc. It can also be used in a library to ensure that only known implementations of a class or interface are ever passed to it (prevent users from creating subclasses of something and passing them into the library).
Bonus:
Visibility modifier keywords: public, internal, private, protected
Inheritance modifier keywords: open, final, sealed
data and value also cause a class to be final implicitly as a side effect.
One of my POJO class is implementing an interface which extends Serializable
My doubt is, As we cant include serialVersionUID in interface class can it result in Cannot Marshal EJB parameters Exception?
You can not pass ,,an interface" as parameter of java method. You can only pass an instance of some class, that implements such interface. That class will be marked as Serializable due to abstraction hierarchy. The Serializable interface is a marker interface, and your implementation class will be serializable even if it does not declare the serialVersionUid attribute(However, it is strongly recommended that you do declare the serialVersionUID).
So to answer your question: as long as the particular instance you pass to your EJB method is marked as serializable it will be fine.
Let's say I have a Swing GUI that has to display a certain type of information in two different ways. From a design patterns perspective one would probably use the Strategy pattern here: create an interface that defines how the communication between the display component and the client works like this:
public interface Foo {
void showData(Data bar)
}
The real action is then done by different components that implement Foo and can be created and plugged in for doing the real work.
Now, what happens, if the real components are java.awt.Components? As I see it, it results in a mess of type casts because Component is a class. Let's assume an implementation like this one:
public class Baz extends Component implements Foo {
...
}
If I want to pass objects of class Baz around, the methods can either use "Component" as the parameter type or "Foo". The problem is that some methods need objects that are both Component and Foo (e.g. because they add the object to a JPanel and then supply the data calling the interface method showData()).
As I see it I have some choices to make this happen:
I can pass the reference as Component and cast to Foo. Before, I have to check that the reference is an instance of Foo and I have to handle situations where this requirement is not met. Another problem is that I have to communicate to clients of the method that the Component passed also has to implement Foo, which is awkward and error-prone.
I can do the same thing with Foo
I can add a method "Component getComponent()" to the Foo interface and the implementation would always return "this". This boilerplate method could be put into an abstract sub-class of Component. This solution means an interface method I don't want and an additional sub-class I don't need.
I can pass two references, one Component and one Foo reference to the same object. Internally, I'd have to make sure, though, that both references belong to the same object. And I have to deal with situations in which this requirement is not met.
I can use an abstract sub-class of Component and define the interface using abstract methods. This would allow me to pass references in a type-safe manner, but break with good OOP practices: keeping interfaces and implementations separate and also the interface segregation principle.
So, all of these solutions are merely workarounds. Is there any solution I'm missing? What should I do?
I would use the Strategy design pattern as you mentioned, but perhaps in a different context. The problem with trying to "shoe-horn" both Foo and Component into one class is that you could have combinations of implementations that would require duplicating code.
For example, imagine you have the following implementations of Component:
(Its been too long since Ive used Swing, these classes may not exist)
JPanel
JButton
JMenu
And you also had the following implementations of Foo
MyFoo
HisFoo
OurFoo
WhatTheFoo
And Imagine all the combinations of those: that's whats called a class explosion. This is the classic justification for the Strategy pattern.
I would create a sort of container class that uses a HAS-A relationship for each of the needed classes instead of using the IS-A relationship as follows:
(Im a c++ programmer, so you'll have to excuse the hybrid code :)
class ComponentFooHandler {
Component component_;
Foo fooImpl_;
inline Foo getFoo() {return fooImpl_;}
void setFoo(Foo f) {fooImpl_ = f;}
Component getComponent() {return component_;}
void setComponent(Component c) {component_ = c;}
void doAction() {
component_.someAction();
fooImpl_.anotherAction();
}
}
You would then have to create different implementations of Foo seperately. Then the Component and Foo implementations can be combined as needed with out having to duplicate Foo impl code. Notice also that you can call methods that like doAction() that can operate on both Foo and Component without knowing their details, similar to a Template Pattern.
To solve the issues with your original question:
When a Component is needed, call getComponent() on a handler instance
When a Foo is needed, call getFoo() on a handler instance
I would avoid creating methods that need both in one and split the method args into 2
Or just consider passing around a ComponentFooHandler
I am playing with this example http://scala.sygneca.com/code/remoteactors to learn how remote actors work in Scala (2.8.0). In particular I slightly modified how the messages send by the actors are defined as it follows:
sealed trait Event extends Serializable
case object Ping extends Event
case object Pong extends Event
case object Quit extends Event
and everything works as expected. Unfortunately if I define the events as case classes instead of case objects as in:
sealed trait Event extends Serializable
case class Ping extends Event
case class Pong extends Event
case class Quit extends Event
my example stop working. In more detail it seems that while case objects are serializable, case classes aren't. Indeed when I try to run my example with this last modification I get the following exception:
scala.actors.remote.DelegateActor#148cc8c: caught java.io.NotSerializableException: scalachat.remote.Ping$
java.io.NotSerializableException: scalachat.remote.Ping$
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at scala.actors.remote.JavaSerializer.serialize(JavaSerializer.scala:46)
at scala.actors.remote.NetKernel.namedSend(NetKernel.scala:38)
at scala.actors.remote.NetKernel.forward(NetKernel.scala:71)
at scala.actors.remote.DelegateActor$$anonfun$act$1$$anonfun$apply$1.apply(Proxy.scala:182)
at scala.actors.remote.DelegateActor$$anonfun$act$1$$anonfun$apply$1.apply(Proxy.scala:123)
at scala.actors.ReactorTask.run(ReactorTask.scala:34)
at scala.actors.ReactorTask.compute(ReactorTask.scala:66)
at scala.concurrent.forkjoin.RecursiveAction.exec(RecursiveAction.java:147)
at scala.concurrent.forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:422)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:340)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:325)
Is there a reason why case objects can be made serializable and case classes can't? Is there a way to make my example working with case classes either?
Edit: as suggested by Victor and confirmed by Aaron I am sending the companion object as message instead of the class. Moreover inspecting the compiled code with javap it appears evident that while the class is serializable:
public class scalachat.remote.Ping extends java.lang.Object implements scalachat.remote.Event,java.io.Serializable,scala.ScalaObject,scala.Product
the companion object is not:
public final class scalachat.remote.Ping$ extends scala.runtime.AbstractFunction0 implements scala.ScalaObject
Now the question is: how can I specify that I want to use the class instead of the companion object? I also added an empty couple of parenthesis when I send the message as suggested by Aaron like in:
pong ! Ping()
but nothing is changed. In the end I also added a fake parameter to the case class
case class Ping(i: Int) extends Event
sending the message as:
pong ! Ping(0)
but without experiencing any difference still. Any suggestion?
#serializable case class Foo
I was also surprised that case objects were serializable per default.
Edit: After reading the exception properly I suspect that:
You're trying to send the generated companion object of the case class over the wire, instead of an instance of the case class.
Case classes without parameters are meaningless and deprecated. And I see no Serializable in Scala, just serializable. Does it work if you fix these things?
I'm still learning ASP.NET and I often see code like this throughout parts of our framework:
Public MustInherit Class DBFileManager(Of F As IDBFile, FC As IDBFileContent, FT As IDBFileThumb)
Can anybody tell me what this means? Much thanks!
Its a generic. That means a DBFileManager can be created that acts on 3 classes that implement the 3 named Interfaces
see http://msdn.microsoft.com/en-us/library/w256ka79(VS.80).aspx for more information
To build on what #Jimmy said: It is also an Abstract Class, which means it acts as a base class - you can't use it directly, you must sub class it to use. That subclass must implement the 3 types in the class header.