Develop Reference

How to add a base class to a mosby MVPActivity?

I am looking for a way to add a base class to a mosby MVPActivity. Let me explain what i need.
Usually when using mosby we would declare an activity like this:
public class LoginActivity extends MVPActivity<LoginView, LoginPresenter> {
//...
}
but i would like to add a base class so that i can do the calls like this:
public class LoginActivity extends BaseActivity<LoginView, LoginPresenter> {
//...
}
and then BaseActivity would be like this :
abstract class BaseActivity<T, P> extends MvpActivity<T extends MvpView, P> {
}
but this is not working as the IDE at compile time has an error saying that "extends MvpView" has unexpected bounds.
So how can i add a base class to a mosby MVPActivity ?

You have to apply the generic parameters with your extended class definition and define it with the extension.
abstract class BaseActivity<V extends MvpView, P extends MvpPresenter<V>>
extends MvpActivity<V, P> { }

How to change java class generic type signature?

I 'll get straight to the point. Here is the problem
I have a class ClassA
public class ClassA<GENERICTYPE extends TypeA>
{
...
}
What I want to achieve is make the GENERICTYPE extend a new TypeB where TypeB extends TypeA
One possible solution is
public class ClassB<GENERICTYPE extends TypeB> extends ClassA<GENERICTYPE>
{
//emtpy
}
But doesn't seem to be the right approach.
Any suggestions?
If it makes any difference, I am using Spring 4.
Thanks
Nikos

It's the right idea, but not quite how you specify it:
public class ClassB<T extends TypeB> extends ClassA<T> {
}

Inherit generic type and force the <type>

Is it possible to inherit generic type and to force in the child class the type received?
Something like:
class A<GenericType>{}
class B extends A<GenericType>{}
Or:
class B <PreciseType> extends A <GenericType>{}
But where do I define the GenericType used in B?

Given
class A<T> {}
It depends on what you try to do, but both options are possible:
class B extends A<SomeType> {};
B bar = new B();
A<SomeType> foo = bar; //this is ok
and
class B<T> extends A<T>{}; //you could use a name different than T here if you want
B<SomeType> bar = new B<SomeType>();
A<SomeType> foo = bar; //this is ok too
But keep in mind that in the first case SomeType is an actual class (like String) and in the second case T is a generic type argument that needs to be instantiated when you declare/create objects of type B.
As a piece of advice: using generics in collections is easy and straightforward, but if you want to create your own generic classes you really need to understand them properly. There are a few important gotchas about their variance properties, so read the tutorial carefully and many times to master them.

Assuming A is declared as class A<T> {} and you want be to be specialised on String only for example, you can declare it as class B extends A<String>.
Example:
public class A<T> {
public T get() {
return someT;
}
}
public class B extends A<String> {
public String get() {
return "abcd";
}
}

class B extends A<GenericType>{}
This is possible. Your B class will be a new class that extends generic A class with specific class as parameter and B will not be a generic class.
class B <PreciseType> extends A <GenericType>{}
In this case you create a generic class B which has generic parameter PreciseType. This class B extends a specific version of A, but A's parameter doesn't depend on PreciseType.
If you want to create a generic class that has a parameter which is used in specification of parent class you can use the following:
class B <PreciseType> extends A <PreciseType>{}

Java generics - use same wildcard multiple times

I have a class declaration which uses generics and bounded wildcards:
class Factory<T extends Logic<? extends Entity>,
U extends DAO<? extends Entity>>
{
}
Basically its a generic factory, which takes a logic interface (T) and returns a configured implementation. In order to instantiate the logic, I take a appropriate DAO class implementing the DAO interface (U).
Both interfaces for logic and DAO are generic as well and take the type of the entity to work with as their type parameter. However, I want to constrain that further, so that DAO and Logic not only have a type parameter which extends Entity, but that they extend the same Entity. The result may look similiar to that:
class <X extends Entity> Factory<T extends Logic<X>,
U extends DAO<X>>
{
}
Can I achieve that with java generics?

Yes, you're close. Do it like this:
class Factory<X extends Entity,
T extends Logic<X>,
U extends DAO<X>>
{
}
Alternative
class Factory<T extends Logic<?>,
U extends DAO<?>>
{
// Here, the generic method parameter only requires X
// to be the same bound at method invocation. However,
// you will "lose" that information again when the
// Factory is returned.
public static <X extends Entity,
T extends Logic<X>,
U extends DAO<X>> Factory<T, U> createFactory(T logic, U dao)
{
return new Factory<T, U>(logic, dao);
}
}

Another approach could be to provide a wrapper (although that's not really elegant ;) ):
class Entity{}
interface Logic<T extends Entity> {}
interface DAO<T extends Entity> {}
interface DaoLogic<X extends Entity> {
DAO<X> getDAO();
Logic<X> getLogic();
}
class Factory<T extends DaoLogic<? extends Entity>> {}

Would the following work. X would be the "common" type, where Logic and DAO both would use this type.
public class Factory<X extends Entity, T extends Logic<X>, U extends DAO<X>>
{
}

Narrow a Java field type without making the enclosing class generic?

Is it possible to narrow the type of a field in a Java class without making the containing class itself generic?
The generic example would be something like this:
abstract class MyClass {
//...
}
interface MyInterface {
//...
}
class MyConcreteClass<T extends MyClass & MyInterface> {
private T value;
}
Is there any way to do the following:
class MyConcreteClass {
private MyClass & MyInterface value;
}
This is essentially equivalent to MyConcreteClass or the raw MyConcreteClass type. In my implementation the type parameter will vary over the lifetime of the object (cursed mutability! It is imposed upon me by JPA!) and so the type annotation seems somewhat superfluous.
EDIT -
There is an additional restriction I forgot to mention. We will also have this:
class SubA extends MyClass
class SubB extends MyClass
class SubC extends MyClass
class SubSubA extends SubA implements MyInterface
class SubSubB extends SubB implements MyInterface
class SubSubC extends SubC implements MyInterface
Thus, simply declaring an abstract subclass of MyClass that implements MyInterface is not a suitable solution.
Also, the ultimate field type must be a concrete type, rather than simply an interface representing the intersection, for the simple reason that JPA-persisted entites cannot be referenced by their interface types. That is, a persistent field in a JPA entity class must be of either a primitive type or a concrete entity type.

I have never come across a problem like that (and thus no elegant solution comes to mind :-)... however...
interface Fooable
{
}
abstract class MyClass
implements Fooable
{
}
interface MyInterface
extends Fooable
{
}
class MyConcreteClass
{
private Fooable value;
}

In such complicated cases you should hide classes behind interfaces.
Then you can define an explicit interface for the intersection, i.e. an interface that extends both the interface corresponding to MyClass and MyInterface, and letting the appropriate superclasses implement it instead of MyInterface.

I don't think there is a way to do that. Not exactly like that anyway. However, since this is a private field and you control it entirely, you can just declare it as
private MyClass value;
but also make sure in all your code that only objects that implements MyInterface are affected to it, and cast everywhere you need to access it as the interface. Yes, it looks dirty, and it is (slightly).
You could also create the following derived class
abstract class MyDerivedClass extends MyClass implements MyInterface {
//...
}
and then use
private MyDerivedClass value;
This is much cleaner, but you have to create an other class, just for that purpose...