0

Many specifications define different JSRs for different versions of the API, e.g. for the Java Servlet spec:

 -------------------------------
|Servlet spec version |   JSR   |
 -------------------------------
|     4.0             |   369   |
|     3.1             |   340   |
|     3.0             |   315   |
|     ...             |   ...   |   
 -------------------------------

However, in other cases multiple versions of the API are handled by the same JSR. As an example JavaMail has 6 API versions - from 1.1 to 1.6, all defined through JSR 919.

When trying to download the spec, only the 1.5 versions (one for evaluation and the other for implementation) can be downloaded (files called JavaMail-1.5.pdf). If I want to read version 1.6 or implement 1.2, I'm out of luck.

Do the old versions of the spec get discarded as part of the process?

In this particular case, there is a 1.6 implementation, but there's only the 1.5 spec accessible publicly. Are there files hidden from the public?

How is the decision made to stay within the same JSR in contrast to creating a brand new one? What is the process of taking that decision? Can I vote?

parml
  • 497
  • 5
  • 15

1 Answers1

1

You must be a member of the JCP (Java Community Process) to be able to make a proposal for a JSR. Being a member means paying some annual fees. The JSR-913 explains the JCP rules.

The JCP defines several types of members (extract from JCP):

  • Associate Members: individuals who can contribute to JSRs and vote for the Executive Committee.

  • Partner Members: Java User Groups and other non-profit organizations that can serve on and vote for the Executive Committee.

  • Full Members: can serve on Expert Groups, lead JSRs, serve on and vote for the Executive Committee.

A graph explaining how to join the JCP is available here: https://jcp.org/aboutJava/communityprocess/final/jsr364/JCP_Joining_Process_v11.pdf

JavaMail 1.6 will be available when totally finalized. As you can see in a plain text document published on the JCP.org site (https://jcp.org/aboutJava/communityprocess/maintenance/jsr919/JavaMail-1.6-changes.txt), they talk about it in the future (!!!):

On this page, available today (Aug 17, 2017), they talk like if they had written the changelog from JavaMail 1.5 to JavaMail 1.6 more than one week in the future. The document starts with:

JavaMail 1.6
============
(Updated August 28, 2017)
Following is a description of the changes to the JavaMail
API introduced in JavaMail 1.6.  The numbers in parentheses
are bug numbers; you can find more information about the
bug reports at:
https://jcp.org/aboutJava/communityprocess/maintenance/jsr919/JavaMail-1.6-changes.txt

Moreover, HTTP headers say it has been published on may 23, 2017! Weird...

With Java specifications, problems are not linked to JSR availability. They are linked to TCK and JCK availability. To summarize, you can not say that your implementation of a JSR is really a Java implementation of this JSR without having passed all the tests described in the TCK/JCK. And those documents are not systematically available free of charge. And even if you are ready to pay Oracle to get those documents, Oracle is not forced to accept. It is weird, but Oracle owns the Java IP and trademark, so you have to agree with Oracle's terms of use.

Alexandre Fenyo
  • 4,526
  • 1
  • 17
  • 24