RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo
Alan.Bateman at oracle.com
Wed Jun 4 13:03:00 UTC 2014
On 04/06/2014 02:22, Henry Jen wrote:
> In an effort to determine APIs availability in a given version, it
> became obvious that a consistent way to express @since tag would be
> So started with the most obvious ones, where we have various
> expression for JDK version, this webrev make sure we use @since
> 1.n[.n] for JDK versions.
> The main focus is on public APIs, private ones are taken care if it is
> straightforward, otherwise, we try to keep the information.
> Some public APIs are using @since <STANDARD> <standard version>
> format, they are also preserved for now, but I think it worth
> discussion whether we want to change to the version as included in J2SE.
> There are APIs without @since information, separate webrevs will be
> coming to complete those information.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8044740
> The webrev can be found at
> but it's probably easier just look into the raw diff,
I skimmed through the patch and it looks okay to me. It's good to get
consistency as it was always odd to have a mix of JDK1.x vs. 1.x in the
javadoc. From what I can tell, there was a mix of JDK1.x vs. 1.x in the
early releases but it's much more consistent in the last few major
releases (there are no JDK1.6 or JDK1.7 to replace for example, and the
only "JDK1.8" are in the JSR-310 classes).
I see you've changed a number of implementation classes, I guess they
aren't too interesting as the javadoc is typically not
generated/published for those.
One thing that isn't clear is the changes to several package.html files
where the change is not obvious. Are these just white spaces? Maybe a
side effect of a script?
I see Phil has asked that this be split up for jdk9/dev and jdk9/client
but it hardly seems worth it for this patch. It might be simpler to just
push and then sync up jdk9/client.
More information about the core-libs-dev