[javaee-spec users] [jsr342-experts] report on EG meeting at JavaOne

From: arjan tijms <>
Date: Thu, 10 Oct 2013 19:46:33 +0200

On Wed, Oct 9, 2013 at 8:17 PM, Bill Shannon
<<javascript:_e({}, 'cvml',
> wrote:

> arjan tijms wrote on 10/09/13 11:02:
> Do you or anyone else remember what the exact rationale was for removing
> JSR 88? I did some digging but couldn't find anything on the mailing lists.
> If I understand correctly it was pruned in Java EE 6, made optional in Java
> EE 7, and will be removed in Java EE 8, right?
> Nothing is ever removed from the RI. It's optional and will remain
> optional for the foreseeable future. Products may choose not to provide it.

Thanks for the clarification. I was under the impression that the cycle was
"prune" (announce becoming optional), "make optional", "remove from the
spec", but this was thus wrong.

It was pruned because virtually no one is using it.

Aren't at least WebLogic and Geronimo using it as their native deployment

But what I actually meant to ask is whether it's known why the uptake was
so low? Was there any discussion about that back then?

The functionality still seems to be in demand. As this sub-discussion
started out with; will replacing it by ReST APIs suddenly make it something
everybody will use?

> Feel free to submit a new JSR to define such a spec. I agree that many
> would find it useful, but it's unlikely to become a required part of the
> platform.

Do you mean the JSR corresponding to the item "ReST APIs to deploy and
manage applications" from slide 31, or a JSR completely separate from that?

> The TCK needs to be able to deploy/undeploy applications, but it does not
> need to start/stop servers. The TCK has been using JSR-88, but with that
> becoming optional the TCK will need to define its own pluggability API just
> for its own purposes; it need not be a general purpose API.

That's really interesting to know.

I wonder, if this new ReST API did indeed happen and it only did
deploy/undeploy, couldn't that one be used for the TCK?

> I'm not sure that's a major issue with either of those specs.

Well, I got this among others from the following quote in the "Pruning
JSR-77" discussion that I referred to earlier:

>> [...] forces the application server to expose a consistent set of
monitoring data [...]
> I'm not sure it does that with so much of the spec being optional

> We're definitely open to that, and will consider the filed Jira issues in
> that context.

Great, that's a really good start. I especially hope that a few of the
filed Jira issues for JASPIC can be done for Java EE 8 (either for another
MR or for a new version of that spec).

Kind regards,
Arjan Tijms