[javaee-spec users] Re: default resources

From: Romain Manni-Bucau <>
Date: Mon, 17 Nov 2014 22:05:13 +0100

2014-11-17 21:55 GMT+01:00 Bill Shannon <>:
> 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.

Fully agree but when it comes to resources that's almost the only
thing you care about. That's why i said it was awesome for tests but
not usable in prod environments.

>>>>>>> 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.

If that's not activated by default and user activates it by itself
then the spec is no more in action so I don't see why it is an issue.
If that's the case it should be broken with next spec cause if
something in the spec N prevents an app to work and it can't be
changed even with proprietary config/code then you just don't care
about some users until spec N+1 at least.

In practise no issues: there is not a single (open source at least)
library doing what you describe. All are customizable enough to
completely violate EE if we want - I don't say it should be done just
flexibility is good and natural since most of products are usable with
EE alternatives.

> 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.