2:41 a.m.
CDI developer all
Hi, I'm Hiromi Takahashi.
I work for Mitsubishi UFJ Information Technology.
Our company is in charge of Mitsubishi UFJ financial group system development, operation
and maintenance.
And then , I'm in charge of in-house Java framework.
Our Java framework depends heavily on Java SE and Java EE technologies.
I reviewed JSR365 (CDI2.0) Public Review .
I think it's great.
On the other hand, to make things even better, I would like to suggest the following:
・About CDI's goal in Java SE
What I think is great about CDI is its ability to inject to Java object
"transparently".
However, with the current spec of CDI, it requires some coding each time to get the
injected objects.
For example, in getNewInstance() method, I think it would be great if CDI could judge if
there was an injected field or not
(ie. if there is an injected field then CDI injects, and if not CDI just makes a new
instance.)
How we code would be even simpler and more beautiful.
This way, users can always generate instances in such standard method.
Also, it could be even better if CDI could act like below when using "new"
descriptor:
- If the class has injected field, then get the injected instances
- If the class has no injected field, then just simply get a new instance
In Java EE, these functions are the container's role and CDI may not have to be in
charge of them.
However, considering CDI may be used in Java SE, I think CDI needs to act like above in
the future.
Best regards.
##############################################################
Mitsubishi UFJ Information Technology,Ltd.
Management Information Systems Platforms Department.
Hiromi Takahashi
tel：+81-3-5859-1525
mail：hiromi_18_takahashi(a)mufg.jp
##############################################################
5:09 a.m.
Hi Hiromi,
And thanks for your feedback.
Regarding your suggestion I'm not sure to understand everything, so giving
us code example could help.
Anyway, I'll try to answer on the points I understood, we won't go on too
much magic in CDI: injecting automatically in field if they are not
annotated with @Inject.
This could be confusing and would bring more problem than solution I think.
But if you need this on your project you can rather easily create a
portable extension to implement this feature.
Regarding hooking on the "new" java keyword, I also think it's a bad idea:
user would be never be sure if their variable contains a pojo instance or a
contextual instance with a lifecycle they don't own.
I may have misunderstood your suggestion, so feel free to correct me.
Antoine Sabot-Durand
On Thu, Mar 2, 2017 at 9:41 AM <hiromi_18_takahashi(a)mufg.jp> wrote:
CDI developer all
Hi, I'm Hiromi Takahashi.
I work for Mitsubishi UFJ Information Technology.
Our company is in charge of Mitsubishi UFJ financial group system
development, operation and maintenance.
And then , I'm in charge of in-house Java framework.
Our Java framework depends heavily on Java SE and Java EE technologies.
I reviewed JSR365 (CDI2.0) Public Review .
I think it's great.
On the other hand, to make things even better, I would like to suggest
the following:
･About CDI's goal in Java SE
What I think is great about CDI is its ability to inject to Java object
"transparently".
However, with the current spec of CDI, it requires some coding each time
to get the injected objects.
For example, in getNewInstance() method, I think it would be great if CDI
could judge if there was an injected field or not
(ie. if there is an injected field then CDI injects, and if not CDI just
makes a new instance.)
How we code would be even simpler and more beautiful.
This way, users can always generate instances in such standard method.
Also, it could be even better if CDI could act like below when using "new"
descriptor:
- If the class has injected field, then get the injected instances
- If the class has no injected field, then just simply get a new instance
In Java EE, these functions are the container's role and CDI may not have
to be in charge of them.
However, considering CDI may be used in Java SE, I think CDI needs to act
like above in the future.
Best regards.
##############################################################
Mitsubishi UFJ Information Technology,Ltd.
Management Information Systems Platforms Department.
Hiromi Takahashi
tel：+81-3-5859-1525 <+81%203-5859-1525>
mail：hiromi_18_takahashi(a)mufg.jp
##############################################################
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
2874
days inactive
2874
days old
1 comments
2 participants
participants (2)
-
Antoine Sabot-Durand -
hiromi_18_takahashi＠mufg.jp