How to apply #OneToMany on super class getter method in multiple subclasses with different target entity - eclipselink

Stack
I'm using JPA2.0 with Eclipselink 2.6.3 and Spring 4(JTA).
Problem
I'm trying to override the class A attribute with #OneToMany mapping in class B and class C (which is similar to class B ) so that I can change the target entity to class X and Z respectively while fetching results for class B.
Class A has SINGLE_TABLE inheritance and class B & C are discriminator classes which is maintained by #classExtractor depending on some field value in class A.
Class Z has TABLE_PER_CLASS inheritance and class X & Y extends class Z with same table (just a hack for inheritance to avoid DTYPE).
Expected Result
When I query on class B or Class C and fetch getZList() then I should be able to see class X and Y type objects as mentioned in targetEntity in #OneToMany mapping in class B & C
I tried overriding the getter of class A in subclasses like below but the list is always empty.
Class A
#Entity
#Table(name="TABLE_A")
#Customizer(ACustomizer.class)
#Inheritance(strategy=InheritanceType.SINGLE_TABLE)
#ClassExtractor(AExtractor.class)
#InstantiationCopyPolicy
#Cacheable
#Cache( alwaysRefresh=true,
refreshOnlyIfNewer=true,
expiry=300000,
coordinationType = CacheCoordinationType.SEND_NEW_OBJECTS_WITH_CHANGES)
public class A implements Serializable {
#Column(name="ABC")
private String abc;
#Transient
private List zlist= new ArrayList<>();
}
Class B
#Entity
public class B extends A{
//problem is here...this mappping doesn't populate super class object
#Access(AccessType.PROPERTY)
#OneToMany(cascade=CascadeType.ALL, mappedBy="class A", targetEntity=Z.class)
#PrivateOwned
public List getZList() {
return super.getZList();
}
}
Class Z
#Entity
#Table(name="TABLE_Z")
#Customizer(ZCustomizer.class)
#Inheritance(strategy=InheritanceType.TABLE_PER_CLASS)
public class Z{
//some fields
//and #oneToOne mapped with class A
}
class X
#Table(name="TABLE_Z")
#Entity
public class X extends Z{
//some fields
}

Related

UML class diagram relation with mother class if every child class uses the same thing

I have two questions:
I have a Singleton class with a property Layout that I use in creating child objects of an abstract class (example below). The abstract class has an abstract method where the layout file is given as a variable. Do I connect that Singleton class to the abstract class or each child? The following example is written using pseudo-code:
public class SingletonClass
{
public static Instance;
public var[,] Layout;
}
public abstract class AbstractClass
{
public abstract void DoSomething(var[,] Layout);
}
public class ClassA : AbstractClass
{
public override void DoSomething(var[,] Layout) { some code }
}
public class ClassB : AbstractClass
{
public override void DoSomething(var[,] Layout) { some other code }
}
Is it even needed, or "cleaner", to give the Layout as variable in the method, or is it ok to just call Layout from the singleton class?
The following UML is an equivalent of your code
under the following assumptions: Instance and Layout are assumed to be attributes of analogous classes.
SingletonClass has two owned attributes (denoted by the big dots): public layout of type Layout and instance of type AbstractClass (it's abstract, hence the italics). The latter will later hold either an instance of the concrete ClassA or ClassB.
Whether or not the design is ok depends. Basically there's nothing wrong with this.

Duplicate fields in data classes that extend other (sealed) classes?

When a data class extends a sealed class containing a non-abstract open val property, the generated child data class contains private fields that duplicate the private fields of the parent class.
sealed class Foo(open val field1: String? = null)
data class Bar(override val field1: String? = null) : Foo(field1)
Output from javap -p Foo.class:
public abstract class com.example.Foo {
private final java.lang.String field1;
public java.lang.String getField1();
private com.example.Foo(java.lang.String);
com.example.Foo(java.lang.String, int, kotlin.jvm.internal.DefaultConstructorMarker);
public com.example.Foo(java.lang.String, kotlin.jvm.internal.DefaultConstructorMarker);
}
And javap -p Bar.class:
public final class com.example.Bar extends com.example.Foo {
private final java.lang.String field1;
public java.lang.String getField1();
public com.example.Bar(java.lang.String);
public com.example.Bar(java.lang.String, int, kotlin.jvm.internal.DefaultConstructorMarker);
public com.example.Bar();
public final java.lang.String component1();
public final com.example.Bar copy(java.lang.String);
public static com.example.Bar copy$default(com.example.Bar, java.lang.String, int, java.lang.Object);
public java.lang.String toString();
public int hashCode();
public boolean equals(java.lang.Object);
}
The bytecode for Bar.class contains its own private field field1; the field in the parent class does not appear to be re-used by the child class.
When using frameworks that set fields using reflection, which field will be set? Why is the field in the parent class not re-used by the child class? Is there a way to change the visibility of the field in the parent class to protected so it can be re-used by the child class?
In that caseBar holds the field indeed twice. Two alternatives to have a single field:
sealed class Foo(val field1: String?)
data class Bar(private val hiddenField1: String? = null) : Foo(hiddenField1)
or
sealed class Foo {
abstract val field1: String?
}
data class Bar(override val field1: String? = null) : Foo()
The field is not reused because you declared a separate property, which has its own backing field. If you want to reuse the field, change your code to:
sealed class Foo(val field1: String? = null)
data class Bar(field1: String? = null) : Foo(field1)
When using frameworks that set fields using reflection, which field will be set?
It depends on the class you use. Foo::class.java.getDeclaredField() or Bar::class.java.getDeclaredField().
See:
https://programming.guide/java/accessing-private-fields-of-superclass-through-reflection.html
What is the difference between getFields and getDeclaredFields in Java reflection
Why is the field in the parent class not re-used by the child class?
Why should it? You defined a field-backed property field1 in both classes. Both fields will exist but getField1() method is overridden by child class to return child class' field.
Is there a way to change the visibility of the field in the parent class to protected so it can be re-used by the child class?
Fields of lateinit properties have the same visibility as the getters. But I'm not sure that's what you want.
How about this?
sealed class Foo {
abstract val field1: String?
}
data class Bar(override val field1: String? = null) : Foo()
See discussion here: https://twitter.com/orangy/status/1033067930248867840

UML - What is relationship when a class instance is declared in method

I would like to know how the following relationship is called in UML and how it is marked on a class diagram ? Is that a constrained dependency relationship, marked by dotted arrow ?
public class A {}
public class B
{
public foo()
{
A a = new A();
}
}
Yes, exactly. It's
B - - - > A

How Dynamic binding works in java

I am beginner to java and trying to understand Dynamic binding
when i come across this below example,
class Animal{}
class Dog extends Animal{
public static void main(String args[]){
Dog d1=new Dog();
}
}
Here d1 is an instance of Dog class, but it is also an instance of
Animal.
here what i dont understand is,How d1 is also become an instance of Animal class when you do inherit in java.
Can someone explain this concept.
Why they say "d1 is also an instance of Animal", what they really mean is that d1 can be used like an instance of Animal. You can use d1 to do everything an instance of Animal can do, including but not limited to:
Passing d1 to an Animal parameter
public static void method(Animal a) { ... }
...
method(d1); // compiles!
Assigning d1 to a variable of type Animal
Animal myAnimal = d1;
Calling methods that is in the Animal class
d1.move();
The reason why you can do all these is all because of that extends keyword.
Dynamic binding occurs during the run time.It is also known as Late binding as it occurs in the run time.The type of the object cannot be determined during the compile time.The parent class and the child class has the same method but the method is overridden.
Simple example to understand Dynamic binding
class Animal{
void eat(){
System.out.println("Animal is Eating");
}
}
class Dog extends Animal{
void eat(){
System.out.println("Dog is Eating");
}
}
class Test{
public static void main(String [] args){
Animal obj = new Animal();
obj.eat(); // displays Animal is Eating
Animal obj1 = new Dog(); // reference of the parent class
obj1.eat(); // displays Dog is Eating
}
}

Base class and derived class

I have a question, I have a base class and an another class which derived from the base class. Can we access derived class in the base class.
Thanks in advance
You can access the code in the derived class from the base class code, but only from within an object which is actually a derived class object, and then only if the methods involved are virtual methods.
If you have an object which is itself an instance of the base class, then from within that instance you cannot see derived class code from the base class .
example
public class Baseclass
{
public void Foo()
{
Bar();
}
public virtual void Bar()
{
print("I'm a BaseClass");
}
}
public classs Derived: BaseClass
{
public override void Bar()
{
print("I'm a Derived Class");
}
}
Main()
{
var b = new BaseClass();
x.Foo() // prints "I'm a BaseClass"
// This Foo() calls Bar() in base class
var d = new Derived();
d.Foo() // prints "I'm a Derived Class"
// in above, the code for Foo() (in BaseClass)
// is accessing Bar() in derived class
}
No you can not. If you happen to know the an object declared as the Base class is actually the derived class, you can cast it. But within the base class you can not access the derived class's members.
There are a lot of ways that a base class can access members of a derived class (depending on programming language), but generally it is considered a design smell.
Instead, you usually want the base class to only directly access its own members, and allow derived classes to override methods.