Using Hibernate Versioning in a middle class of a hierarchy - java

I want to use Hibernate Versioning in my application but I have a problem in a class hierarchy like this :
C extends B and B extends A.
I want to use version in Class B and I don’t need to use version in class A and I know when I use versioning in Class B automatically it will be effective in Class C.
I implement inheritance in hibernate with 'joined-subclass' and ‘Version’ tag is not defined for 'joined-subclass'. How can I use versioning in my class hierarchy?

You can't do this with joined-subclass, because, as you have already observed, it will apply to any further subclasses.
You'll probably have to use table-per-subclass to get what you want.

Related

Adding properties to abstract class which are already extending from that abstract class

I have an abstract class A. There are at least 10 other concrete classes that are extending from Abstract class A. Class C is one of those concrete classes. I have a requirement to add a property of type C to all those classes. The best way would have been to add that to class A so as to avoid code duplication. However since C is also extending from A, this would not be possible.
Is there any way to achieve the above?
Maybe consider using an Interface. Though java does not support multiple class inheritance, it does allow for multiple implementations of an interface. This way, you would be able to have the methods you need in C, can be stored in an interface, that way other classes that need that method, can inherit them from the interface, and also use the abstract class at the same time.

Caution while extending a class which is Serializable

I have a class A implementing Serializable and another class B extends A, but I want to use class B for XML binding, not for serialization.
Is there anything I should worry about?
Assuming you've implemented all of the Serializable methods in A, nope. You won't need to worry about implementing them, since that's already done. If there are any naming conflicts between XML binding and serialization, you can define the method in B and your XML binding library will call the methods for B, not those of A (i.e. polymorphism).
The only potential worry is a method that takes an argument of type Serializable -- if B, for whatever reason, shouldn't be (de)serialized, this is a problem. I doubt that this is a problem for you, if only because there are so few cases when it would apply.

detecting UML relationships from java source code

my program runs through source code easily enough and I can detect easy relationships such as implementation or inheritance using extends just by searching for where the class is defined. However, I'm a bit stuck with ideas on how to detect other relationships such as if a class has association or aggregation with another class.
So far I have tried parsing the code and looking for where other methods are called but I'm not sure of an exact code definition of these relationships.
Sorry if I am being unclear I can try and explain better if you don't understand just let me know in the comments.
Aggregation and composition both look like member variables in Java
e.g.
class MyClass {
private HerClass h;
}
MyClass HAS-A HerClass member - so that's composition or possible aggregation. You could tell the difference based on whether MyClass creates the HerClass - that would PROBABLY be composition.
Association is based on dependency. Why don't you use the imports to find out which classes are depended on? Or you could scan any use of type names in the code - the moment a type name is mentioned, there's a "uses" association.
The problem is that there is not any strict definition how to translate Java classes relations in associations, dependencies and aggregations. You should set the rules yourself, only check them against the UML standard.
I would advice the following :
UML Java
Dependency A->B Class A mentions class B
Association A->B Class A has reference {that can have reference} (it is recursive!} to class B
Composition A->B Class A has array or collection of B or of references to B AND
(black diamond) no other classes have instances of B or references to them,
either single or collective (arrays, collections)
Shared aggregation A->B Class A has array or collection of B or of references to B AND
(empty diamond) at least one other class has an instance of B or references to such,
either single or collective (arrays, collections)
If according to the last rule, you get two-sided shared aggregation A-B, it is forbidden. So, change it to two mutual shared aggregations.
Remember, that Association and Shared aggregation have NO strict definitions, only limitations.

How to explain multiple inheritance in Java [duplicate]

This question already has answers here:
Java : If A extends B and B extends Object, is that multiple inheritance
(11 answers)
Closed 8 years ago.
Actually the question was asking by one of the interviewer
Que: How can you say that java is not supporting multiple inheritance?
If Object class is a parent of all classes in java.
I have no answer of that question.
That means no clear idea about java concepts :-(
Ex:
if A extends B
And here A is already extending Object class. right?
Now how its works?
Please share your answers..
Multiple inheritance is about multiple-direct-inheritance.
A single class class can't have two immediate parent classes. It can have a grandparent class, though.
A extends B and B extends C, is not the same as A extends both B and C.
The reason this is disallowed is for simplicity when you have a case like:
A extends both B and C
B extends D
C extends D
If you had such a case, and then you had this code:
A a = new A();
a.someAbstractOrVirtualMethodOnD();
... are you talking about the B implementation of someAbstractOrVirtualMethodOnD(), or the C implementation of that same method? Which should get called? (Hint: there isn't a great answer)
So, Java bans it.
Note, you can get something much like multiple inheritance if you implement multiple interfaces. But since there is only one concrete implementation, there is no confusion as to what gets called.
On the top of all to keep the language design simple
And the example from the blog I follow regularly.
1)We have two classes B and C inheriting from A.
2)Assume that B and C are overriding an inherited method and they provide their own implementation.
3) Now D inherits from both B and C doing multiple inheritance. D should inherit that overridden method, which overridden method will be used? Will it be from B or C?
Here we have an ambiguity.
Any ways to overcome this we have interfaces and Multilevel inheritance.
Edit :
And here A is already extending Object class.
That is never called as Multiple inheritance.That is called Multi level inheritance.
In Multi level ,
Many classes are involved in inheritance, but one class extends only one. The lowest subclass can make use of all its super classes' contents.
Multiple inheritance means a single class can inherit from multiple classes. In other way, it can have multiple parent classes.
For Object class example cited by the interviewer, there are two possibilities:
The interviewer himself is confused about multiple parent class(multiple inheritance) and multiple child class.
Or he is trying to trick you using that question
A parent class can have many child classes and that does not relate to multiple inheritance.
Have a look at this StackOverflow answer: https://stackoverflow.com/a/9790475/2619912
Your class that extends that other class, but it extends Object, too, so you're still in one line of inheritance, not two.
This is a common misconception with Java.
The way multiple inheritance works (in C++ and Python) is something like this.
Parent1 Parent2 Parent3
| | |
_______________________
|
v
Child
It means that Child will inherit the attributes and methods from all the parents.
However, in Java, inheritance works like this.
Object
|
v
Child1
|
v
Grandchild
So, object is the superclass of all classes, but it is not the immediate parent of all classes. Java does, however provide a way to somewhat implement multiple inheritance by the way of Interfaces
Object
|
v
Child <--- Interface
|
v
Grandchild
Now, Grandchild will inherit methods from Child which, in turn is obligated to implement the methods defined in the interface [Unless it is an abstract class, but that is separate discussion altogether]
So, Object is the ancestor of all classes, but it is not the parent of all classes, and Java, therefore does not support multiple inheritance.
Multiple inheritance is where a single class can extend from multiple classes. That is not possible in java. See here: http://en.wikipedia.org/wiki/Multiple_inheritance
When you do class A extends B in Java, then A extends B only, and not Object. B in turn extends Object (or whatever else, which will eventually extend object)
The only resemblence of mutiple inheritance in java is Interfaces.
A class can implement multiple interfaces.
Object class is not an example of multiple inheritance. May be you misinterpreted the question.
The answer is Java supports multi-level inheritance but not multiple inheritance.
Please refer this : http://docs.oracle.com/javase/tutorial/java/IandI/subclasses.html
In case of Object class to other classes its not actually multiple inheritance ... As said , its where a single class can extend from multiple classes ..
A java class can only be a direct child of a single parent class. It can have a grandparent but no second parent.
It is like having a single biological mother. You cannot have more than one biological mothers, sure you can have a grandmother.
Let there be a class A and class B.
Now we define a class Derived.
Multiple Inheritance means: class Derived can inherit both class A and class B.
But this is not possible in Java. Hence it does not support Multiple Inheritance.
Que: How can you say that java is not supporting multiple inheritance? If Object class is a parent of all classes in java.
Object is ancestor of all classes (father, grandfather, great grandfather, etc.) but every class has only one father (if not specified, it's the Object class).
Multiple inheritance should allow a class to inherit multiple parent classes. But Java doesn't allow this since it might create Diamond problem
Regarding Object class being parent, and then having many classes in inheritance hierarchy, its termed as Multi level inheritance
Sidenote:
C# allows multiple inheritance by interface by allowing child to implement multiple parent type's methods separately even though they have same signature
First case: Suppose you create a class A without using inheritance. By default, it is derived from Object class.
Second case: Suppose you create the class B that extends class A. Class A contains all the fields from Object class, so class B will also contain them through inheritance. It is
class B extends A(which extends Object), so you could say that B is a subclass for A and also for Object.

Use annotation to specify which classes/interfaces should be generate javadoc?

I have a java program and want to generate javadoc for classes/interfaces. However, I just want to generate javadoc for a certain classes and interfaces. I just want to know if there is any way that I can add an annotation at the beginning of each class/interface to indicate that this class/interface should not be generated javadoc (something like #no-generate-javadoc)
Does anyone have ideas, please?
Thanks
Writing your own doclet is realtively straightforward and will give you exactly what you want. You can still delegate to the standard doclet, so your implementation only needs to include your specific changes.
The ExcludeDoclet would be a good starting point. It reads excluded classes from a file. You get excludes by annotation by calling the annotations() method on ClassDoc (actually it's base class, ProgramElementDoc) to fetch the annotations, and then check these against your desired exclude annotations. If desired, you could also do this recursively for superclasses and implemented interfaces,
Thanks for mentioning our tool - DocFlex/Javadoc
By the way, simply excluding classes and members isn't the whole story. The generated JavaDoc must look consistent after that.
For instance, suppose we have the following situation:
class C1 extends class C2
class C2 extends class C3
class C3 contains a public method m() -- which is supposed to be documented
Now, let's assume that the class C3 must be excluded from the documentation.
What will happen with the method m() ?
It should be shown in the documentation as declared in the class C2!
Then, for the class C1, m() must appear as inherited from the class C2
(rather than from the class C3, as it actually is in the code).
The same situation is with fields, which is actually even more complicated, because equally named fields not overload but shadow each other. For example
class C1 extends class C2
class C2 implements interface I
class C2 contains a private field F
interface I contains a public field F -- which might be documented
Let's assume the interface I must be excluded from the documentation.
What to do with the field I.F?
Actually, nothing! It shouldn't get in the documentation because it is shadowed by C2.F, which is private and, therefore, must be invisible.
Does simple tweaking (delegating) of the Standard Doclet solves such problems?
Our tool does!

Categories