Jason T. Greene wrote on 10/10/11 7:25 AM:
> We skipped pruning JSR-77 last time around because a number of us thought it was
> better to update it to be more current. I think it's become clear that the spec
> is not only not going to be updated, but that its relevance is fading with the
> cloud direction the industry is moving in.
I agree, we're not expecting significant updates to JSR-77, and we need a
different management API in the long term. I'd be much happier if we had
a replacement in place when we make JSR-77 optional.
> Can we prune it this time around (make it optional to vendors)? Also, why does
> the pruning process require that we wait for the next EE iteration to finalize
> something being made optional? Let's assume that in this example we made JSR-77
> optional in EE7, then after 7 is released we decided it was a mistake, we can
> just bring it back as required in EE8.
We adopted the process formalized by the Java SE platform expert group, rather
than inventing our own different process. It's good that there's consistency
across the Java platform for how these things are handled.
The reason it takes two releases is to give developers and the community a
chance to react and to provide feedback. This is fairly standard practice
across the industry.