<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
That makes sense to me. I very much hope we can remove the getWindow
method in JDK 10.<br>
<br>
-- Kevin<br>
<br>
<br>
David DeHaven wrote:
<blockquote cite="mid:A6933CAA-732E-4EC4-9C78-97A12CAC20FD@oracle.com"
 type="cite">
  <pre wrap="">[removed bad email address..]

Ok, my understanding was that forRemoval was intended for the next release, so setting it to true meant we were saying "removing in JDK 10." If that's NOT the case then we should set it to true for this particular case since this method is tied specifically to the plugin and not Applet.

I just don't want to hear any whining when it comes around to JDK 11 and it hasn't been removed yet ;)

I still don't know about Applet as anyone using it outside of plugin has been very quiet and I suspect we WON'T hear anything until JDK 9 gets released and developers start using it, it seems safer to leave it false for now and revisit marking for removal in 10 when hopefully we've had some feedback.

-DrD-

  </pre>
  <blockquote type="cite">
    <pre wrap="">Yes, ultimately the decision is up to Kevin and Dave (or whoever is in charge of technical decision-making in this area).

I wanted to provide some clarity on the use of forRemoval=true.

The specification is fairly neutral, saying only that there is "intent to remove" the API "in a future version."

In practice, for the JDK, I'm trying to make sure we set forRemoval=true only when there are definite plans for removal in the near future, for example, in the following release. I want to avoid a situation where there are a bunch of APIs in the JDK that have forRemoval=true but that are hanging around for several releases before they are eventually removed. (Or not.)

When I discussed this issue with the team with respect to the Applet API, I asked whether Applets would be removed in the next release (after JDK 9). There was some hemming and hawing, and eventually it emerged that there were still some narrow use cases that would probably still need to be supported even in the next release, and they weren't entirely sure when Applet could actually be removed. Based on that discussion we deprecated Applet with forRemoval=false in JDK 9, and we'll revisit this in the future when plans are more definite.

I had thought that the plugin and Applets were closely related enough so that they ought to be treated the same. This would argue that this API should also be deprecated in JDK 9 with forRemoval=false, and revisited at the same time as Applet. But I could be mistaken, and it might make sense to treat the plugin separately from Applet.

s'marks

On 6/10/16 11:30 AM, Mandy Chung wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">This method is about the fate of plugin support in a future regardless of the presence of java.applet.Applet API. The @deprecated note may cause the confusion.

What I understand from the past discussion with Kevin and Dave, we want this method to be removed in a future release - the earliest possible release would be N+1 when it’s deprecated for removal in JDK N.

I’ll let Kevin and Dave to clear this up and make the final call.

Mandy

      </pre>
      <blockquote type="cite">
        <pre wrap="">On Jun 10, 2016, at 9:58 AM, Stuart Marks <a class="moz-txt-link-rfc2396E" href="mailto:stuart.marks@oracle.com"><stuart.marks@oracle.com></a> wrote:

Hi, sorry I had missed this earlier.

It's surprising if forRemoval=true were to be added to this API when the rest of the Applet API has forRemoval=false. Is it the intent, for example, to have JSObject.getWindow() removed from JDK 10 but to have the rest of the Applet API remain?

My understanding of the plan was to deprecate the Applet API in JDK 9 with forRemoval=false. Then, in a future release, when removal plans become more definite, to change forRemoval to true, and in a subsequent release, to remove the Applet APIs. I'd think that plan would apply here as well.

Put another way, I'd recommend that we set forRemoval=true only when the plan is more definite than "we plan to remove this in some future, as yet unspecified release."

s'marks


On 6/8/16 5:34 PM, Daniil Titov wrote:
        </pre>
        <blockquote type="cite">
          <pre wrap="">Hello,

Please review the new version of the fix for JDK9.

1. "forRemoval = true" is added to @Deprecated annotation for JSObject.getWindow(Applet) method.
2.  A new doc bundle for JSObject documentation is added in the docs build.

Webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01">http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.01</a>
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~dtitov/8156960/webrev.01">http://cr.openjdk.java.net/~dtitov/8156960/webrev.01</a>


Bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8156960">https://bugs.openjdk.java.net/browse/JDK-8156960</a>

Thank you!

Best regards,
Daniil

-----Original Message-----
From: Mandy Chung
Sent: Wednesday, June 08, 2016 3:09 PM
To: Daniil Titov
Cc: David Dehaven; Stuart Marks; Erik Joelsson; build-dev; <a class="moz-txt-link-abbreviated" href="mailto:build-infa-dev@openjdk.java.net">build-infa-dev@openjdk.java.net</a>; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate JSObject.getWindow(Applet) method

That’s right.  It requires to add a new doc bundle in the docs build.  What you did was the right direction.  Can you update the webrev?

FYI.  There is an effort under discussion to revisit the number of docs bundle generated and clean up the docs build.

Mandy

          </pre>
          <blockquote type="cite">
            <pre wrap="">On Jun 8, 2016, at 2:48 PM, Daniil Titov <a class="moz-txt-link-rfc2396E" href="mailto:daniil.x.titov@oracle.com"><daniil.x.titov@oracle.com></a> wrote:

NON_CORE_PKGS variable is not used in make/Javadoc.gmk, so just adding a new package in this variable will not make this package included in any docs. We will need to create a new javadoc target for JSObject documentation ( or add it to some existing target, but it doesn't look like there is one that fits it). For example:


diff -r 389c2d2842a5 make/Javadoc.gmk
--- a/make/Javadoc.gmk  Wed May 25 12:53:26 2016 +0200
+++ b/make/Javadoc.gmk  Thu Jun 02 16:20:35 2016 -0700
@@ -82,7 +82,7 @@
PLUGIN2_FIRST_COPYRIGHT_YEAR = 2007
JDKNET_FIRST_COPYRIGHT_YEAR = 2014
JACCESSAPI_FIRST_COPYRIGHT_YEAR = 2002
-
+JSOBJECT_FIRST_COPYRIGHT_YEAR = 1993

# Oracle name
FULL_COMPANY_NAME = Oracle and/or its affiliates @@ -1031,6 +1031,64
@@

#############################################################
#
+# jsobjectdocs
+#
+
+ALL_OTHER_TARGETS += jsobjectdoc
+
+JSOBJECT_DOCDIR := $(JRE_API_DOCSDIR)/plugin/jsobject
+JSOBJECT2COREAPI := ../../../$(JDKJRE2COREAPI) JSOBJECT_DOCTITLE :=
+Java$(TRADEMARK) JSObject Doc JSOBJECT_WINDOWTITLE := Java JSObect
+Doc JSOBJECT_HEADER := <strong>Java JSObject Doc</strong>
+JSOBJECT_BOTTOM := $(call
+CommonBottom,$(JSOBJECT_FIRST_COPYRIGHT_YEAR))
+# JSOBJECT_PKGS is located in NON_CORE_PKGS.gmk
+
+JSOBJECT_INDEX_HTML = $(JSOBJECT_DOCDIR)/index.html
+JSOBJECT_OPTIONS_FILE = $(DOCSTMPDIR)/jsobject.options
+JSOBJECT_PACKAGES_FILE = $(DOCSTMPDIR)/jsobject.packages
+
+# The modules required to be documented JSOBJECT_MODULES =
+jdk.jsobject
+
+jsobjectdocs: $(JSOBJECT_INDEX_HTML)
+
+# Set relative location to core api document root
+$(JSOBJECT_INDEX_HTML): GET2DOCSDIR=$(JSOBJECT2COREAPI)/..
+
+# Run javadoc if the index file is out of date or missing
+$(JSOBJECT_INDEX_HTML): $(JSOBJECT_OPTIONS_FILE) $(JSOBJECT_PACKAGES_FILE) $(COREAPI_INDEX_FILE)
+       $(prep-javadoc)
+       $(call JavadocSummary,$(JSOBJECT_OPTIONS_FILE),$(JSOBJECT_PACKAGES_FILE))
+       $(JAVADOC_CMD_SMALL) -d $(@D) \
+           @$(JSOBJECT_OPTIONS_FILE) @$(JSOBJECT_PACKAGES_FILE)
+
+# Create file with javadoc options in it
+$(JSOBJECT_OPTIONS_FILE):
+       $(prep-target)
+       @($(call COMMON_JAVADOCFLAGS) ; \
+          $(call COMMON_JAVADOCTAGS) ; \
+         $(call OptionOnly,-Xdoclint:none) ; \
+          $(call OptionPair,-system,none) ; \
+         $(call OptionPair,-modulesourcepath,$(RELEASEDOCS_MODULESOURCEPATH)) ; \
+         $(call OptionPair,-addmods,$(JSOBJECT_MODULES)) ; \
+         $(call OptionPair,-encoding,ascii) ; \
+         $(call OptionOnly,-nodeprecatedlist) ; \
+         $(call OptionPair,-doctitle,$(JSOBJECT_DOCTITLE)) ; \
+         $(call OptionPair,-windowtitle,$(JSOBJECT_WINDOWTITLE) $(DRAFT_WINTITLE)); \
+         $(call OptionPair,-header,$(JSOBJECT_HEADER)$(DRAFT_HEADER)); \
+         $(call OptionPair,-bottom,$(JSOBJECT_BOTTOM)$(DRAFT_BOTTOM)); \
+         $(call OptionTrip,-linkoffline,$(JSOBJECT2COREAPI),$(COREAPI_DOCSDIR)/); \
+       ) >> $@
+
+# Create a file with the package names in it
+$(JSOBJECT_PACKAGES_FILE): $(call PackageDependencies,$(JSOBJECT_PKGS))
+       $(prep-target)
+       $(call PackageFilter,$(JSOBJECT_PKGS))
+
+
+#############################################################
+#
# mgmtdocs
#


Best regards,
Daniil



-----Original Message-----
From: David DeHaven
Sent: Wednesday, June 08, 2016 1:23 PM
To: Mandy Chung
Cc: Daniil Titov; Stuart Marks; Erik Joelsson; build-dev;
<a class="moz-txt-link-abbreviated" href="mailto:build-infa-dev@openjdk.java.net">build-infa-dev@openjdk.java.net</a>; awt-dev; Kevin Rushforth
Subject: Re: Review Request: 8156960 Deprecate
JSObject.getWindow(Applet) method


How about NON_CORE_PKGS.gmk for javadoc?

Something like:

diff --git a/make/common/NON_CORE_PKGS.gmk
b/make/common/NON_CORE_PKGS.gmk
--- a/make/common/NON_CORE_PKGS.gmk
+++ b/make/common/NON_CORE_PKGS.gmk
@@ -44,6 +44,8 @@
  org.w3c.dom.events \
  org.w3c.dom.views

+JSOBJECT_PKGS = netscape.javascript
+
JDI_PKGS = com.sun.jdi \
  com.sun.jdi.event \
  com.sun.jdi.request \
@@ -113,6 +115,7 @@

# non-core packages in rt.jar
NON_CORE_PKGS = $(DOMAPI_PKGS) \
+    $(JSOBJECT_PKGS) \
  $(MGMT_PKGS) \
  $(JAAS_PKGS) \
  $(JGSS_PKGS) \

-DrD-

            </pre>
            <blockquote type="cite">
              <pre wrap="">The client team owns jdk.jsobject module and so I add awt-dev to this thread.  And bcc jdk9-dev.

It is not Java SE API and it should not add to CORE-PKGS.gmk.  As for @Deprecated, I believe the plan is to remove the getWindows method in a future release. Kevin and Dave can confirm.

Mandy

              </pre>
              <blockquote type="cite">
                <pre wrap="">On Jun 8, 2016, at 12:33 PM, Daniil Titov <a class="moz-txt-link-rfc2396E" href="mailto:daniil.x.titov@oracle.com"><daniil.x.titov@oracle.com></a> wrote:

Hello,



Please review the fix for JDK 9.



The fix adds @Deprecated annotation to netscape.javascript.JSObject.getWindow(Applet) method and ensures that netscape.javascript package is included in the generated docs.



Bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8156960">https://bugs.openjdk.java.net/browse/JDK-8156960</a>



Webrev:   <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/">http://cr.openjdk.java.net/~dtitov/8156960/jdk/webrev.00/</a>

     <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/">http://cr.openjdk.java.net/~dtitov/8156960/webrev.00/</a>





Best regards,

Daniil
                </pre>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>