Hi
This is what says chapter 13 of java language specification
section 13.4.17. final Methods
https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html
"... Changing a method that is declared final to no longer be declared
final
does not break compatibility with pre-existing binaries. ..."
"... Changing an instance method that is not declared final to be declared
final may break compatibility with existing binaries that depend on the
ability to override the method. ..."
LU> Can't we just remove the "final" modifier here? I know that in these
cases
LU> it makes sense, but make UIComponent instances injectable in CDI seems
to
LU> be a winning
LU> proposition to me.
EB> That sort of signature change would break existing compile time
EB> dependencies and cause build time problems. We can't do that at this
EB> point.
I disagree. The Java Language Specification is clear about this. What
happens
here is if you change a "non final" method to "final", that breaks binary
compatibility.
The change proposed does not break binary compatibility.
EB> You're not the only one. We tried to make UIComponent injectable and
EB> ran into a lot of problems with state saving and the lifecycle. It's
EB> too big a change at this point.
Could be, but I do not want to throw the towel until try it. At this point
we have 3 options:
1. Change the table to exclude UIViewRoot from injection.
2. Do the change removing "final" modifiers and include UIViewRoot as CDI
injectable, do not inject components for current version.
3. Do the change and make components injectable.
I ask you guys to reconsider, at least do option 2. Option 3 is still a
posibility to explore, I'll do my best to see how to make it work.
regards,
Leonardo Uribe
2016-12-15 14:19 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> +1 on NOT doing API change
>
>
> On 12/15/16, 11:26 AM, Edward Burns wrote:
>
>> Executive Summary:
>>
>> Ed pushes back on proposed API change.
>>
>> Details inline.
>>
>> On Thu, 15 Dec 2016 01:59:16 -0500, Leonardo Uribe<
>>>>>>> leonardo.uribe_at_irian.at> said:
>>>>>>>
>>>>>> LU> Hi
>> LU> I'm exploring the posibility of make UIComponent instances CDI
>> injectable
>> LU> for JSF 2.3, and I have found that some final methods in UIComponent
>> LU> creates a conflict:
>>
>> LU> public final Map<String,Object> getPassThroughAttributes()
>> LU> public final TransientStateHelper getTransientStateHelper()
>> LU> public final void popComponentFromEL(FacesContext context)
>> LU> public final void pushComponentToEL(FacesContext context, UIComponent
>> LU> component)
>>
>> LU> Can't we just remove the "final" modifier here? I know that in these
>> cases
>> LU> it makes sense, but make UIComponent instances injectable in CDI
>> seems to
>> LU> be a winning
>> LU> proposition to me.
>>
>> That sort of signature change would break existing compile time
>> dependencies and cause build time problems. We can't do that at this
>> point.
>>
>> On Thu, 15 Dec 2016 02:14:42 -0500, Leonardo Uribe<
>>>>>>> leonardo.uribe_at_irian.at> said:
>>>>>>>
>>>>>> LU> I forgot to mention why this is really wanted. If UIComponents
>> are
>> LU> CDI proxyable we could make "binding" attribute to inject a CDI
>> LU> UIComponent proxy and solve the problem when UIComponent instances
>> LU> are inside session scope beans once for all. That could be a big
>> LU> step forward for JSF.
>>
>> On Thu, 15 Dec 2016 10:34:05 +0300, Cagatay Civici<
>>>>>>> cagatay.civici_at_gmail.com> said:
>>>>>>>
>>>>>> CC> There are so many users who suffer from this issue for years,
>> fixing
>> CC> this will be great.
>>
>> While it is certainly true that users are suffering from the "binding"
>> issue, which has been present since 1.0,
>>
>> On Thu, 15 Dec 2016 18:25:54 +0100, arjan tijms<arjan.tijms_at_gmail.com>
>>>>>>> said:
>>>>>>>
>>>>>> AT> Components are indeed explicitly not injectable now. See also
>> the overview
>> AT> table here: http://arjan-tijms.omnifaces.org/p/jsf-23.html#1316
>>
>> AT> A little over a year ago I had been experimenting with this too, and
>> what
>> AT> it basically needs (besides, indeed removing the final modifiers),
>> is what
>> AT> I called a "FacesRequestScope".
>>
>> You're not the only one. We tried to make UIComponent injectable and
>> ran into a lot of problems with state saving and the lifecycle. It's
>> too big a change at this point.
>>
>> Thanks,
>>
>> Ed
>>
>>