hg: jdk8/tl/langtools: 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present
Changeset: 4a6f853f8721 Author:bpatel Date: 2014-01-02 02:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a6f853f8721 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/ClassDoc.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/testLambdaFeature/TestLambdaFeature.java ! test/com/sun/javadoc/testLambdaFeature/pkg/A.java ! test/com/sun/javadoc/testLambdaFeature/pkg1/FuncInf.java + test/com/sun/javadoc/testLambdaFeature/pkg1/NotAFuncInf.java
Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc
Hi Doug,
I agree with your changes to AbstractMap. I’ve taken your patch, removed the
superfluous paragraph tags, and generated a webrev.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/
I also ran specdiff to see what else may be impacted by this. It shows that the
only spec changes are to AbstractMap itself, and to ConcurrentHashMap size and
isEmpty. What we want.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html
I know it is late in the JDK 8 game, but I see this as a serious bug in the
documentation, and it needs to be addressed.
Conservatively, one could argue that minimally pasting the appropriate specs
into CHM size and isEmpty would be sufficient to resolve the problem, but I
think your first proposal is a more complete solution. Given the above
specdiff, I would be confident to request this change for inclusion in JDK 8.
I filed the following bug to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8031133
-Chris.
On 28 Dec 2013, at 13:47, Doug Lea d...@cs.oswego.edu wrote:
There might have been some mis-communication about whether the
new @implSpec tag would be used in existing java.util.AbstractX
classes. I had assumed that it would be, and pulled out a few
javadoc overrides in java.util.concurrent classes that would
not be needed if @implSpec were used. With @implSpec, you do
not need to paste in the interface-level spec in an overridden
method just to suppress inclusion of (incorrect) doc comments
about the default implementation.
Is it too late to do this for JDK8? It is easy -- just add a line
with @implSpec for each defined method. AbstractMap diffs
below. (They could be tweaked to get rid of now-unnecessary
paragraph markup, but I don't think this would improve display.)
If this isn't done, then minimally we'd need to paste in
interface-level specs in ConcurrentHashMap.{size, isEmpty}
since the JDK8 javadocs as they stand are wrong. There
may be other cases as well.
...
diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java
--- a/src/share/classes/java/util/AbstractMap.javaThu Nov 21 09:23:03
2013 -0800
+++ b/src/share/classes/java/util/AbstractMap.javaSat Dec 28 08:33:42
2013 -0500
@@ -78,6 +78,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns ttentrySet().size()/tt.
*/
public int size() {
@@ -87,6 +88,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns ttsize() == 0/tt.
*/
public boolean isEmpty() {
@@ -96,6 +98,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified value. If such an entry is found,
* tttrue/tt is returned. If the iteration terminates without
@@ -126,6 +129,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified key. If such an entry is found,
* tttrue/tt is returned. If the iteration terminates without
@@ -157,6 +161,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified key. If such an entry is found,
* the entry's value is returned. If the iteration terminates without
@@ -191,6 +196,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation always throws an
* ttUnsupportedOperationException/tt.
*
@@ -206,6 +212,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching for
an
* entry with the specified key. If such an entry is found, its value is
* obtained with its ttgetValue/tt operation, the entry is removed
@@ -255,6 +262,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over the specified map's
* ttentrySet()/tt collection, and calls this map's ttput/tt
* operation once for each entry returned by the iteration.
@@ -276,6 +284,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation calls ttentrySet().clear()/tt.
*
* pNote that this implementation throws an
@@ -302,6 +311,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns a set that subclasses {@link
AbstractSet}.
* The subclass's iterator method returns a wrapper object over this
* map's ttentrySet()/tt iterator. The ttsize/tt method
@@ -358,6 +368,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns a collection that subclasses {@link
* AbstractCollection}. The subclass's iterator method returns a
* wrapper object
RFR(S): JDK-8031134 : PPC64: implement printing on AIX
Hi, could somebody please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8031134/ It's the straight forward implementation of the basic printing infrastructure on AIX and shouldn't have any impact on the existing platforms. As always, this change is intended for the http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. Thank you and best regards, Volker
Re: RFR: JDK-8028712 : Tidy warnings cleanup for java.sql package
Hi Serge, On Dec 20, 2013, at 9:16 AM, Serge wrote: Hi all. Please review a second fix http://cr.openjdk.java.net/~yan/8028712/webrev.03/ for https://bugs.openjdk.java.net/browse/JDK-8028712 I deleted part of java/sql/package.html, I did not see the section below deleted, perhaps the change did not get pushed to where you generated the webrev from? and replaced br/ to br for compliance with html 3.2 On 12/05/2013 10:39 PM, Lance Andersen - Oracle wrote: Hi Serge This looks OK. For --- old/src/share/classes/java/sql/package.html 2013-12-05 15:08:50.587885460 + +++ new/src/share/classes/java/sql/package.html 2013-12-05 15:08:50.435885464 + Please remove the following Package Specification . Specification of the JDBC 4.0 API Related Documentation . Getting Started--overviews of the major interfaces . Chapters on the JDBC API--from the online version of The Java Tutorial Continued . JDBCTMAPI Tutorial and Reference, Third Edition-- a complete reference and tutorial for the JDBC 3.0 API The above links keep breaking now that we are off of java.sun.com And I agree with roger, please use br Alan, yes I can look to clean up some of the formatting crud for Java SE 9 once we have access to the workspace Thank you for doing this Serge. Best Lance On Dec 5, 2013, at 10:31 AM, Alan Bateman wrote: On 05/12/2013 17:25, Serge wrote: Hi all, please review the fix http://cr.openjdk.java.net/~yan/8028712/webrev.02/ http://cr.openjdk.java.net/%7Eyan/8028712/webrev.02/ for https://bugs.openjdk.java.net/browse/JDK-8028712 This patch cleanup tidy warnings for generated html documentation, and do not affect the appearance of the documentation. The removal of the p tags seems okay. The only thing that I'm not sure about the addition of br/ to the package docs (is that needed?). Lance - while scanning this patch then it appears that some of the formatting in the javadoc comments is all over the place (java.sql.Connection is one example). It might be good to clean that up once the jdk9 project is open for business. -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
JDK 9 RFR of JDK-8029561: Optimization in Integer to string conversion
Following up from this thread of last week http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-December/024162.html with respect to https://bugs.openjdk.java.net/browse/JDK-8029561. The change being suggested in this review request is merely to remove the FIXME comment --- a/src/share/classes/java/lang/Integer.java Mon Dec 30 16:34:06 2013 +0400 +++ b/src/share/classes/java/lang/Integer.java Thu Jan 02 11:21:00 2014 -0800 @@ -376,9 +376,6 @@ // JIT case the dispatch overhead doesn't exist and the // trick is considerably faster than the classic code. // -// TODO-FIXME: convert (x * 52429) into the equiv shift-add -// sequence. -// // RE: Division by Invariant Integers using Multiplication // T Gralund, P Montgomery // ACM PLDI 1994 since the code change proposed in the issue report did not show any performance improvement. Thanks, Brian
Re: RFR(S): JDK-8031134 : PPC64: implement printing on AIX
On 02/01/2014 17:22, Volker Simonis wrote: Hi, could somebody please review the following small change: http://cr.openjdk.java.net/~simonis/webrevs/8031134/ It's the straight forward implementation of the basic printing infrastructure on AIX and shouldn't have any impact on the existing platforms. As always, this change is intended for the http://hg.openjdk.java.net/ppc-aix-port/stage/jdk repository. cc'ing 2d-dev as that is where the printing code is maintained. Your changes suggest that this code should probably be refactored at some point to make it easier to add other Unix variants. -Alan
Re: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG
On 27/12/2013 00:34, Brian Burkhalter wrote: Sounds reasonable. There was previously mention of this getting in before b01 so I wanted to resurface it now. Brian I see Joe's mail asking me to comment but I don't think I have much to add except that when running in agentvm mode + concurrency then it normal to limit the heap of the agent VMs to avoid over committing memory. For example, in jdk/test/Makefile then you'll see that the tests are run with -vmoption:-Xmx512m. One idea would be add an @run so that they run in othervm mode. That way there wouldn't be any question about whether the OOME would cause side effects that would impact tests that run subsequently in the same (agent) VM. Another idea is to just check the heap size in the test so that it skips when the heap size is too small (this approach might be a faster than attempting to test and recovering from the OOME). BTW: Just on the @ test then the normal way to exclude tests is to add the @ignore tag or else add the test to the exclude list (ProblemList.txt). Just mentioning it because someone might spot the space and wonder if it is intentional or not. -Alan.
Re: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG
Would adding @run main/othervm -Xmx1200M BitLengthOverflow and similarly to the other three tests be acceptable? Brian On Jan 2, 2014, at 12:34 PM, Alan Bateman wrote: For example, in jdk/test/Makefile then you'll see that the tests are run with -vmoption:-Xmx512m. One idea would be add an @run so that they run in othervm mode. That way there wouldn't be any question about whether the OOME would cause side effects that would impact tests that run subsequently in the same (agent) VM.
Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc
On 2 Jan 2014, at 22:02, Martin Buchholz marti...@google.com wrote:
As the subject says, these changes should be applied to all of the so-called
skeletal implementations in java.util.
You may have noticed that I used a different subject line in the bug ;-)
There is a *lot* of (previously unavoidable (painful memories)) javadoc
duplication in java.util, some of which could now be undone.
If you are agreeable, then I'd like to push just the AbstractMap changes as
they are to JDK 9 and JDK 8. We can then immediately follow up with the
additional skeletal types, under a different bug number for JDK 9, and evaluate
the feasibility of putting it into JDK 8.
This is just a matter of timing, it is getting very late in the JDK 8 release
cycle. There is a specific problem in CHM stemming from AbstractMap, which I
would like to resolve without growing the scope of the changes and risk.
-Chris.
On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Hi Doug,
I agree with your changes to AbstractMap. I’ve taken your patch, removed the
superfluous paragraph tags, and generated a webrev.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/
I also ran specdiff to see what else may be impacted by this. It shows that
the only spec changes are to AbstractMap itself, and to ConcurrentHashMap
size and isEmpty. What we want.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html
I know it is late in the JDK 8 game, but I see this as a serious bug in the
documentation, and it needs to be addressed.
Conservatively, one could argue that minimally pasting the appropriate specs
into CHM size and isEmpty would be sufficient to resolve the problem, but I
think your first proposal is a more complete solution. Given the above
specdiff, I would be confident to request this change for inclusion in JDK 8.
I filed the following bug to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8031133
-Chris.
On 28 Dec 2013, at 13:47, Doug Lea d...@cs.oswego.edu wrote:
There might have been some mis-communication about whether the
new @implSpec tag would be used in existing java.util.AbstractX
classes. I had assumed that it would be, and pulled out a few
javadoc overrides in java.util.concurrent classes that would
not be needed if @implSpec were used. With @implSpec, you do
not need to paste in the interface-level spec in an overridden
method just to suppress inclusion of (incorrect) doc comments
about the default implementation.
Is it too late to do this for JDK8? It is easy -- just add a line
with @implSpec for each defined method. AbstractMap diffs
below. (They could be tweaked to get rid of now-unnecessary
paragraph markup, but I don't think this would improve display.)
If this isn't done, then minimally we'd need to paste in
interface-level specs in ConcurrentHashMap.{size, isEmpty}
since the JDK8 javadocs as they stand are wrong. There
may be other cases as well.
...
diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java
--- a/src/share/classes/java/util/AbstractMap.javaThu Nov 21 09:23:03
2013 -0800
+++ b/src/share/classes/java/util/AbstractMap.javaSat Dec 28 08:33:42
2013 -0500
@@ -78,6 +78,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns ttentrySet().size()/tt.
*/
public int size() {
@@ -87,6 +88,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns ttsize() == 0/tt.
*/
public boolean isEmpty() {
@@ -96,6 +98,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified value. If such an entry is found,
* tttrue/tt is returned. If the iteration terminates without
@@ -126,6 +129,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified key. If such an entry is found,
* tttrue/tt is returned. If the iteration terminates without
@@ -157,6 +161,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified key. If such an entry is found,
* the entry's value is returned. If the iteration terminates without
@@ -191,6 +196,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation always throws an
* ttUnsupportedOperationException/tt.
*
@@ -206,6 +212,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
for an
* entry with the specified key. If such an entry
Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc
On 3 Jan 2014, at 02:14, Martin Buchholz marti...@google.com wrote:
OK, as you wish - this change is clear progress!
Thanks Martin.
I pushed the AbstractMap changes to JDK 8 and JDK 9.
8031142 now tracks the changes to AbstractCollection and AbstractList
https://bugs.openjdk.java.net/browse/JDK-8031142
-Chris.
On Thu, Jan 2, 2014 at 3:48 PM, Chris Hegarty chris.hega...@oracle.com
wrote:
On 2 Jan 2014, at 22:02, Martin Buchholz marti...@google.com wrote:
As the subject says, these changes should be applied to all of the so-called
skeletal implementations in java.util.
You may have noticed that I used a different subject line in the bug ;-)
There is a *lot* of (previously unavoidable (painful memories)) javadoc
duplication in java.util, some of which could now be undone.
If you are agreeable, then I'd like to push just the AbstractMap changes as
they are to JDK 9 and JDK 8. We can then immediately follow up with the
additional skeletal types, under a different bug number for JDK 9, and
evaluate the feasibility of putting it into JDK 8.
This is just a matter of timing, it is getting very late in the JDK 8 release
cycle. There is a specific problem in CHM stemming from AbstractMap, which I
would like to resolve without growing the scope of the changes and risk.
-Chris.
On Thu, Jan 2, 2014 at 8:03 AM, Chris Hegarty chris.hega...@oracle.com
wrote:
Hi Doug,
I agree with your changes to AbstractMap. I’ve taken your patch, removed the
superfluous paragraph tags, and generated a webrev.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/webrev/
I also ran specdiff to see what else may be impacted by this. It shows that
the only spec changes are to AbstractMap itself, and to ConcurrentHashMap
size and isEmpty. What we want.
http://cr.openjdk.java.net/~chegar/AbstractMap_implSpec/specdiff/overview-summary.html
I know it is late in the JDK 8 game, but I see this as a serious bug in the
documentation, and it needs to be addressed.
Conservatively, one could argue that minimally pasting the appropriate specs
into CHM size and isEmpty would be sufficient to resolve the problem, but I
think your first proposal is a more complete solution. Given the above
specdiff, I would be confident to request this change for inclusion in JDK 8.
I filed the following bug to track this issue:
https://bugs.openjdk.java.net/browse/JDK-8031133
-Chris.
On 28 Dec 2013, at 13:47, Doug Lea d...@cs.oswego.edu wrote:
There might have been some mis-communication about whether the
new @implSpec tag would be used in existing java.util.AbstractX
classes. I had assumed that it would be, and pulled out a few
javadoc overrides in java.util.concurrent classes that would
not be needed if @implSpec were used. With @implSpec, you do
not need to paste in the interface-level spec in an overridden
method just to suppress inclusion of (incorrect) doc comments
about the default implementation.
Is it too late to do this for JDK8? It is easy -- just add a line
with @implSpec for each defined method. AbstractMap diffs
below. (They could be tweaked to get rid of now-unnecessary
paragraph markup, but I don't think this would improve display.)
If this isn't done, then minimally we'd need to paste in
interface-level specs in ConcurrentHashMap.{size, isEmpty}
since the JDK8 javadocs as they stand are wrong. There
may be other cases as well.
...
diff -r 8bc258c021a3 src/share/classes/java/util/AbstractMap.java
--- a/src/share/classes/java/util/AbstractMap.javaThu Nov 21 09:23:03
2013 -0800
+++ b/src/share/classes/java/util/AbstractMap.javaSat Dec 28 08:33:42
2013 -0500
@@ -78,6 +78,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns ttentrySet().size()/tt.
*/
public int size() {
@@ -87,6 +88,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation returns ttsize() == 0/tt.
*/
public boolean isEmpty() {
@@ -96,6 +98,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified value. If such an entry is found,
* tttrue/tt is returned. If the iteration terminates without
@@ -126,6 +129,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified key. If such an entry is found,
* tttrue/tt is returned. If the iteration terminates without
@@ -157,6 +161,7 @@
/**
* {@inheritDoc}
*
+ * @implSpec
* pThis implementation iterates over ttentrySet()/tt searching
* for an entry with the specified key. If such an entry is found,
* the entry's value is returned. If the iteration
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 18080cca998a Author:dl Date: 2014-01-03 06:22 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18080cca998a 8031133: AbstractMap should specify its default implementation using @implSpec Reviewed-by: chegar, alanb ! src/share/classes/java/util/AbstractMap.java Changeset: 33a60ce1e35d Author:chegar Date: 2014-01-03 06:23 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33a60ce1e35d Merge ! src/share/classes/java/util/AbstractMap.java
