RFR: 8044740: Convert all JDK versions used in @since tag to 1.n[.n] in jdk repo
david.holmes at oracle.com
Wed Jun 4 09:55:28 UTC 2014
On 4/06/2014 1:38 PM, Paul Benedict wrote:
> I like seeing "JDK" as well... primarily because IDEs have the ability to
> show javadoc snippets when hovering over an element. It's good to see what
> product the version comes relates to.
> Yet, on the other hand, these Oracle APIs are not published under "JDK"
> branding but under the title "Java SE". Shouldn't that be used instead?
The "naming documents" eg:
indicate using the version string on @since tags ie 1.7, 1.8
> On Tue, Jun 3, 2014 at 10:17 PM, Mike Duigou <mike.duigou at oracle.com> wrote:
>> You will need to include awt-dev and security-dev since this patch touches
>> those areas as well. Other impacted groups I missed?
>> I would like to see this all go back in one changeset to dev repo though
>> as it would be a lot cleaner that way.
>> I am concerned a bit that if we retain standard names for non-jdk
>> standards it may be sometimes confusing or lacking in context to see a raw
>> version number. Consistency is trumps all, but I would prefer to see
>> JDK#.#[.#] used to be unambiguous.
>> I don't see any missteps in the changeset but wouldn't want mine to be the
>> only review.
>> On Jun 3 2014, at 18:22 , Henry Jen <henry.jen at oracle.com> 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
>>> 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,
More information about the core-libs-dev