The Cloud could be among cases, where at least platform or vendor-related
features may require finer grained optionality.
Nothing existing for most parts, so it's not like deprecating.
If parts of let's say Bean Validation were not to be optional, then
introducing a similar paradigm (an annotation to control whether a value may
be null or not) in a different place should be handled with even greater
care.
As introducing new redundancy or ambiguous annotations like "NonNull" vs.
"NotNull" would create even greater confusion.
On Tue, Oct 18, 2011 at 2:31 AM, Bill Shannon <bill.shannon_at_oracle.com>wrote:
> Werner Keil wrote on 10/17/11 17:12:
>
> * Deprecate JSF @ManagedBean -- the redundancy right now is very
>> confusing for developers.
>> * Deprecate Java EE 6 @ManagedBean -- it's hardly ever used and
>> creates
>> a lot of confusion.
>>
>>
>> As a matter of policy, we don't deprecate anything except for the most
>> serious errors. We can update the docs to make it clear what you
>> should
>> and should not use, but we're not likely to deprecate them.
>>
>>
>> EE8 and beyond with true modularity will require a different approach to
>> that,
>> by declaring something "optional", thus allowing an app to function
>> properly
>> without having to use or load it.
>> So unless something was crucial now in EE 7 I would probably postpone
>> other
>> cases and think about a good and reasonable module structure and profiles
>> then.
>>
>
> Even with true modularity, we're trying to only make entire specs optional.
> With a few exceptions, finer grained optionality will be harder for
> developers to understand.