sorry about title since i couldn't find a better one so any edit on that will be appreciated.
consider these classes :
public interface GlobalDashlet {
public Collection<? extends GlobalDashletSetting> getSettings();
public void setSettings(Collection<? extends GlobalDashletSetting> settings);
}
public class Dashlet implements GlobalDashlet {
private Collection<DashletSetting> settings;
public Collection<DashletSetting> getSettings(){
return settings;
}
//This Wont Work
public void setSettings(Collection<DashletSetting> settings) {
this.settings = settings;
}
//This Will Work
public Collection<DashletSetting> getSettings(){
return settings;
}
}
public class DashletSetting implements GlobalDashletSetting {
}
Why overriding the setter method(i mean the way that i have done) wont work (the dashlet class complains about the unimplemented method) but overriding the getter method works?
how can i fix it? i need to be able to implement setter methods too (like the way that i have override the getter methods) because i have to serillize the Dashlet class with jackson mapper and Jackson can not determine the actual type of and object at run time without additional information on super classes.
The reason is that return types may be covariant.
You can always return a more specific type (i.e. a subtype) when overriding a method. A more comprehensible example is the following:
class NumberProvider {
Number getNumber() { return 1.23; }
}
class IntegerProvider extends NumberProvider {
// Returning a more specific type when overriding:
#Override
Integer getNumber() { return 42; }
}
The type Collection<DashletSetting> is a proper subtype of Collection<? extends GlobalDashletSetting>. See the section about Which super-subtype relationships exist among instantiations of generic types? in the Generics FAQ.
For the setter, this does not work. The short reason why it does not work is: It is not type safe. An example of where the type safety is violated is easy to find, although it may seem a bit contrived at the first glance:
// This is the interface as it was defined:
public interface GlobalDashlet {
public void setSettings(Collection<? extends GlobalDashletSetting> settings);
}
public class Dashlet implements GlobalDashlet {
// Assume this was working:
public void setSettings(Collection<DashletSetting> settings) {
// Then you could add a "DashletSetting" here:
settings.add(new DashletSetting());
}
}
// But someone who CALLED this method may not have given it
// a Collection<DashletSetting>, but maybe a collection
// like Collection<SpecialGlobalDashletSetting>:
Collection<SpecialGlobalDashletSetting> settings = ...;
GlobalDashlet dashlet = new Dashlet();
// Based on the method signature that was defined in the interface,
// this would be possible:
dashlet.setSettings(settings);
// Now, the "settings" collection WOULD contain a simple "DashletSetting",
// although it should only contain "SpecialGlobalDashletSetting" instances
// This would cause a ClassCastException sooner or later
The example may look a bit confusing. Again, it's more intuitive with the "simple" types like Number and Integer, but it boils down to the same problem: If a more specific type was allowed for the setter method, then the type safety may be violated.
Because overrided method can not restrict the scope of input variable. Original method can accept anything which extends GlobalDashletSetting class but, but overriden method isrestricting to only one subclass of GlobalDashletSetting class
Because it has different signatures.
Collection<DashletSetting> is not Collection<? extends GlobalDashletSetting>
you need to override the exact signature, not part of it.
if you have method that takes Object, you cant override it with method that takes String even the String extends Object
in youre case, Collection<DashletSetting> and Collection<? extends GlobalDashletSetting> are actually different classes, you have to override with the same class.
the getter is working since it has the same signature (same method name and no params), thats not the case in the setter
Related
Ok, I'll try to explain this as cleanly as I can.
I've created a generic abstract controller class that has a method hasCreatePermissions that looks something like this:
public abstract class ApplicationController<
AppEntity extends ApplicationEntity,
AppService extends ApplicationService<AppEntity>,
DTOManager extends ApplicationDTOManager
> {
// Other methods, properties, etc...
public boolean hasCreatePermissions(DTOManager.CreationRequest requestBody, Optional<UUID> requestingUser) {
return false;
}
}
Essentially, I want any class that overrides this method to be able to use its own DTOManager class as the parameter when it overrides this method.
The generic ApplicationDTOManager class looks like
public abstract class ApplicationDTOManager {
public abstract class CreationRequest {}
public abstract class CreationResponse {}
}
and any class that inherits ApplicationDTOManager can add classes that extend CreationRequest and CreationResponse for their own implementation of respective DTOs.
However, lets say I try to extend it with a UserResource class (assume UserDTOManager exists with an implementation for CreationRequest):
#RestController
public class UserResource extends ApplicationController<
User,
UserService<User>,
UserDTOManager
> {
#Override
public boolean hasCreatePermissions(UserDTOManager.CreationRequest requestBody, Optional<UUID> requestingUser) {
// Stuff
}
}
I'm told that this does not override any super class methods. Why? Is there any way to achieve this as I did not want to pass too many generics to my ApplicationController class, but also cannot have a constructor.
class ApplicationController<
AppEntity extends ApplicationEntity,
No, stop right there. This is declaring a type variable with the bound rules: "Must be either ApplicationEntity or any subtype thereof" and you named it AppEntity. This is going to make your head go in circles when you read the code later, 'I keep confusing reified types with type variables' comprises 95% of all confusion about generics. I know it seems unreadable, but there really is just only one way to go about it, and that is to use single capital letters for all your type vars. So let's fix that right now:
public abstract class ApplicationController<
E extends ApplicationEntity,
S extends ApplicationService<E>,
M extends ApplicationDTOManager> {
Which then immediately lets us see a big problem in the next line:
public boolean hasCreatePermissions(M.CreationRequest requestBody) {}
Of course that can't work. M is a type variable, at compile time the compiler has no idea what type it is. It could be bound to some type that doesn't even exist yet right now. You can't ask for a reified inner type on a type variable. You can of course simply talk about ApplicationDTOManager.CreationRequest and that's presumably what you want.
Alternatively, you're thinking that subtypes of ApplicationDTOManager may also want to subclass ApplicationDTOManager.CreationRequest. This is possible, but then all ApplicationDTOManager types need to carry their associated CreationRequest type as a type variable. We thus fix a few things:
public class ApplicationDTOManager<R extends ApplicationDTOManager.CreationRequest> {
public static class CreationRequest {}
}
You may have a non-static inner class named CreationRequest. I'm going to stop you again on that - non-static inners have an invisible inner field of their outer's type, and combining that invisible voodoo magic with generics just doesn't work. Don't do it. You can explicitly make that field if you must have it, and make a constructor that takes it. This is what javac generates for you if you don't add static to your inner classes. But by making it explicit, you take control of the generics, which you have to here, and avoid confusion which given the nature of the question seems pertinent.
I'm told that this does not override any super class methods. Why?
Java's method names include all their erased types. The name of this method:
class List<T extends Number> {
int hello(String name, boolean[] hi, T arg) throws SQLException {}
}
is, as far as the JVM is concerned, hello(Ljava/lang/String;[ZLjava/lang/Number;)I.
Yeah, no, really. javap -c -v a class file and you'll see it. (I is integer, [ is array, Z is boolean, and Ltxt; encodes ref type names in JVM style, e.g. with slashes and dollars instead of dots). It's written name(params)ret.
If you then subtype something and introduce a method whose erased JVM name is identical, you're overriding. If you don't, it is not an override. Merely an overload. Overrides are dynamically dispatched. But overloads are not - The names are all linked up at compile time. However, for any given 'JVM method name', the lookup is done dynamically based on the receiver type. In other words:
class Fruit {
void hi(Fruit f) { System.out.println("Fruit Fruit"); }
void hi(Apple a) { System.out.println("Fruit Apple"); }
}
class Apple extends Fruit {
void hi(Fruit f) { System.out.println("Apple Fruit"); }
void hi(Apple a) { System.out.println("Apple Apple"); }
}
Fruit f = new Fruit();
Fruit a = new Apple();
a.hi(a);
Will print Apple Fruit. You'd think it should print Apple Apple perhaps - we are calling apple's hi passing an apple, no? But the invocation a.hi(a) is invoking the method named hi(Lfruit;)V (because the type of a is Fruit). The receiver variable (a) has compile time type Fruit, but its real type is Apple. So, which of the hi(Lfruit;)V methods is chosen is done with dynamic dispatch - you get apple's hi(Fruit). Deciding between going with hi(Fruit) and hi(Apple) is done by the compiler only. Given that the type of the expression a is Fruit, you get hi(Fruit). The fact that if you resolve this expression, you get an object whose .getClass() returns Apple.class, doesn't change this.
Hence, what you wrote, does not override. Different name, even if you erase.
Toss generics in the mix and it gets funky. But you can do this.
public abstract class ApplicationDTOManager<I extends CreationRequest, O extends CreationResponse> {
public abstract static class CreationRequest {}
public abstract static class CreationResponse {}
}
public abstract class ApplicationController<
E extends ApplicationEntity,
S extends ApplicationService<AppEntity>,
I extends CreationRequest,
O extends CreationResponse,
M extends ApplicationDTOManager<I, O>
>
// heck that's probably too many, at some point generics aren't worth it
{
public abstract boolean hasCreatePermissions(I requestBody);
}
#RestController
public class UserResource extends ApplicationController<
User,
// UserService<User>, // this seems wrong!
UserService, // UserService should extends ApplicationService<User>
UserDTOManager.CreationRequest,
UserDTOManager.CreationResponse,
UserDTOManager> {
#Override
public boolean hasCreatePermissions(UserDTOManager.CreationRequest requestBody, Optional<UUID> requestingUser) {
// Stuff
}
}
Not sure all this is worth the pain, but, if you insist on linking all this together with generics, the above is the only way. You cannot express the notion 'has an inner type that is a subtype of CreationRequest' is a generics bound.
If you override a method you cannot have a different signature, If the method you override requires a DTOManager.CreateRequest you cannot use a child class within the override method.
You have to "support" all types of input that the parent method could take.
I believe that you need this because the permission validation relies on methods or fields of the child class. If so you should implement it inside the child class.
I've a use case :
inteface A{
get(EnumSet<?> fetchModes);
}
class B implements A{
//Here FetchMode is an enum
get(EnumSet<FetchMode> fetchMode){
//Some logic here
}
}
But it's throwing compile time error :
Method get of class B has the same erasure as get(EnumSet fetchMode) of type A but doesn't override it.
I had read that Enums cannot be generic but is there any way to implement this usecase ?
(Basically want the EnumSet to be generic and different implementations can pass different Enums)
A method can override another if the argument types match exactly, but yours doesn't. Eventhough EnumSet<FetchMode> is a subtype of EnumSet<?>, they are not exactly the same. You are not overriding the super class method get(EnumSet<?> fetchModes); in your subclass, rather you are overloading it with a different parameter type. Both of these has the same signature due to erasure when you inspect or decompile the bytecode which is get(EnumSet fetchModes) and your compiler starts complaining.
This is covered in JLS §8.4.8.1:
A class cannot have two member methods with the same name and type
erasure
A naive attempt at fixing the problem is to change the parameter type such that it is compatible with that of the super class, overriding the method properly in your sub class.
#Override
public void get(EnumSet<?> fetchModes) {
}
Though this fixes the compiler error after a fashion, it is still not elegant since it allows your EnumSet to store any Object. But ideally you may want it to store only some subtype of Enum. This idiom supports that.
What you have to do is declare a generic interface with bounded type parameter and then implement it by overriding the method properly as shown below.
public interface A<E extends Enum<E>> {
void get(EnumSet<E> fetchModes);
}
public class B implements A<FetchMode> {
#Override
public void get(EnumSet<FetchMode> fetchModes) {
}
}
try this you have to make the generic type extends Enum:
public class B implements A<FetchMode> {
//Here FetchMode is an enum
public void get(EnumSet<FetchMode> fetchMode){
//Some logic here
}
}
}
interface A<T extends Enum<T>> {
void get(EnumSet<T> fetchModes);
}
I have this method in a service AbstractClass:
public <E extends EntityFilter> Specification<T> getSpecifications(E entityFilter) {
return null;
}
Then I have an implementation for EntityFilter too:
public class UserEvaluationFilter implements EntityFilter {
#Getter
#Setter
private String evaluator;
}
And I want to override the AbstractClass in my serviceClass (which extends the controller AbstractClass) method like this:
#Override
public Specification<UserEvaluation> getSpecifications(UserEvaluationFilter filter) {
return doStuff();
}
The compiler says that this is not overriding any method of my AbstractClass.
What's wrong?
The method signature you have declared in the abstrct class says that the method should accept any subclass of EntityFilter as that parameter.
Actually, the type variable is redundant there: you may as well just declare it as:
public Specification<T> getSpecification(EntityFilter entityFilter)
What you're trying to do in your subclasses is to make the parameter type more specific than EntityFilter; but this is forbidden by the Liskov Subtitution Principle, which says that subclasses must be:
No more specific in the parameters they accept;
No more general in the values they return.
As such, the method you are trying to declare in the subclass doesn't actually override the method in the supertype, so it is forbidden.
To deal with this, you need to make the filter type a class-level type variable:
class AbstractClass<T, E extends EntityFilter> {
public Specification<T> getSpecifications(E entityFilter) {
return null;
}
}
When defining something like this method:
class State {
public void addOperator(Operator<? extends State> op) {
}
}
Is there any way to define it in this way:
class State {
public void addOperator(Operator<? extends this.getClass()> op) {
}
}
So that any class inherting from State forces all passed in value to conform to its class-type.
I know that the above wont work, but is there anyway to force a generic wild-card to at least match the current classes type?
You already accepted an answer that claims your desired constraint can't be expressed in Java. If I understand the requirements correctly, the following solution comes close.
// You didn't flesh out what an operator does or provides,
// so I'll just make something up.
interface Operator<T> {
void apply(T arg);
}
// Request that a derived type provide its own type as a type
// parameter, per the Curiously Recurring Template Pattern (CRTP).
abstract class State<T extends State> {
public void addOperator(Operator<? extends T> op) {
final PrintStream s = System.out;
s.print("Received an operator of concrete type ");
s.print(op.getClass().getName());
s.println('.');
}
}
final class DerivedState extends State<DerivedState> {
}
public class Driver {
public static void main(String[] args) {
DerivedState ds = new DerivedState();
ds.addOperator(new Operator<DerivedState>() {
// ...
});
// And the following will not compile:
ds.addOperator(new Operator<Integer>() { /* ... */ });
}
}
Note that DerivedType's apply() method will only accept an Operator argument whose type parameter is DerivedType—or some type derived from DerivedType, but since DerivedType is final, no other such types exist.
What we can't do—which may be what Chris was alluding to—is mandate that the type parameter provided to State is in fact the derived type itself. We can't prevent the following definition, where one class supplies another as the type parameter for State:
final class AnotherDerivedState extends State<DerivedState> {
}
Here, one could call AnotherDerivedState#addOperator() with an Operator<DerivedState>, which is obviously not of type Operator<AnotherDerivedState>.
You can't prevent someone from deriving from State "incorrectly", but if you assume that people will follow the intended derivation pattern, you can help them use the rest of your library safely.
A subclass can be used instead of the superclass at any time because of the inclusion polymorphism.
Try writing
State.class
to get the Class object of State.
class State {
public void addOperator(Operator<? extends State.class> op) {
}
}
Although I am not sure that Class object inherit among them, they use generics, Class<T>.
So let's say we have class Base, and class Derived extends Base.
Class<Derived> probably does extends Class<Base>.
Instead, this scenario looks more promising
class State {
public void addOperator(Operator<Class<? extends State>> op) {
}
}
This question already has answers here:
Java generics type erasure: when and what happens?
(7 answers)
Closed 7 years ago.
I am trying to refactor some code, moving common code shared among a few caches to a base class. Here's a simplified concept of it:
public abstract class DBObject {
public void copyTo(DBObject other) {
other.setId(this.id);
}
}
public class Person extends DBObject {
public void copyTo(Person other) {
super.copyTo(other);
other.setName(this.name);
}
}
public class PersonCache extends Cache<Person> {
}
public abstract class Cache<T extends DBObject> {
Map<Long, T> idToCachedMap;
private Class<T> tObjectClass;
public void initialize() {
// does stuff to populate the idToCachedMap
}
public void updateCache(T cachedObjToUpdate) {
T cachedObj = idToCachedMap.get(cachedObjToUpdate.getId());
T oldCachedObj = tObjectClass.newInstance();;
cachedObj.copyTo(oldCachedObj); // PROBLEM HERE
// do other stuff...
}
}
The problem I'm running into is that when I call updateCache(Person) on a PersonCache, the copyTo methods that get invoked on the objects are that in DBObject, as opposed to the one in Person. As a result, only some of the data is actually copied (in this example case, the ID, but not the name).
It seems to me that since both cachedObj and oldCachedObjs are guaranteed to be Person objects if it's a PersonCache, the copyTo method that should be called is the one on the Person class.
I feel like there must be something about how generics work that I'm missing that is causing this behavior. I know if I override copyTo in the Person class to be a signature of copyTo(DBObject other) rather than copyTo(Person other) it then does call the copyTo on the person class - but that'd be a sloppy way to rewrite it and I think I'm missing something that might be cleaner.
You are not overwriting the copyTo method because you change the signature. And you invoke the method which exist in T.
Try this:
public abstract class DBObject<T extends DBObject> {
public void copyTo(T other) {
other.setId(this.id);
}
}
public class Person extends DBObject<Person> {
#Override
public void copyTo(Person other) {
super.copyTo(other);
other.setName(this.name);
}
}
You state It seems to me that since both cachedObj and oldCachedObjs are guaranteed to be Person objects if it's a PersonCache, the copyTo method that should be called is the one on the Person class.
Because of type erasure this is an incorrect assumption, at runtime all it knows is DBObject and obviously Object as well.
It knows nothing about T at runtime, it is erased and not available at runtime.
copyTo(T other) is not equivlent to copyTo(Person other) they are overloaded not overridden because of the type erasure. copyTo(T other) actually becomes copyTo(DBObject other) as your behavior is showing that it matches copyTo(DBObject other). This is the expected behavior.
Type Erasure behavior is very well documented here on SO and on the internet in general.