This page provides some additional detail on how the Java EE group at Oracle uses or interprets the standard JCP processes described in the JCP process document.
The JCP process defines two ways to update a JCP spec:
We typically make two types of changes to specs:
Unfortunately, the two types of changes don't map directly to the two ways of updating a spec.
We always use the Maintenance Release process for spec errata.
We also use the Maintenance Release process for API Changes.
Of course, we only use the Full JSR process for significant API Changes.
Even though both errata and API changes can be done in a Maintenance Release, we prefer to not mix them in a single Maintenance Release.
Which API changes are "too big" for the Maintenance Release process is a judgment call. In general, the changes should be straightforward. A person who understands the spec should be able to look at the proposed changes and say "yes, I understand that". If you feel like you need to consult other experts in order to make sure your proposed changes are correct, you may be outside the scope of a Maintenance Release. But note that just because you have consulted other experts doesn't mean you're automatically disqualified from the Maintenance Release process.
The appropriate measure is less the size of the change and more the complexity of the change. (But of course size and complexity are related.)
You can add new methods, new classes, and new packages to an existing spec.
You can not create an entirely new spec.
In the end, the practical answer to "what can I do in an MR?" is "whatever the JCP EC approves". If you think there's significant risk that they won't approve it if they see it in an MR, don't do it in an MR.
A Maintenance Release that includes API changes defines a new version of the spec.
A Maintenance Release that includes only errata does not define a new version of the spec, but only updates the spec document. The spec clarifications included in such a Maintenance Release apply to the current version of the API.
If a single Maintenance Release contains both errata and API changes, the clarifications in the errata apply to only the newly defined version of the API. For this reason it's usually best to separate errata and API changes into separate Maintenance Releases.
See Versioning for more on versioning of APIs and specification documents.