Romain Manni-Bucau wrote on 11/15/14 03:01:
> 2014-11-14 22:54 GMT+01:00 Bill Shannon <bill.shannon_at_oracle.com>:
>> This discussion seems to have wandered off topic...
>>
>> I'm not trying to raise the question of whether default resources are a good
>> idea or not. We've already decided they are, and they're already in the spec.
>> You might disagree with that decision, but that decision has already been made.
>>
>
> Yes, sorry but mainly wanted to make more obvious default resources
> are not defined enough today and that some more work on this topic
> would be very welcomed.
I'm not sure in what sense you think they're not defined well enough,
although it may depend on whether you think (e.g.) the JDBC, JPA, and
JMS specs are defined well enough to allow you to write a portable
application that's independent of the implementation of that spec.
>> Given that we made that decision, and given that we believe it is a useful and
>> usable feature appropriate for some users and some use cases, how should we
>> deal with the issue raised in my original message?
>
> Maybe I didn't get it right but your message is mainly about product
> specific features in which case vendors should handle it and not the
> spec since features are already out the spec. Said otherwise if the
> spec allows to influence vendors features then this should be spec
> features. Having auto-adjusting resources or default resources is
> mainly the same in term of behavior so not sure spec should go further
> regading it.
It may help to better understand how our Java Compatibility rules work...
When the spec says "X happens", it means "X *always* happens", not
"X happens unless the product overrides it" or "X happens if you're in
Java EE compatibility mode" or "X happens unless you select option Y".
That means products *always* have to map resource references to default
resources, as described in the spec. Always. No matter what. You can't
have a product-specific feature that does something different.
And that's where the conflict comes in, which is why I raised this issue.