Well, we have to define something for the version syntax and how it
converts to the legacy double version.
I think it makes sense to follow the Verona JEP as that's the JDK
version syntax which seems to fit the normal convention of release
numbering.
Maybe we can clarify major and minor by referring to
java.lang.Runtime.Version class?
Valerie
On 6/23/2016 6:22 PM, Wang Weijun wrote:
On Jun 24, 2016, at 9:11 AM, Valerie Peng <valerie.p...@oracle.com> wrote:
I am not sure if we can always return 0d for getVersion() even if we deprecate
this method.
Doubt that people are relying on this, but don't we normally keep the
functionality the same after deprecating a method?
I accept this.
"9.0d" is not the supported version format. The new version string syntax
follows what's suggested in Verona JEP, not the the direct string representation of
double. 9.0d is only for specifying double value in the older constructor. I don't think
it means you can call the new constructor by just adding a quote around it to convert it
into a String.
Maybe we need to document it somewhere to prevent this potential user error?
Yes.
In the new Provider constructor, you mentioned
233 * @implNote The JDK implementation will process the specified version
234 * string by keeping only the major and minor versions and then
235 * convert the result into a double for {@code getVersion()}. If
parsing
236 * failed, value 0 will be returned.
but the meaning of "major and minor versions" is actually undefined. Do we
really require a 3rd party vendor to use the Verona version style?
Thanks
Max
