hg: jdk8/tl/jdk: 2 new changesets

[chris . hegarty]

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

Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc

[Chris Hegarty]

On 3 Jan 2014, at 02:14, Martin Buchholz  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  
> wrote:
> 
> On 2 Jan 2014, at 22:02, Martin Buchholz  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  
>> 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  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
>> >  * This implementation returns entrySet().size().
>> >  */
>> > public int size() {
>> > @@ -87,6 +88,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation returns size() == 0.
>> >  */
>> > public boolean isEmpty() {
>> > @@ -96,6 +98,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation iterates over entrySet() searching
>> >  * for an entry with the specified value.  If such an entry is found,
>> >  * true is returned.  If the iteration terminates without
>> > @@ -126,6 +129,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation iterates over entrySet() searching
>> >  * for an entry with the specified key.  If such an entry is found,
>> >  * true is returned.  If the iteration terminates without
>> > @@ -157,6 +161,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation iterates over entrySet() 

Re: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc

[Chris Hegarty]

> On 2 Jan 2014, at 22:02, Martin Buchholz  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  
>> 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  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
>> >  * This implementation returns entrySet().size().
>> >  */
>> > public int size() {
>> > @@ -87,6 +88,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation returns size() == 0.
>> >  */
>> > public boolean isEmpty() {
>> > @@ -96,6 +98,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation iterates over entrySet() searching
>> >  * for an entry with the specified value.  If such an entry is found,
>> >  * true is returned.  If the iteration terminates without
>> > @@ -126,6 +129,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation iterates over entrySet() searching
>> >  * for an entry with the specified key.  If such an entry is found,
>> >  * true is returned.  If the iteration terminates without
>> > @@ -157,6 +161,7 @@
>> > /**
>> >  * {@inheritDoc}
>> >  *
>> > + * @implSpec
>> >  * This implementation iterates over entrySet() 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
>> >  * This implementation always throws an
>> >  * UnsupportedOperationException.
>> >  *
>> > @@ -206,6 +212,7 @@
>> > 

Re: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG

[Brian Burkhalter]

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: JDK 9 RFR of JDK-8027595: Enable BigInteger overflow tests in JTREG

[Alan Bateman]

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: RFR(S): JDK-8031134 : PPC64: implement printing on AIX

[Alan Bateman]

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

JDK 9 RFR of JDK-8029561: Optimization in Integer to string conversion

[Brian Burkhalter]

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: JDK-8028712 : Tidy warnings cleanup for java.sql package

[Lance Andersen - Oracle]

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 
>> 
>> 
>> 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/ 
 
 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  tags seems okay. The only thing that I'm not sure 
>>> about the addition of  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

RFR(S): JDK-8031134 : PPC64: implement printing on AIX

[Volker Simonis]

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: Using @implSpec in AbstractMap, AbstractCollection, AbstractList, etc

[Chris Hegarty]

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  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
>  * This implementation returns entrySet().size().
>  */
> public int size() {
> @@ -87,6 +88,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation returns size() == 0.
>  */
> public boolean isEmpty() {
> @@ -96,6 +98,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation iterates over entrySet() searching
>  * for an entry with the specified value.  If such an entry is found,
>  * true is returned.  If the iteration terminates without
> @@ -126,6 +129,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation iterates over entrySet() searching
>  * for an entry with the specified key.  If such an entry is found,
>  * true is returned.  If the iteration terminates without
> @@ -157,6 +161,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation iterates over entrySet() 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
>  * This implementation always throws an
>  * UnsupportedOperationException.
>  *
> @@ -206,6 +212,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation iterates over entrySet() searching for 
> an
>  * entry with the specified key.  If such an entry is found, its value is
>  * obtained with its getValue operation, the entry is removed
> @@ -255,6 +262,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation iterates over the specified map's
>  * entrySet() collection, and calls this map's put
>  * operation once for each entry returned by the iteration.
> @@ -276,6 +284,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation calls entrySet().clear().
>  *
>  * Note that this implementation throws an
> @@ -302,6 +311,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation returns a set that subclasses {@link 
> AbstractSet}.
>  * The subclass's iterator method returns a "wrapper object" over this
>  * map's entrySet() iterator.  The size method
> @@ -358,6 +368,7 @@
> /**
>  * {@inheritDoc}
>  *
> + * @implSpec
>  * This implementation returns a collection that subclasses {@link
>  * AbstractCollection}.  The subclass's iterator method returns a
>  * "w

hg: jdk8/tl/langtools: 8029143: javadoc standard doclet should add Functional Interface blurb when @FunctionalInterface annotation is present

[bhavesh . x . patel]

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