Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

On 2013-12-10 12:06, Alan Bateman wrote: (This one is for the jdk9-dev forest once it is created) The addPropertyChangeListener and removePropertyChangeListener methods defined by Pack200.{Packer,Unpacker} and LogManager methods are deprecated and flagged with a warning that they "will be rem

Re: RFR: 8029795 : LinkedHashMap.getOrDefault() doesn't update access order. (was Why doesn't new Map methods generate entry accesses on LinkedHashMap?)

On Dec 11, 2013, at 1:27 AM, Mike Duigou wrote: > I have added tests and documentation for the other methods. > > http://cr.openjdk.java.net/~mduigou/JDK-8029795/1/webrev/ > > The documentation for some of the methods is ambiguous about how many access > events are generated. For LRU cache is

Re: 8029805/8029806: Remove XXX addPropertyChangeListener and removePropertyChangeListener methods

On 11/12/2013 10:03, Magnus Ihse Bursie wrote: I'm glad to see this hackish stuff go away! The build changes are mostly fine, however you remove the definition of BEANLESS_CLASSES_TARGETS but do not remove it everywhere. While it will work (expands to empty), it would be better if you fixed t

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

On 10/12/2013 18:37, Mandy Chung wrote: Alan, The change looks good. A minor one - in the class description of java.lang.SecurityManager, I suggest to remove the references to java.awt.AWTPermission line 143 and 214. Thanks Mandy. I left in these links as it's just a sample list of permiss

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

Hi, Alan, the changes look fine to me. A short quick question: what is the reason to introduce a new AWTPermissions class as a holder for various AWTPermission constants? We can have the same fields directly in AWTPermission. The only difference is that AWTPermission is in java.awt, while the

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

On 11/12/2013 13:17, Artem Ananiev wrote: Hi, Alan, the changes look fine to me. A short quick question: what is the reason to introduce a new AWTPermissions class as a holder for various AWTPermission constants? We can have the same fields directly in AWTPermission. The only difference is t

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

On 12/10/2013 08:51 AM, Alan Bateman wrote: In JDK 8 we deprecated the JDK 1.1-era SecurityManager methods checkTopLevelWindow, checkSystemClipboard and checkAccessAwtEventQueueAccess with a warning that they would be changed in a future release to check AllPermission. At the same time we change

Re: 8029886: Change SecurityManager check{TopLevelWindow, SystemClipboardAccessAwtEventQueueAccess} to check AllPermission

On 11/12/2013 16:16, Sean Mullan wrote: The code changes and suggested wording for the updated methods look fine to me. Please add a release-note=yes label to the issue. The permissions security guide will also need to be updated with the new behavior of these methods: http://download.java.n

RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification

Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe

RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support

Hello Joe, Martin, et. al., In JDK8, solaris 32-bit support was removed entirely, this is the only platform that required dual-mode support, ie. 32-bit and 64-bit binaries co-located in the same binary hierarchy on the disk. In JDK 8 the DUAL_MODE support was disabled in the launcher, using c

Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification

On 12/11/13 8:52 PM, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe Hi Joe, Looks good to me - but I'm not a native English speaker :-) -- daniel

Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification

On 11/12/2013 19:52, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe It looks okay although I think it could be reduced to something like "The origin

hg: jdk8/tl/langtools: 8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses

Changeset: 847cc0cccfa1 Author:rfield Date: 2013-12-11 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/847cc0cccfa1 8029558: java.lang.VerifyError: Bad return type when lambda's body is in parentheses Summary: properly type convert the body of a lambda expression

Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification

On 12/11/2013 12:21 PM, Alan Bateman wrote: On 11/12/2013 19:52, huizhe wang wrote: Hi, This is a quick documentation change to fix an error in javax.xml.stream.XMLOutputFactory: http://cr.openjdk.java.net/~joehw/jdk8/jaxp16MR/8029895/webrev/ Thanks, Joe It looks okay although I think it c

Re: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support

On 12/11/2013 12:25 PM, Martin Buchholz wrote: Although I have a small emotional attachment to the idea of fat binaries, there doesn't seem to be too much support for this in the larger java community, and probably the larger unix community will be 64-bit only relatively soon. So ... OK. Th

Re: RFR for JDK-7168267: TEST_BUG: Cleanup of rmi regression tests (activation and others)

On 12/10/13 6:10 PM, Tristan Yan wrote: /Hi everyone I am working on bug JDK-7168267 . Correct link is https://bugs.openjdk.java.net/browse/JDK-7168267 Root Cause: - Per Stuart's comment, this is a clean up bug. Suggested Fix: - Will use ti

Re: RFR (JAXP) 8029895 : XMLOutputFactory.newFactory(String, ClassLoader) - incorrect specification

looks fine joe On Dec 11, 2013, at 4:10 PM, huizhe wang wrote: > > On 12/11/2013 12:21 PM, Alan Bateman wrote: >> On 11/12/2013 19:52, huizhe wang wrote: >>> Hi, >>> >>> This is a quick documentation change to fix an error in >>> javax.xml.stream.XMLOutputFactory: >>> >>> http://cr.openjdk.jav

Re: [8] WXP minor fixes for a cleaner compile of c code

I have filed https://bugs.openjdk.java.net/browse/JDK-8030010 to clean up these warning and I can sponsor it. Mandy On 12/10/2013 11:17 PM, Staffan Larsen wrote: I see you were directed here from the build-dev list. Unfortunately these are core library fixes, not hotspot fixes. I’ve added cor

RFR: 8027536: rmic: add deprecation warning message

Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/ https://bugs.openjdk.java.net/browse/JDK-8027536 Thanks, s'm

hg: jdk8/tl/jdk: 8029551: Add value-type notice to java.time classes

Changeset: fe3383582427 Author:rriggs Date: 2013-12-11 16:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe3383582427 8029551: Add value-type notice to java.time classes Summary: Add warning about identity of value types and reference to ValueBased.html Reviewed-by: brian

Re: RFR: 8027536: rmic: add deprecation warning message

On 12/11/2013 1:53 PM, Stuart Marks wrote: Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/reviews/8027536/webrev.0/ The change looks

Re: RFR: 8027536: rmic: add deprecation warning message

On 12/11/2013 2:25 PM, Mandy Chung wrote: On 12/11/2013 1:53 PM, Stuart Marks wrote: Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/re

RFR: JDK9: 8029388: java.exe consumes argument intended for launched java class

Hello, Please review a fix for Windows launcher where it consumes application args -d32 and -d64, the fix is to stop the scan when it hits the Application sentinel ie. class-name or jar-name. http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/ Thanks Kumar

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 1298e476729c Author:michaelm Date: 2013-12-11 15:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1298e476729c 8029944: Primitive Stream reduce method documentation pseudo code misidentifies apply method Reviewed-by: mduigou Contributed-by: michael.mcma...@oracle

Re: RFR: 8027536: rmic: add deprecation warning message

Should this be a warning or error? Darryl On 12/11/2013 01:53 PM, Stuart Marks wrote: Hi all, Just one more deprecation task for JDK 8 Please review the following change to rmic to add a warning message that's emitted when static stubs are generated: http://cr.openjdk.java.net/~smarks/

Re: RFR: JDK9: 8029388: java.exe consumes argument intended for launched java class

On 12/11/2013 3:21 PM, Kumar Srinivasan wrote: Hello, Please review a fix for Windows launcher where it consumes application args -d32 and -d64, the fix is to stop the scan when it hits the Application sentinel ie. class-name or jar-name. http://cr.openjdk.java.net/~ksrini/8029388/webrev.0/

Re: RFR: JDK9: 8029388: java.exe consumes argument intended for launched java class

Mandy, Thanks for the review. On 12/11/2013 3:21 PM, Kumar Srinivasan wrote: Hello, Please review a fix for Windows launcher where it consumes application args -d32 and -d64, the fix is to stop the scan when it hits the Application sentinel ie. class-name or jar-name. http://cr.openjdk.j

hg: jdk8/tl/jdk: 8026115: [zh_CN] inproper translation in output of jarsigner command

Changeset: 01b11184bcf9 Author:mfang Date: 2013-12-11 21:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b11184bcf9 8026115: [zh_CN] inproper translation in output of jarsigner command Reviewed-by: naoto, yhuang ! src/share/classes/sun/security/tools/jarsigner/Resources_

RFR: 8030016: HashMap.computeIfAbsent generates spurious access event

Hello all; In the review for JDK-8029795 Paul Sandoz noted that HashMap.computeIfAbsent would generate a spurious access event for keys mapped to null when the function returned null. This patch corrects that behaviour. http://cr.openjdk.java.net/~mduigou/JDK-8030016/0/webrev/ The actual regre

hg: jdk8/tl/nashorn: 3 new changesets

Changeset: 4706897b4dec Author:attila Date: 2013-12-09 10:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/4706897b4dec 8029467: Widening of booleans causes bad results Reviewed-by: jlaskey, lagergren ! src/jdk/nashorn/internal/codegen/Attr.java + test/script/basic/JDK-

Re: RFR: JDK 9: 8024033: [launcher] remove solaris dual mode support

Hi Kumar, Will be glad to see this "feature" purged from the sources! I believe the comments on lines 135 to 167 in the new file still need some updating. The comment block on line 261 - 273 may need revising too. Otherwise, looks fine. Thanks, -Joe On 12/11/2013 01:12 PM, Kumar Srinivasa