springframework-developer

[Springframework-developer] Generics-enhanced Beans declaration?

[<l.d...@gm...>]

 I did not invest much time in googling around to find an answer, but most=
=20
of my findings were concerning something called "generics medicines" and=20
"until spring".

I want to ask if there are any plans to support generics-enahnced beans=20
declarations in Spring Context.
I don't quite grasp the idea there, but I think there 'might/should' be a=
=20
way to generalize a beans's class in the context, something saying what=20
classes is the generic specialized for.

While Spring uses reflection and run-time casting it would supply little or=
=20
no extras for Spring itself (I think), but enabling the use of Generics for=
=20
contained beans might provide some wishful flexibility.

Thoughts for food :)

P.S. Sorry to cross-post. Erroneously sent it to the user list.

[Springframework-developer] Generics-enhanced Beans declaration?

[<l.d...@gm...>]

 I did not invest much time in Google-ing around to find an answer, but mos=
t
of my findings were concerning something called "generics medicines" and
"until spring".

I want to ask if there are any plans to support generics-enhanced beans
declarations in Spring Context.
I don't quite grasp the idea there, but I think there 'might/should' be a
way to generalize a bean's class in the context, something saying what
classes is the generic specialized for.

I have seen questions here as to what use would it be...
Well... Let's say we have a generic base DAO interface:

public interface BaseDao<T> {
public T load(Long ID);
public Long save(T);
public void update(T);
public void delete(T);
}

So we have our services depend on BaseDAO<SpecificType>

public class MyServiceImpl implements MyService {
// We specialise the generic type here.
public void setBaseDao(BaseDao<SpecificEntity> dao) {
this.dao =3D dao;
}
}

Then let's assume we are using Hibernate and have a Generic implementation
of the BaseDao<T>: BaseHibernateDao<T>

1. I would very much like to do:
<bean name=3D"myEntityDao"
class=3D"com.company.BaseHibernateDao<com.company.SpecificEntity>" />

Actually I believe this is quite required if Spring is to be Java5-capable.

2. I would also want to have:
<bean name=3D"myService"
class=3D"com.company.MyServiceImpl"
autowire=3D"byType"/>

and of course have my baseDao set accordingly. This is not required, as
byName gives better handling, but might be considered good.

These are not all the implications Generics support in Spring might give,
but I think these give some insight on what Generics can be used for.

While Spring uses reflection and run-time casting it would supply little or
no extras for Spring itself (I think), but enabling the use of Generics for
contained beans might provide some wishful flexibility.

Thoughts for food :)

Lachezar Dobrev

[Springframework-developer] Generics-enhanced Beans declaration?

[Lachezar D. <l.d...@gm...>]

 << Appologies to all members that get this mail once more. >>
<< It seems SF drops mail from users with non-latin names :(. >>
<< I changed my name to be in latin letters only, hope it gets now. >>

I did not invest much time in Google-ing around to find an answer, but most
of my findings were concerning something called "generics medicines" and
"until spring".

I want to ask if there are any plans to support generics-enhanced beans
declarations in Spring Context.
I don't quite grasp the idea there, but I think there 'might/should' be a
way to specialize a generic enhanced bean's class in the context, something
saying what classes is the generic specialized for.

I have seen questions here as to what use would it be...
Well... Let's say we have a generic base DAO interface:

public interface BaseDao<T> {
 public T load(Long ID);
 public Long save(T);

public void update(T);
public void update(Collection<T>);

public void delete(T);
 public void delete(Collection<T>);
public void delete(Collection<Long>);
 }

So we have our services depend on BaseDAO<SpecificType>

 public class MyServiceImpl implements MyService {
 // We specialise the generic type here.
 public void setBaseDao(BaseDao<SpecificEntity> dao) {
 this.dao =3D dao;
 }
 }

Then let's assume we are using Hibernate and have a Generic implementation
of the BaseDao<T>: BaseHibernateDao<T>
 public class BaseHibernateDao<T> extends HibernateDaoSupport
implementsBaseDao<T> {
 public T load(Long ID) { ... }
 public Long save(T) { ... }

public void update(T) { ... }
public void update(Collection<T>) { ... }

public void delete(T) { ... }
 public void delete(Collection<T>) { ... }
public void delete(Collection<Long>) { ... }
 }

1. I would very much like to do:
 <bean name=3D"myEntityDao"
 class=3D"com.company.BaseHibernateDao<com.company.SpecificEntityClass>" />

Actually I believe this is quite required if Spring is to be Java5-capable.

2. I would also want to have:
 <bean name=3D"myService"
 class=3D"com.company.MyServiceImpl"
 autowire=3D"byType"/>

and of course have my baseDao set accordingly. This is not required, as
byName gives better handling, but might be considered good.

These are not all the implications Generics support in Spring might give,
but I think these give some insight on what Generics can be used for.

While Spring uses reflection and run-time-casting it would supply little or
no extras for Spring itself (I think), but enabling the use of Generics for
contained beans might provide some wishful flexibility.

Thoughts for food :)

Lachezar Dobrev

Re: [Springframework-developer] Generics-enhanced Beans declaration?

[Juergen H. <ju...@in...>]

JDK 1.5 generics are essentially a compile-time construct, not a run-time
construct. We can't instantiate a class with a given generic type through
reflection: That only makes sense in Java source code, for strong typing at
compile time. At runtime, it's just a plain instance of that class. Hence,
we also can't autowire such beans by specific generic type: At runtime, the
generic type information is essentially not available anymore. All of those
instances can be just be matched again their plain class type.
 
In other words, classes using generics are not different from plain Java
classes at runtime, hence they cannot be (or need to be) treated in a
specific fashion by Spring.
 
In your specific case, you could essentially define a single
BaseHibernateDao and pass it to all your services, even if each of those
services expects a specifically typed BaseHibernateDao. At runtime, that
single plain BaseHibernateDao instance is gonna be able to serve all those
typed callers. It's all gonna be Object arguments at runtime, with the
specific types only mattering to the source code of the callers - as long as
the actual runtime Object type matches the caller's expectation.
 
Juergen
 

  _____  

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Lachezar Dobrev
Sent: Wednesday, October 05, 2005 10:15 AM
To: Spring DEV
Subject: [Springframework-developer] Generics-enhanced Beans declaration?


  << Appologies to all members that get this mail once more. >>
  << It seems SF drops mail from users with non-latin names :(. >>
  << I changed my name to be in latin letters only, hope it gets now. >>

  I did not invest much time in Google-ing around to find an answer, but
most of my findings were concerning something called "generics medicines"
and "until spring".
  
  I want to ask if there are any plans to support generics-enhanced beans
declarations in Spring Context.
  I don't quite grasp the idea there, but I think there 'might/should' be a
way to specialize a generic enhanced bean's class in the context, something
saying what classes is the generic specialized for.

  I have seen questions here as to what use would it be... 
  Well... Let's say we have a generic base DAO interface:

  public interface BaseDao<T> {
     public T    load(Long ID);
     public Long save(T);

     public void update(T);
     public void update(Collection<T>);

     public void delete(T);
     public void delete(Collection<T>);
     public void delete(Collection<Long>);
  }

  So we have our services depend on BaseDAO<SpecificType>

  public class MyServiceImpl implements MyService {
     // We specialise the generic type here.
     public void setBaseDao(BaseDao<SpecificEntity> dao) {
        this.dao = dao;
     }
  }

  Then let's assume we are using Hibernate and have a Generic implementation
of the BaseDao<T>: BaseHibernateDao<T>
  public class BaseHibernateDao<T> extends HibernateDaoSupport implements
BaseDao<T> {
     public T    load(Long ID) { ... }
     public Long save(T)       { ... }

     public void update(T)             { ... }
     public void update(Collection<T>) { ... }

     public void delete(T)                { ... }
     public void delete(Collection<T>)    { ... }
     public void delete(Collection<Long>) { ... }
  }

  1. I would very much like to do:
  <bean name="myEntityDao" 
    class="com.company.BaseHibernateDao<com.company.SpecificEntityClass>" />

  Actually I believe this is quite required if Spring is to be
Java5-capable.

  2. I would also want to have:
  <bean name="myService" 
    class="com.company.MyServiceImpl"
    autowire="byType"/>

  and of course have my baseDao set accordingly. This is not required, as
byName gives better handling, but might be considered good.

  These are not all the implications Generics support in Spring might give,
but I think these give some insight on what Generics can be used for.

  While Spring uses reflection and run-time-casting it would supply little
or no extras for Spring itself (I think), but enabling the use of Generics
for contained beans might provide some wishful flexibility.
  
  Thoughts for food :)

  Lachezar Dobrev 

Re: [Springframework-developer] Generics-enhanced Beans declaration?

[Lachezar D. <l.d...@gm...>]

 Hm.
Actually after reading your reply I found out, that I don't need to
specialize beans in Spring, and even autowire-by-type works...

The problem would arise when one tries to reuse a single generic bean as
multiple specialized properties, but that is completely out-of scope.

I had the vague idea, that one could use reflection to instantiate a
specialized instance of a generic class, but you clarified it for me...
Those are just compile-time extras.

Thank you.