[8u] RFR 8160768: Add capability to custom resolve host/domain names within the default JNDI LDAP provider
Severin Gehwolf
sgehwolf at redhat.com
Wed Aug 19 06:51:08 UTC 2020
On Mon, 2020-08-17 at 06:26 +0100, Andrew Hughes wrote:
> On 11:51 Thu 13 Aug , Severin Gehwolf wrote:
> > On Tue, 2020-08-11 at 14:48 -0400, Zhengyu Gu wrote:
> > > Hi Michael,
> > >
> > > > My tests/comments:
> > > > * @since still says 12. Is that correct?
> >
> > I agree. Zhengyu, please remove the @since 12 tags in this backport. It
> > doesn't make sense to have them in either 11 or 8.
> >
>
> I disagree. Such tags are a useful indicator that this is a backported
> API that wasn't in 8 GA.
If we are starting to rely on @since tags as an indicator for backports
then we're in trouble. Instead, the bug system and source control
should be used for this. Given that, by removing the @since tag we
don't loose info that it's a backport.
> What would be the issue with leaving them in?
A couple of reasons:
* It's confusing. Mentioning something related to JDK 12 in a JDK 8
tree is, well, confusing. It only wouldn't be so if you are
intimately familiar with the process and know about this mailing
list discussion.
* @Since tags are usually used for *publicly* exposed classes as an
aid for JDK API consumers. "This API is available for JDK 12 and
onwards". I'm aware there are instances where it was used for
internal classes too, but they become less prominent these days. It
makes sense to have them for the original JDK 12 change. For the JDK
8u backport, classes have been moved to a private package. It's not
a 1-to-1 backport. The value of it being preserved regardless makes
little sense. It's not the original class where it was added to
begin with.
* The SinceTree.java interface mentions this in its javadoc: "Returns
the text explaining the availability of the item being documented."
That's wrong for code in JDK 8. We'd be putting a @since 12 on code
introduced in an update version of 8u.
Overall, the drawbacks outweigh the benefits.
Thanks,
Severin
More information about the jdk8u-dev
mailing list