• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DI and final filelds

 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

I try to use DI with a final variable, the variable was already set to null so its value can not be set again - but it seams that the DI does a little bit more - see the code snippet below .


I run this code with Glassfish and it works well. Is this (final field reassign ) a container specific behavior or this is a standard DI behavior.

Regards,
M
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's one drawback of reflection. It allows to break common object oriented programming rules.
 
Jaikiran Pai
Marshal
Pie
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mihai Radulescu:
I try to use DI with a final variable



I run this code with Glassfish and it works well. Is this (final field reassign ) a container specific behavior or this is a standard DI behavior.



This looks like a bug to me. I had read in the spec that the fields which need dependency injection cannot be final. I don't seem to find that section in the spec right now.
 
Sergio Tridente
Ranch Hand
Posts: 329
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are right, Jaikiran.

Accordingly to section 16.2.2 of the ejb core specification (Annotation for environment entries):


A field of the bean class may be the target of injection. The field must not be final.

[ September 11, 2008: Message edited by: Sergio Tridente ]
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys and thanks fro the answers.

so it I put it all together this is a drawback (based on the reflection mechanism). The specification does now allows this but for :
  • the compiler this a legal statement
  • the container ignore the specification because of the reflection drawback.



  • So I presume that I must stay stick to the specifications.


    Regards,
    M
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic