[javaee-spec users] Re: default resources

From: Bill Shannon <>
Date: Mon, 17 Nov 2014 12:55:11 -0800

Romain Manni-Bucau wrote on 11/17/14 12:39:
> 2014-11-17 21:30 GMT+01:00 Bill Shannon <>:
>> Romain Manni-Bucau wrote on 11/17/14 12:22:
>>> 2014-11-17 21:02 GMT+01:00 Bill Shannon <>:
>>>> Romain Manni-Bucau wrote on 11/15/14 03:01:
>>>>> 2014-11-14 22:54 GMT+01:00 Bill Shannon <>:
>>>>>> 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.
>>> For JMS: you don't know if you are local/remote/protocol. For DS: you
>>> don't know if you are in memory, on disk (and where), remote.... All I
>>> ask is to add a line saying use cases associated with theses default
>>> resources (1000 datasource lines? 1000000?... for instance).
>> Sorry, I don't understand what you want added where.
> You know you have a car but you don't know if you can go in city, road
> or highway. That's current state.

We've tried to explicitly stay away from "quality of service" specifications.
It becomes too much of a judgment call instead of a testable assertion.
In the end, users need to choose a runtime/product that meets their
reliability/scalability/performance/whatever requirements and it seems
unlikely we'll ever be able to encode all those requirements in an
application package.

>>>>>> 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.
>>> Which is not true. A vendor can (of course) override EE rules if
>>> needed/asked. Think all impls do it.
>> The Java EE Compatibility rules prohibit that. It's true that they can,
>> but they're not allowed to. Just because you *can* exceed the speed limit
>> doesn't mean it's *legal* to do so.
> Even if default is respected?

Yes, even if.

The spec doesn't say "here's what you have to do by default".
The spec says "here's what you have to do". Period. End of sentence.
No qualifiers. If you ever want to do something different, the spec
has to explicitly allow it.

I know this is a hard thing to grasp because few if any other specs
do it this way, but this is one of the key things that makes Java unique.